[FFmpeg-devel] MJPG decoder picture quality

Baptiste Coudurier baptiste.coudurier
Wed Jun 9 02:41:30 CEST 2010

On 6/8/10 5:33 PM, Pavel Pavlov wrote:
>> -----Original Message-----
>> bounces at mplayerhq.hu] On Behalf Of Baptiste Coudurier
>> Please use latest svn when doing these kind of tests.
> [Pavel Pavlov]
> I couldn't test with latest svn because it just didn't work at all (24: Could not find codec parameters (Video: mjpeg, yuv420p)). Now I figured out why - I forgot that I work with http url directly and that's why latest svn didn't work for me (ffmpeg cmd line tool also doesn't work with http urls for me). It seems that the problem was recently introduced in http code.
> I'm currently: At revision: 23544

Weird, works fine here.

>>> By the way, I didn't notice any color differences between my image
>>> Tulips_yuv444.png, original Tulips.jpg and test%d.png, what color
>>> hotness differences do you get?
>> The original, the png created by ffmpeg have good hot yellow color.
>> Your looks like the yellow was washed, which definitely suggest the conversion
>> from jpeg to png didn't go really well.
>>> Even if these images look the
>>> same, they really are far from the same; look closer: original image
>>> has perfect lines and the other two have some jagged edges and colors
>>> have some green or black in transition from yellow to red.
>> They look the same. Like Michael mentioned, the defaults a tuned toward
>> speed, but it can be changed of course.
>   [Pavel Pavlov]
> That's right, I just tested this cmd line:
> ffmpeg -i Tulips.jpg testX.png -sws_flags +accurate_rnd+full_chroma_int
> and thre results look the same. They aren't exact, but it's just some random pixels are different. In short, that's what I expected to get as output.
> For those who use libavcodec, the equivalent is to pass
> SWS_ACCURATE_RND | SWS_FULL_CHR_H_INT as flags when creating swscale context.

That's correct, but it's more for users of libswscale :)
Besides, maybe we should change the defaults to this.

>>> My Tulips_yuv444.png is a bit different because it's actually yuvj444p
>>> rendered by sdl (yuv surface) and then I simply made a screenshot of
>>> the window :) yuv444 is the MJPG output for hi quality jpegs, has no
>>> relation to png of course.
>> Tulips_yuv444.png is a _PNG_ using RGB24.
>> The original YUVJ444P was converted to RGB24 using something, ffmpeg
>> decoder outputs YUVJ444P.
>> There is nothing wrong with the _decoder_ here.
> [Pavel Pavlov]
> That's it. It seems that all the problems and bad results came from conversion from YUVJ444P to anything that can be rendered.
> Recently, there was a change suggesting that YUVJ444P is deprecated and shouldn't be used. What's the right way to do it from now on?

Decoders should set AVCodecContext->color_range and it should be set to 
pixel format would be PIX_FMT_YUV444P.
I'm not sure the jpeg decoder does that yet, though, it should be changed.

Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org

More information about the ffmpeg-devel mailing list