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

[Olivier Guilyardi]

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
3 - the v4l2 demuxer believes it uses the the clock of the device, but the v4l2
    documentation states this is the same as 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.

--
  Olivier