[MPlayer-dev-eng] [PATCH] vf_bmovl2 - rewrite of vf_bmovl - Extra Tasty Crispy version

[Jonas Jensen]

On Mon, 2003-10-20 at 06:55, Jason Tackaberry wrote:
> So I've worked up a new version of bmovl that has several design
> differences.  The original bmovl uses a single bitmap which has the same
> dimensions of the video.  This modified version can have up to 10
> separate bitmaps of varying sizes and they are overlaid at arbitrary
> coordinates.

This is very exciting. vf_bmovl has been desperately needing a rewrite,
and this seems to be the right thing. I'm not an mplayer developer, but
a bmovl user and the author of http://rve.sf.net, and if your patch gets
applied for me I will redesign rve to work with this new filter.

> bmovl2 can also be updated while mplayer is paused.  This was an
> important requirement for me, and I bet freevo will benefit from it as
> well.  Additionally, only one bmovl2 filter can be instantiated -- this
> was a design decision because I wanted the overlay images to survive a
> loadfile command.  While this is contrary to mplayer's filter design
> (the ability to chain filters), in practice I strongly doubt it will be
> a problem and there are good reasons to only allow one instance.

IMHO, a bigger problem with this is that you cannot have multiple
applications drawing overlays at the same time without disturbing each
other. This is a step back from the original vf_bmovl where you could
just add a filter to the chain for each application you had.

A solution to this could be to change bmovl2 to listen on a socket (UNIX
or INET) instead and allow multiple connections. Or to be able to give
multiple fifos as arguments. Or a combination of these.
A socket interface would also allow bi-directional communication so
bmovl2 could tell the application the width/height/fps of the movie.

But is there anything conceptually wrong with letting the overlay both
be chainable and survive loadfile? If there is a way for the filter to
tell which index in the chain it has, could the state not be saved in an
array of struct vf_priv_s instead of a pointer to a single struct
vf_priv_s? Then, in vf_open(), it could just load back the correct
structure into the priv pointer.
This might need either changes in mplayer's filter api or some weird
tricks, I don't know.

In the short term, it could just be an option: if it's chainable it
cannot survive loadfile and vice versa.

> So I submit this patch for your review and comments.  Consider it a
> first draft. :)

It would be nice if it supported a dynamically growing/shrinking number
of images instead of just NUM_IMAGES.
I'd also like support for sending planar YUV images to the filter,
instead of only packed RGB.

I can help with the coding of these things, but let's get the patch
applied first.

-- 
Jonas Jensen <jbj at knef.dk>