FS#8270 - Mpegplayer artifacts since few month

Attached to Project: Rockbox
Opened by Chris Kotulla (chrissel) - Wednesday, 05 December 2007, 10:54 GMT
Last edited by Jonathan Gordon (jdgordon) - Tuesday, 15 December 2009, 07:38 GMT
Task Type Bugs
Category Video
Status Closed
Assigned To No-one
Operating System iPod Nano
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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

This task depends upon

Closed by  Jonathan Gordon (jdgordon)
Tuesday, 15 December 2009, 07:38 GMT
Reason for closing:  Out of Date
Additional comments about closing:  no comment for over a year, and I'm sure if this was an actual problem there would be more complaints.
Comment by Paul Louden (Llorean) - Wednesday, 05 December 2007, 11:15 GMT
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?
Comment by Michael Sevakis (MikeS) - Wednesday, 05 December 2007, 17:37 GMT
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
Comment by Michael Sevakis (MikeS) - Wednesday, 05 December 2007, 18:03 GMT
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.
Comment by Tri Nguyen (tri170391) - Sunday, 16 December 2007, 06:50 GMT
Same thing happens on both my Nano and Sansa e200.
Comment by Michael Sevakis (MikeS) - Sunday, 16 December 2007, 09:04 GMT
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.
Comment by Marc Guay (Marc_Guay) - Wednesday, 09 April 2008, 23:52 GMT
I'm not noticing anything out of the ordinary watching Elephant's Dream on the e200. Anyone care to update?
Comment by Michael Sevakis (MikeS) - Saturday, 17 May 2008, 19:40 GMT
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.