[FFmpeg-devel] MJPG decoder picture quality

[Pavel Pavlov]

> -----Original Message-----
> bounces at mplayerhq.hu] On Behalf Of Michael Niedermayer
> > > >  [Pavel Pavlov]
> > > > I use libavcodec, not the ffmpeg cmd line app.
> > >
> > > you post on a development list, we assume you know how to convert
> > > that ;)
> > >
> >
> >  [Pavel Pavlov]
> > Well, as long as search returns anything that matches these cmd line switches
> then obviously it's a minute task to find out what I needed to use. I was primarily
> asking about that comment related to color_range and how to set that (search
> didn't return anything usefull). That question was already answered by Baptiste:
> " Decoders should set AVCodecContext->color_range ..."
> >
> > > >
> > > > [Pavel Pavlov]
> > > > I tried: ffplay -f rawvideo Tulips_1024x768.yuv.bin -pix_fmt
> > > > yuv444p -s 1024x768 It didn't work (window is just a black square).
> > >
> > > could be your hw not supporting such large overlays and SDL send us
> > > a patch that finally frees ffplay from SDL
> > >
> >
> >  [Pavel Pavlov]
> > Not likely, I have a recent pc and yay.exe that I compiled for yuv images has
> my modifications to support other formats and it uses sdl yuv surface and it
> works just fine. The thing is that yay (freshmeat.net/projects/yay) doesn't try to
> open YUV444 surface (which probably isn't well supported by HW), yay seems to
> drop half of these channels and convert this way from 444 to 420. That's
> probably why the colors in my original png looked cold.
> > What's the problem with sdl? I think it's totally ok for use with large projects
> and for modern PC's if you don't have requirements to battle with slow cpu (yuv
> overlay in sdl I think is written in such a way so that if HW doesn't support
> requested format then sdl will convert it in software).
> 
> sdl is shit, the most recent issue i had with it where its timers, they simply are
> inaccurate and unsuitable for multimedia. standard libc aka time of the day
> functions are much more accurate. this is plain a joke also the latency it has for
> passing stuff between threads is not suitable for multimedia.
> 
> not to speak of sdls random messup with >2 audio channels or the issues with
> too large overlays. Or the quaity of its software based color convertion and the
> nearest neighbor scaler that it uses ...
> or the fact that it is slower than more direct access to the hardware benchmark
> sdl vs. vidix in mplayer, its ages ago that i checked but ill wager a bet that sdl has
> not improved speedwise
> 

 [Pavel Pavlov] 
I don't use sdl myself, and the only reason I touched it was because ffplay needs it :) One day I had to work on some directx mess for multimedia for mobiles and it just didn't seem to work sometimes and randomly didn't produce expected results. So, I tried to find some sample code for the functions that I used with directX. Guess what, most of the references on the web were from sdl and after I read the src code I found many problems in the code that I was debugging and I didn't have bad impression after reading their directX code (for video stuff). All timers and synchronization in my code I eventually had to rewrite completely (I never used sdl for that purpose). Sometimes I also had problems with inaccurate timers, or problem when different timer functions don't return consistent times, but for sdl (which is targeted for media and game developers) that kind of stuff should have been solved from the beginning I think :)