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

[Arpi]

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...


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
    "However, many people beg for its inclusion in Debian. Why?" - Gabucino
  "Because having new software in Debian is good." - Josselin Mouette
"Because having good software in Debian is new." - Gabucino