[MPlayer-dev-eng] [PATCH] VFCTRL_PERIODIC_UPDATE

[Uoti Urpala]

On Thu, 2007-01-11 at 10:32 +0100, Reimar Döffinger wrote:
> > So here updates are skipped if there's less than 10 ms free time between
> > decoding a frame and showing it. Maybe sensible, but note that this
> > disables updates completely if for example 50 FPS video takes more than
> > 50% CPU. Also the return value 1 is probably wrong given the rest of the
> > code below.
> 
> 
> Which is no problem, the main point is to allow filters to change the content
> when the fps is very low, < 10 fps or even paused.

Then it's just the rest of the patch that doesn't match those goals...

What's the intended use case for the filter?

> > The original sleeps were quite short already. Do you really have a valid
> > reason to make them shorter? If you're trying to show video with good
> > timing in the overlay then there should be a proper timing mechanism for

> Well, the original values would mean a maximum sleep time of 40 ms, if
> you add to that a not impossible 20 ms that the periodic_update might
> need, you get a maximum frame rate of 16 fps for the overlay filter in
> paused mode, which is quite bad even if precise timing does not matter
> so much.

Well, quite bad for what? For displaying smooth video or low-latency
interactive content maybe, but if those are desired then IMO the
implementation should not be polling-based to begin with (and possibly
the whole idea of using slave mode from another process is questionable
for those). The values in the patch gave 3+1 ms sleeps in the pause
loop, meaning 250 loops and 500 wakeups per second (maybe 333 in
practice) which is definitely way too much.