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

[D Richard Felker III]

On Sun, Nov 02, 2003 at 01:17:10PM +0100, Arpi wrote:
> Hi,
> 
> > Hey devs! It's far from finished, but here's a glimpse at the new
> > video pipeline layer for mplayer-g2. The main functions of interest
> > are vp_pull_image, vp_get_image, and vp_release_image. vp_config and
> > vp_insert_filter are somewhat relevant to the dreaded auto-insertion
> > hack too. :)
> 
> ok, i'm answering yoru question on irc:
> 
> <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
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.
Maybe stride should be negotiated at config-time? That would help
codecs/filters that don't like stride changing from one frame to
another, but it also might interfere with DR1 of B frames for IPB
codecs. It would also add a lot of complexity to the config process.

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?

Rich