[FFmpeg-devel] [Jack-Devel] [PATCH] libavdevice: JACK demuxer

[Michael Niedermayer]

On Thu, Mar 05, 2009 at 09:31:43PM +0100, Olivier Guilyardi wrote:
> Michael Niedermayer wrote:
> > On Thu, Mar 05, 2009 at 01:15:21PM +0100, Fons Adriaensen wrote:
> >> On Thu, Mar 05, 2009 at 03:02:14AM +0100, Michael Niedermayer wrote:
> >>
> [...]
> >> I'm not going to waste anymore time on this, unless
> >> you can at least show you understand the basic theory
> >> and we have a common ground. 
> > 
> > i think we agree here,
> > keep your filter, i keep the one that works better
> > and when i get really bored ill reread the theory behind
> > kalman filters and optimally adapt the parameters, until then
> > mine is still having half the error in actual tests and i prefer
> > to give our users the code that performs best in reality than the
> > code that should perform best given linear and timeinvariant +
> > a few other assumtations.
> 
> Michael, as a matter of fact, in libavdevice:
> 
> 1 - the oss demuxer timestamps the packets with gettimeofday() without filtering
> 2 - the v4l demuxer uses gettimeofday() without filtering

i know these are broken, and here is where your timefilter code will come in
handy ...


> 3 - the v4l2 demuxer believes it uses the the clock of the device, but the v4l2
>     documentation states this is the same as gettimeofday()

do you have a link to the docs/src that says it calls gettimeofday() ?


> 4 - the libdc1394 demuxer timestamps seem to be based on the video device clock:
>     dc1394->packet.pts = (dc1394->current_frame  * 1000000) / (dc1394->fps);
> etc...
> 
> As you can see, this is incoherent, and this is the current experience you are
> giving to your users.
> 
> And now, you are fighting about the epsilon amount of jitter that could be
> suppressed during the first couple of samples that are read from the device.
> Nothing is perfect, and the current timefilter does provide an improvement. It
> has been tested and benchmarked (see the link in my previous post).
> 
> This is what I call the Not Invented Here syndrom. The theory and/or the code
> weren't elaborated by you or another member of your group, so you consider that
> it's broken.
> 
> But it's not.

The code performs very significnatly worse on the first 1000 sampled time
values then a naively changed variant which has a single line changed.
Iam just picking the best i can, thats not NIH its rather evolution.
NIH would be rewriting perfectly fine code and ending up with
nothing better, iam not planing to rewrite it just change it to make it
perform better.

also 1000 sampled time values are with, lets say 1024 sound samples per
packet not just a few seconds but closer to a minute. assuming 22khz

and just for fun i tried 10000 time samples
at 0.0% sample rate error your code performs worse by a factor of 14
at 0.1% sample rate error your code performs worse by a factor of 2

iam not sure when you would consider the end of the first few samples
to be but i have the feeling my variant is asymptotically
performing better
and really that makes sense, for the 0.0% sample rate error you try to
beat the arithemtic mean by a exponentially decaying IIR filter, that
cant work out

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090305/79b85fff/attachment.pgp>