Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#8270 - Mpegplayer artifacts since few month

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

Details

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

chris
This task depends upon

Closed by  Jonathan Gordon (jdgordon)
Tuesday, 15 December 2009, 08:38 GMT+2
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, 12:15 GMT+2
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, 18:37 GMT+2
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
   dump 071205-194909.bmp (150.1 KiB)
Comment by Michael Sevakis (MikeS) - Wednesday, 05 December 2007, 19:03 GMT+2
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, 07:50 GMT+2
Same thing happens on both my Nano and Sansa e200.
Comment by Michael Sevakis (MikeS) - Sunday, 16 December 2007, 10:04 GMT+2
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) - Thursday, 10 April 2008, 01:52 GMT+2
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, 21:40 GMT+2
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.

Loading...