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

[Jonas Jensen]

On Mon, 2003-10-27 at 19:25, Jason Tackaberry wrote:
> One possibility to get around the multiple connections problem is to use
> arbitrary strings as identifiers rather than integers.  As convention,
> one could prefix the string with "appname_."  Instead of using an array
> to store images, I could just use a linked list with the identifier
> being part of the structure.  This would provide flexibility and also
> remove the limit on the number of images that you could store.
> 
> What do you think?

This solves the problem when two applications take turns to write
something to the same fifo and expect to continue after the other app
has finished. But that is only a small part of the problem.

The bigger problem is when two applications want to render different
things on the video simultaneously, i.e. each frame will be altered by
(possibly multiple) commands from two or more non-cooperating
applications. AFAICS, this was possible in bmovl but not in bmovl2.

I would solve it by:
- Allowing bmovl2 to "listen" on both INET sockets, UNIX sockets and
(multiple) fifos.
- Using only unidirectional communication for now, the new listen
methods are only for multiplexing.
- Keeping a seperate "name space" of layers for each connected file
descriptor. Names can be integers or strings, that doesn't matter to me,
but the prefix convention should be unnecessary because of the name
spaces.
- Giving each file descriptor its own "z-index", so that layers from one
application always stay together and are never mixed.

What do you think?

-- 
Jonas Jensen <jbj at knef.dk>