[MPlayer-dev-eng] [PATCH] Possible SDL aspect bug, quick workaround

D Richard Felker III dalias at aerifal.cx
Sat Oct 18 21:39:41 CEST 2003


On Sat, Oct 18, 2003 at 08:51:01PM +0200, Fredrik Roubert wrote:
> On Sat 18 Oct 20:47 MEST 2003, D Richard Felker III wrote:
> 
> > > > Huh? The scaling values generated by aspect() are only used when a
> > > > hardware scaler is available, or when -zoom and -vf scale are used. At
> > > > least that's the way it's supposed to work.
> > >
> > > Then we have a bug here.
> > >
> > > > Maybe vo_sdl is broken and thinks it has an overlay because SDL is
> > > > emulating it in software or something stupid...
> > >
> > > Could you check if there is a bug in the SDL code, or tell me how it is
> > > supposed to work so that I can track down the bug?
> >
> > The problem is that vo_sdl's query_format returns true for YUV
> > colorspaces without checking whether hardware overlay support is
> > present. This should be checked in the preinit function and stored
> > somewhere. It's probably a bit of a mess to fix.
> >
> > IMO vo_sdl is horrible crap and should be rewritten from scratch, but
> > that would be a lot of work...
> 
> OK. Then I suggest that my patch is applied:
> 
> http://mplayerhq.hu/pipermail/mplayer-dev-eng/2003-May/018669.html
> 
> This will prevent vo_dsl from scaling unless -zoom is specified. Later
> someone (e.g. myself) could implement the right things in the preinit
> function, so that people who actually have a hardware scaler and use SDL
> won't have to use -zoom.
> 
> Is there anyone who thinks this is a bad idea?

I'm against adding hacks like this. Instead add -vf format=bgr32 (or
whatever rgb colorspace your X server is configured for) and mencoder
will load its own (fast) colorspace converter instead of SDL's
horrible slow one, and not scale unless -zoom is specified.

Rich



More information about the MPlayer-dev-eng mailing list