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

[Nicolas George]

Le primidi 1er ventôse, an CCXX, Michael Niedermayer a écrit :
> Well, but this mathematical model doesnt really match reality
> 
> My patch would exactly calculate the rate while leaving the actual
> values to a first order filter. In the model that the rate is constant.
> If its not constant but instead piecewise constant, like in your test
> here, it of course doesnt work nearly as well.
> 
> One could create a filter that performs better on such piecewise
> constant rate input than any clasical second-order filter.
> That no doubt would perform worse then on for example piecewise
> polynomials
> 
> And any functional classic second-order filter would catastrophically
> break down in case some large discontinuities or outliers are
> introduced.
> 
> I think we should first find a reasonable model for the data and noise
> before trying to find a filter that seperates them
> 
> The 2nd order Timefilter seems to assume that noise is mostly high
> frequency and data is mostly low frequency.
> 
> My patch would in addition have assumed a near constant rate.
> 
> The discontinuities in your test would indicate though that there is
> some non zero high frequency data in addition to the low frequency
> and neither filter handles this well as they try to discard noise by
> discarding high frequency. Blurring the data.
> This should become quite catastrophic in case of large discontinuities
> as  these would have very large high frequency components that actually
> would far exceed the noise.
> I thus think if the filter is intended to handle discontinuities it
> has to do more than just a 2nd order filter. Like detecting such
> discontinuities and reseting its state or adjusting its coefficients.

Obviously, the more rigid the model, the more efficiently it is possible to
filter.

But I believe your proposal is too rigid to model some real-time
phenomenons.

(Additionally, I believe it has the flaw of trusting the very first point
too much: for the same model, a least-square linear fit on all the points
would probably be more accurate; but that is another matter.)

Discontinuities are a severe problem and are easily detected: a special case
for them could be added to any kind of filter.

Speed changes, on the other hand, are much harder to detect, and I believe
they are a real occurrence: I mentioned ntpd, but they also may be due to
some power-management systems, such as cpufreq.

I believe the tests I posted show that the second order filter behaves
pretty well on speed changes. It can not detect them instantaneously, of
course, nothing could short of knowing about them from a side channel. But
the result is always within reasonable values and converges in a very short
time.

In fact, I find the current second order timefilter very good in most cases.
The only problem is that it is designed for constant small intervals, which
does not suit ALSA. That is as much ALSA's fault that the timefilter's. And
the solution of slicing updates small constant steps, although not
mathematically satisfactory, is simple and straightforward, and works pretty
well.

> iam not sure if we misunderstand each other here.
> but if we have audio and video both from the same time source (wall
> clock) and this gets shifted by a few hours due to NTP then the 2 will
> recover very differntly because each has a seperate timefilter
> one run per video frame and one run per audio packet.
> the AV sync errors between the packets after such NTP discontinuity
> should be in the order of minutes and could oscilate around both audio
> and video being late before converging to the correct value

Oh, I see the problem. Maybe a format flag saying that the timestamps are
inaccurate wall-clock timestamp and an option to disable filtering to leave
that work.

But that is another issue.

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/20120220/53af18c2/attachment.asc>