[FFmpeg-devel] [PATCH] ALSA: fix timefilter divergence

[Nicolas George]

L'octidi 28 pluviôse, an CCXX, Michael Niedermayer a écrit :
> Iam quite interrested to see it failing, also heres some simple change
> that vastly improves the timefilters performance in its selftest

I had some time to look at the code, but not tinker with it.

Could you explain in a few words the maths behind your suggested changes?

> note, the variable names in the patch below are not very good, dont
> be mislead by them

They were already awful anyway.

> @@ -41,9 +42,9 @@ TimeFilter *ff_timefilter_new(double clock_period,
>                                double feedback3_factor)
>  {
>      TimeFilter *self       = av_mallocz(sizeof(TimeFilter));
> -    self->clock_period     = clock_period;
> +    self->feedback3_factor = clock_period/feedback3_factor;
> +    self->clock_period_den = 1.0/feedback3_factor;
>      self->feedback2_factor = feedback2_factor;
> -    self->feedback3_factor = feedback3_factor;
>      return self;
>  }
> 
> @@ -62,16 +63,18 @@ double ff_timefilter_update(TimeFilter *self, double system_time, double period)
>      self->count++;
>      if (self->count == 1) {
>          /// init loop
> +        self->first_time =
>          self->cycle_time = system_time;
>      } else {
>          double loop_error;
> -        self->cycle_time += self->clock_period * period;
> +        double num = FFMAX(self->cycle_time - self->first_time, 0) + self->feedback3_factor;
> +        self->cycle_time +=  num * period / self->clock_period_den;
>          /// calculate loop error
>          loop_error = system_time - self->cycle_time;
> 
>          /// update loop
>          self->cycle_time   += FFMAX(self->feedback2_factor, 1.0 / self->count) * loop_error;
> -        self->clock_period += self->feedback3_factor * loop_error / period;
> +        self->clock_period_den += period;
>      }
>      return self->cycle_time;
>  }

If I read things correctly, the second-order feedback factor becomes now, if
I eliminate all unnecessary multiplicative coefficients:

	out <- out + (out + c) / (in + c)

Which means that as time passes, the filter becomes less reactive, I do not
think this is a good property for such a filter.

For example, if the factor between input and output changes (practical case:
ntpd just got the network back and starts correcting a drift), the time the
filter will take to adjust to it will be roughly ten times the time it has
already run. I do not think this is acceptable.

I will need to run some tests to check if my hypothesis is valid, though.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120216/428dcc3e/attachment.asc>