[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

static void draw_slice(struct vf_instance_s* vf,
        unsigned char** src, int* stride, int w,int h, int x, int y){
..
}

and of course fill the funcptr entry at open():
    vf->draw_slice=draw_slice;

then the codec will be able to do get_image with flags MP_IMGFLAG_DRAW_CALLBACK.

it's handled in get_image, if the next filter doesn't have draw_slice() then
this flag will be cleared. also, if your filter does support draw_slice()
only at some conditions, but not always, your get_image() should check teh
conditions and clear this flag when draw_slice not available.

note, that if your filter supports draw_slice(), then your put_image()
should check if slices were used and skip whole-frame blit then.

hmm, now i remember what was the problem: buffer allocation.
so filters supporting slices should support direct rendering (get_image()) too.

i think i'll try to implement slices in some filters.


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