[MPlayer-dev-eng] Re: [PATCH] VFCTRL_PERIODIC_UPDATE

[Jason Tackaberry]

On Fri, 2007-01-19 at 19:17 +0200, Uoti Urpala wrote:
> I think the patch should not be included as is. The timing-related
> changes try to work around limitations that could be removed instead. A
> better way would be as follows:

There needs to be a line drawn somewhere.  Ultimately what I'm trying to
do (allow external process to update a blended overlay that is both
functional while paused and independent of the mplayer framerate) is
going to graft hacks onto the existing architecture.  Short of
redesigning mplayer myself, we will have to accept there will be some
compromises in some places, and if that isn't acceptable, I'd surely
appreciate knowing that sooner rather than later.


> 1) Remove the forced unpause when handling slave commands.

This is a huge change.  Are you really suggesting I fix this -- which
requires a fair bit of disruption and a lot of work testing -- as a
prerequisite to my patch?


> 2) Change timing sleep to do a select on input fds instead of plain
> nanosleep/usleep and process any input immediately (at least on Unix,
> doing this on Windows would require more work).

I'm happy to implement this, and I suggested a possible implementation
in my email the other week.  But I don't know if the suggestion is still
acceptable to the mplayer team.


> If I've understood correctly what you intend to do with the overlay
> filter then after those changes implementing it should be a lot more
> straightforward. It could use ordinary slave commands which would remove
> the need for both the input filter hacks mentioned earlier and
> VFCTRL_PERIODIC_UPDATE (since the only mentioned use for the update was
> basically to check input instead of any real filter functionality).

Actually there are no input filter hacks, AFAIC.  The input hacks you
mentioned were your own invention, based on your guess as to how I'm
implementing vf_overlay.  I later followed up and described how I was
implementing it, which while unprecedented in the sense that no other
filter (or anywhere else in mplayer for that matter) seems to use
mp_input_add_cmd_filter(), I find it to be a quite reasonable approach
to a filter handling a non-trivial slave command as opposed to stuffing
all that logic into mplayer.c, which itself strikes me as fragile and
busting at the seams.

Cheers,
Jason.