• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Video
  • Assigned To No-one
  • Operating System iPod Nano
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by chrissel - 2007-12-05
Last edited by jdgordon - 2009-12-15

FS#8270 - Mpegplayer artifacts since few month

Hey guys,

since some cleanups a few month ago videos on my nano look somekinda ugly. There are many artifacts when something is black in the video. Is it possible to fix this problem? I'm quoting some rockbox member who wrote me a few weeks ago:

"I've asked one of the main mpegplayer coders, and he says what you're talking about is probably a result of us now doing MPEG decoding correctly. The way you're seeing the videos now is the way they actually look when decoded right. I'm going to close this anyway now, if you still think you have found an mpegplayer bug, please open that in its own bug report."

So, this is the report. I hope you can fix it


Closed by  jdgordon
2009-12-15 07:38
Reason for closing:  Out of Date
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

no comment for over a year, and I'm sure if this was an actual problem there would be more complaints.

Could you take a screenshot in a Rockbox simulator, and a screenshot of the same video file in a PC based player that doesn't do any post processing, preferably of the same frame, to show the differences?

MikeS commented on 2007-12-05 17:37

There should be no bug (not with any ASM routines I've done). YUV→RGB conversion is compliant with CCIR601 and correctly decodes the ranges now whereas previously the conversion was done with using the JPEG standard with is not correct for MPEG video. JPEG components use the full 0-255 range for Y, Cb, Cr whereas for MPEG Y = 16-235, Cr, Cb = 16-240. Components outside the range are "blacker than black" and "whiter than white" respecitvely.

If anything's been altered or done differently on Nano, I can't say myself right at this moment.

EDIT: Add own screenshot

MikeS commented on 2007-12-05 18:03

The PC-based player must also decode to RGB565 (no dithering of any sort). The sim doesn't dither yet unfortunately. I ought to throw that together.

Same thing happens on both my Nano and Sansa e200.

MikeS commented on 2007-12-16 09:04

e200 has a really non-linear LCD that brigtens dim colors and compresses bright ones (too much gamma correction in the driver setup IMO) but turning the dithering option on should have it look ok if it's not too much overhead for the material. I know the e200 YUV code is ok. The Gigabeat uses the same color conversion as e200 and doesn't show these problems since the display has much better balance.

I'm not noticing anything out of the ordinary watching Elephant's Dream on the e200. Anyone care to update?

MikeS commented on 2008-05-17 19:40

You must encode in the correct color space as specified above which afaict the encoding recommendations should. Dithering is your best bet for smooth output (but not on Nano yet). I won't make fudge adjustments for things that aren't bugs however if you can point out a specific error in the color conversion that will surely be rectified.


Available keyboard shortcuts


Task Details

Task Editing