[MPlayer-dev-eng] Re: [PATCH] bmovl2: nonblocking input

[Jason Tackaberry]

Hi Jonas,

On Sun, 2003-11-09 at 10:01, Jonas Jensen wrote:
> To follow up on the discussion about the next generation of the bmovl
> filter from a few weeks ago, here are my changes to bmovl2, preparing it
> for input from multiple file descriptors. The patch is
> "mplayer-bmovl2-jbj.patch".

After reading diff-between-patches.diff, my general view is the
complexity this code introduces isn't justifiable.  The main benefit
your code is bringing is robustness, but at a pretty high cost.  I don't
think that dynamically growing input buffers are needed at all.  bmovl2
isn't something end-users are going to have to worry about.  It's for
developers, and if developers misusing it causes strange behaviour in
mplayer, I don't see that as a big problem.

Also having bmovl2 read multiple fds seems to increase complexity for a
fairly uncommon use.

Instead, as a result of one of the last threads in mplayer-dev-eng,
bmovl2 should allow chaining, and so if multiple fifos are needed, they
can be chained when filters are specified.  I've already begun work on
that in my branch.

Certainly some work could be put into making bmovl2 more robust, like
adding some bounds checking to sscanf.  bmovl2 does read commands from
the fifo one byte at a time, and while in theory this is inefficient, in
practice it hasn't been an issue in my tests.  bmovl2 will block-read
image data, however.

We need to also consider that bmovl2 hasn't been accepted by mplayer
core developers yet.  My perspective is that the code should be easy to
understand and as least scary as possible so that it has a better chance
of being merged.  I'd rather not see all this work being done for
naught. :)  Any comments from the Mplayer core guys on that?

> The main user-visible difference is that bmovl will not just execute one
> command (or ATOM) per frame and block on the rest, but it will read as
> many commands as possible without blocking and execute them all at once.

This is a problem.  bmovl2's behaviour must be deterministic, and while
your code still ensures commands between ATOM/ENDATOM are executed
between frames, the user doesn't know which frame that will happen. 
This means that transition effects (fading and/or moving) may or may not
be choppy.

Your code does allow ATOMs to be nested which is good.  I added that to
my branch a while ago but haven't sent an updated patch.

> frame, but they may be sent over multiple frames. This also makes it
> possible to send commands over a slow network without stopping the video
> playback.

Now we're talking about sockets instead of fifos.  This seems like
another fringe case, and I don't think that complexity belongs in
mplayer.  A separate process running on the same system as mplayer could
accept and queue commands over a socket and then send them to mplayer
via the fifo.

It might be a good idea to hear from other current bmovl users, like the
Freevo gang, to hear what sort of things they need that bmovl2 is
lacking.  (Ping Gustavo.)

> My plans are to add actual multi-fd support to bmovl2 next week if there
> are no problems with this code.

Again, I think listening on multiple fds is unnecessary and that
behaviour can be gotten by chaining filters.  But I'd be interested to
hear any other arguments you have.

Cheers,
Jason.

-- 
Jason Tackaberry  ::  tack at auc.ca  :: 705-949-2301 x330
Academic Computing Support Specialist
Information Technology Services
Algoma University College  ::  www.auc.ca