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

[Michael Niedermayer]

Hi

On Sunday 23 February 2003 20:03, 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...
ill change the swscaler so swscale() returns the number of lines which where 
written, perhaps i should also add a maximum lines parameter, dunno

[...]

Michael