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

[Uoti Urpala]

On Fri, 2007-01-19 at 19:14 +0100, Reimar Döffinger wrote:
> On Fri, Jan 19, 2007 at 07:17:05PM +0200, Uoti Urpala wrote:
> > 1) Remove the forced unpause when handling slave commands.
> > 
> > 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).
> > 
> > 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).
> 
> Huh? To check input yes, but to update the picture on screen, too. How
> to do that without either something like VFCTRL_PERIODIC_UPDATE or
> unpausing (which is not okay).

The slave command can invoke whatever code VFCTRL_PERIODIC_UPDATE would
end up executing (which in this case seems to be a filter call and
vo->flip_page()).

> Not to mention, how is this supposed to work with e.g. 0.2 fps "videos"
> (e.g. slideshow, or someone accidentially reducing speed a bit too
> much)?

This is what part 2) is for; the sleep would be interrupted and the
slave command executed as soon as select returns because of slave input.
Even now MPlayer would in practice execute the slave command in much
less than 5 seconds if there's audio because commands are also handled
whenever MPlayer wakes up to fill audio buffers.

> IMO if you want a completely different approach be more detailed so
> someone without a full understanding of the whole MPlayer main loop and
> filter chain has a chance to understand (and estimate if it will work),

In fact it's probably easier to implement it myself than to get someone
else to produce a patch I'd be happy with. I'll try to find enough
motivation to do that...

> or (IMO better) just suggest tweaks to this patch to contain what annoys you
> most until it is acceptable.

There are two mentioned goals, to handle slave commands quickly (which
this patch is part of) and to handle slave commands without unpausing.
The proposed solutions to those have been partially working hacks which
make the main loop and input handling uglier again. It might be possible
to make a less ugly periodic-update implementation, but that would
neither be enough to fill the needs of vf_overlay (it would still leave
the ugly slave input reading inside a filter) nor necessary (the filter
doesn't actually need periodic updates) so it'd add unnecessary
complexity. Handling slave commands without unpausing is something that
is likely to be useful in other cases too so it should be done properly
instead of adding workaround mechanisms specific to one particular
command.