[MPlayer-dev-eng] -geometry code and -vo fbdev broken

[D Richard Felker III]

On Sun, Feb 23, 2003 at 08:03:23PM +0100, Arpi wrote:
> Hi,
> 
> > > > there is potential to code something a lot like slices into the output
> > > > gif, which would save a lot of space through motion compression.
> > > > vo_gif89a does not currently do this, but it could be added in the future.
> > > > (If I get around to gif hacking again this semester.)
> > > the video filter stuff should convert the format and feed the VOs with slices 
> > > of the correct format so the most common case would be yv12 slices -> rgb?? 
> > > slices -> vo, there is no speed loss, but the code is much cleaner, as the 
> > > conversion code is kept outside of the vo code ...
> > 
> > agree.
> > just checked libmpcodecs, and it seems the slices stuff is clean.
> > (i remembered it has design problems but it seems it's ok)
> > 
> > the only thing a filter has to do is implementing
> 
> ok i've implemented slices in vf_scale, but it's a bit slower than without.
> (tested -vo x11  vs.  -vo x11 -dr -vop format=bgr32,scale)
> 
> as soon a is debug out why is it slower i'll commit.
> 
> btw, the real question is that what will/should happen if 2 connected
> filters support slices. should the first one call the second's draw_slice() ? 
> what is if the slice heights differ? for example vf_scale.
> 
> for now, filters are not supposed to call draw_slice, only codecs do.
> it will work fine.
> 
> to allow filters to call draw_slie() we may need some tricks or api
> extension. for example, when calling swsale() i don't even know what lines
> in the output buffer changed, also i can't force it to render to a given
> position, it always receives teh 0;0 position of the buffer...

How about testing -vop crop or -vop expand with slices and see if they
can improve performance...

Also, keep in mind that slice rendering *into* the vo from the last
filter is very important to speed, at least for G200 where there is no
YV12 direct rendering.

Rich