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

[Nicolas George]

L'octidi 28 pluviôse, an CCXX, Michael Niedermayer a écrit :
> of course
> what we have are noisy time values at arbitrary time intervals
> we also know these time intervals to a pretty good approximation.
> There is a systematic error in the time intervals due to clocks not
> being exact while i assumed that this systematic error is sufficiently
> close to constant over time. That is 44100 hz may actually be
> 44098 but wont drift slowly around between that and 44102. If this
> assumtation is wrong the filter becomes less optimal but
> should not catastrophically fail.
> 
> The way i implemented that is quite simply to take the first and
> last timestamps and the "number of samples" to get the true sample
> rate and use this instead of a exponentially decaying average.

I have some plots that will, hopefully, prove helpful. The attached
standalone program (I copy-pasted the timefilter implementations to easily
have both versions in the same program) produce data that can be plotted
using gnuplot for example. The first gnuplot command in the comments is what
I am looking at.

I can post PNGs on my webpage, but it is probably best to be able to zoom
around and adjust parameters.

The input is a 48 kHz stream recorded by chunks of 512 samples (this is a
typical default ALSA setting), with a ±16 samples (0.33 ms) white noise on
the measured times.

After 10 seconds, the system clock leaps forward by 0.2 seconds.

After 15 seconds, the system clock speed increases by 10%.

The plot shows the difference between the "real" time (which includes the
leap forward and the speed change: the purpose of the timefilter is to
eliminate the noise, nothing else) and, in that order, the unfiltered input,
the output of the current timefilter and the output of the timefilter as
modified by your patch.

If you look at the first 10 seconds, you see that both filters perform
equally well; that is feedback2_factor working, and they share the same
logic here.

If you zoom on the time discontinuity, at first glance the modified
timefilter seems to smooth it faster. But you need to zoom enough on the
ordinates, and keep enough abscissas, and optionally turn the noise off:
1.5 second after the discontinuity, the original timefilter has gone back to
0. On the other hand, at the same time the modified timefilter is still at
+1 ms (about one audio packet), and after 5 seconds, still at +0.8 ms.

Now let us zoom on the speed change (possibly turning the discontinuity
off): this time, there is no ambiguity: the original timefilter settles in
about 1.5 second while after 5 seconds, the modified timefilter is still
worse than the worst result of the original one. Note that the result are
exactly in the same proportion with a much more reasonable speed change
(+1/1000).

> It might be better to detect this case and force a (partial?) reset of
> the internal state.

I believe the point of using a second-order timefilter is to avoid this:
instead of various heuristics for the problem we thought of, it's all in the
mathematical model of the filter.

> Also theres another issue, if theres a significnat correction from
> NTPD that may mean the previous hours of recording used wrong
> timestamps. And if there are 2 streams (audio & video) which use
> seperate timefilter, they may with either implementation recover at
> different rates makeing the whole issue even worse

Indeed. But we can not do anything about it, timefilter or no timefilter. If
someone wants to sync streams with different time sources, it is their
responsibility to keep the time sources in sync.

The role of the timefilter in libavdevice is only to smooth the noise caused
by the interval between reading the samples and calling av_gettime.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_timefilter.c
Type: text/x-csrc
Size: 4700 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120218/cd6d6f6a/attachment.bin>
-------------- 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/20120218/cd6d6f6a/attachment.asc>