[MPlayer-dev-eng] [PATCH] VFCTRL_PERIODIC_UPDATE

[Reimar Döffinger]

Hello,
On Thu, Jan 11, 2007 at 05:58:07AM +0200, Uoti Urpala wrote:
> On Wed, 2007-01-10 at 20:35 -0500, Jason Tackaberry wrote:
> > Because this allows updating the vo during the sleep loops, if the
> > vfctrl is consumed, it sleeps for smaller intervals to allow more
> > frequent updating.  In the case where the vctrl isn't consumed (the
> 
> Most of the changes related to this seem quite stupid:
> 
> +static int periodic_update(vf_instance_t *vf, vo_functions_t *vo,
> +                            float time_avail) {
> +   int res;
> +   if (!vf) return 0;
> +   if (time_avail < 0.01) return 1;
> 
> 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.

> -    while ( (cmd = mp_input_get_cmd(20, 1, 1)) == NULL) {
> +    while ( (cmd = mp_input_get_cmd(3, 1, 1)) == NULL) {
> 
> +       if (sh_video && periodic_update(sh_video->vfilter, video_out, 1))
> +          usec_sleep(1000);
> +       else
>         usec_sleep(20000);
> 
> 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
> it instead; if you aren't trying to do that then a couple dozen ms here
> shouldn't matter. Your values here are also shorter than the 10 ms
> "sanity check" in periodic_update.

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.

Greetings,
Reimar Döffinger