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

Michael Niedermayer michaelni at gmx.at
Fri Mar 2 03:49:39 CET 2012


On Thu, Mar 01, 2012 at 07:32:50PM +0100, Nicolas George wrote:
> Le duodi 2 ventôse, an CCXX, Michael Niedermayer a écrit :
> > Iam not opposed to using a 2nd order filter with additional handling
> > for discontinuities. Though IIRC the new filter contains a loop and
> > this might cause it to eat more cpu cycles than would be ideal.
> 
> I agree that that loop is not elegant at all. As for CPU cycles, the loop
> actually loops only when the period is longer than 2 ms; for reference,
> on real-world hardware, the period is usually around 0.67 ms (HDA Intel),
> 0.33 ms (old Ensoniq AudioPCI) or 1 ms (Logitech USB webcam). Therefore, the
> loop will only waste cycles when the user has stacked plugins on top of
> their ALSA device, and the plugins will waste much more CPU cycles than this
> little timefilter.

how does your timefilter perform compared to: ?

--- a/libavdevice/timefilter.c
+++ b/libavdevice/timefilter.c
@@ -71,7 +71,7 @@ double ff_timefilter_update(TimeFilter *self, double system_time, double period)

         /// 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 += self->feedback3_factor * loop_error;
     }
     return self->cycle_time;
 }

I was not able to reproduce unstable behavior with this change and
it would avoid the loop.
The filter is also identical to how it was before with a constant
period. The difference is just for variable period and the old code
made no sense in that case, it could not have worked in the limit of
period -> 0 when loop_error would very likely not tend to 0.


> 
> Shall I push this patch series, then, and later consider adding
> discontinuity detection to the timefilter?
> 

> By the way, V4L2 will also need to use the time filter, as some kernels have
> started giving monotonic timestamps.

cant that be disabled ?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- 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/20120302/96df2ca2/attachment.asc>


More information about the ffmpeg-devel mailing list