[FFmpeg-devel] MJPG decoder picture quality

Pavel Pavlov pavel
Wed Jun 9 02:33:47 CEST 2010

> -----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  

> > 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.

> > 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?

More information about the ffmpeg-devel mailing list