[MPlayer-dev-eng] [PATCH] VFCTRL_PERIODIC_UPDATE

[Jason Tackaberry]

On Fri, 2007-01-12 at 05:42 +0200, Uoti Urpala wrote:
> If it's a slave command that triggers the timing then it sounds like the
> slave input needs to be read and parsed, and that might cause new
> problems since then you need to be able to somehow handle ALL slave
> commands in any location that could sleep. Your previous patch did not
> read slave input between the sleeps in main timing; would something
> (what?) have triggered the filter, or was that another error in the
> patch?

It's not a mistake.  The slave command is handled in the filter.  To do
otherwise would require a scary mishmash of gotos inside mplayer.c,
jumping back and forth between the "key_events" section and the
pause/timing loops, as you have eluded.

But we're getting ahead of ourselves here.  If you do have a problem
with how I'm handling the commands in vf_overlay, we can hash that out
when I submit that patch.  I had hoped to simplify things by breaking up
the patches and deal with them independently.  Certainly it's useful to
talk about vf_overlay in the sense that is a user of this vfctrl, but
they are not inextricably linked.

The idea of VFCTRL_PERIODIC_UPDATE is to provide filters the ability of
updating the frame while paused and inside the timing loops.  So it
seems there's a question of how to do that without polling.  Is that
really so important though, given that polling as the patch proposes
doesn't add any appreciable overhead to critical areas for the case
where there is no VFCTRL_PERIODIC_UPDATE consumer?

(In this case the critical area is the sleep_timer section, and the
overhead is one call to vf->control via periodic_update every frame,
which on my system averages about 2-3 usec and is, for a 24fps video,
about .008% of the time it would spend sleeping.)

Jason.