[FFmpeg-devel] MJPG decoder picture quality

[Michael Niedermayer]

On Wed, Jun 09, 2010 at 01:09:38PM -0400, Pavel Pavlov wrote:
> > -----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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100609/0ebb052a/attachment.pgp>