[MPlayer-dev-eng] [PATCH] vf_bmovl2 - rewrite of vf_bmovl - Extra Tasty Crispy version
Jason Tackaberry
tack at auc.ca
Wed Oct 29 18:53:56 CET 2003
On Wed, 2003-10-29 at 12:19, Jonas Jensen wrote:
> (possibly multiple) commands from two or more non-cooperating
> applications. AFAICS, this was possible in bmovl but not in bmovl2.
Okay, it seems clear that to solve this problem bmovl2 filters must be
chainable. I could key the filter on the fifo filename, so that after a
loadfile, if there already exists a bmovl2 filter listening on that
filename, the image layers from that filter is used.
This means this isn't possible:
mplayer -vf bmovl2=/tmp/fifo,[...],bmovl2=/tmp/fifo
The initialization of the second filter would say something like "Failed
to initialize bmovl2: already listening on /tmp/fifo." Each filter
would implicitly have its own z-index then.
> - Allowing bmovl2 to "listen" on both INET sockets, UNIX sockets and
> (multiple) fifos.
I'm still not convinced this is necessary, especially with the above
proposal. Maybe I'm not considering something I should be?
> - 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.
If bmovl2 can chain the above two points are moot. So it does sound
like allowing chaining but only if the fifos are different is the best
approach.
Cheers,
Jason.
More information about the MPlayer-dev-eng
mailing list