[MPlayer-G2-dev] basic g2 vp (video pipeline) code

Arpi arpi at thot.banki.hu
Sun Nov 2 19:58:29 CET 2003


Hi,

> > <dalias> in g2, any object to requiring that all filters/vo be able to
> >     accept images with any stride?
> > 
> > YES.
> > it limits g2 vf layer to use fully controlled filter code only.
> > ie you cannot call 3rd party code which doesnt accept any kind of stride,
> > be it to-mpeg transcoder, codecs (remember, video encoders are connected
> > to vf layer anyway, but it can be workarounded by ugly hacks), external
> > filters and so on.
> > 
> > it should be handled, at least by auto-inserting expand filter.
> 
> OK. IMO there are a couple solutions. One, like you said, is loading
> expand. I'm not sure exactly how this works. Does it expand the image
> up to stride by adding a small border, or copy the image to a new
> buffer with stride = width*bpp? I assume the latter since the former

the later, of course

> isn't always possible (if stride[0] != stride[1]<<csh, etc.).
> 
> Part of the problem with auto-inserting expand is that it has to be
> done at config time, when you don't yet know what stride will be.

yes

> Maybe stride should be negotiated at config-time? That would help

nope, its impossiblee imho in many cases, and adds yet another
limitation...

dont forget that config() happens befor ethe first frame is passed,
so in case of 3rd party codecs, or anything special, you wont know
the wanted stride before processing first frame

> So should we do like G1 and auto-load expand if the destination vf/ve
> has restrictions on which strides it will accept? Will expand behave
> well and just do nothing in the case where the strides already meet
> the dest's requirements?

it depends on implementation of new vf_expand...


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu



More information about the MPlayer-G2-dev mailing list