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

Michael Niedermayer michaelni
Fri Mar 6 17:43:21 CET 2009


On Fri, Mar 06, 2009 at 12:06:23PM +0100, Olivier Guilyardi wrote:
> Michael Niedermayer wrote:
> 
> >> 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 ...
> 
> To me they're not broken, they could be improved by filtering. The one(s) that

They are broken in the sense that files generated with them are likely not within
the limits of some specifications. And that in practice they might not be playable
on some players without strange issues.


> is (are) broken are those that use the device clock, such as libdc1394, thus
> generating timestamps that drift away from the system time. And the other
> problem is that all demuxers do not follow a uniform timestamping mechanism, so
> that nothing guarantees that they play well together.

iam not maintainer of libdc1394* :)


> 
> >> 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() ?
> 
> http://v4l2spec.bytesex.org/spec/x5953.htm#V4L2-BUFFER
> 
> "struct timeval	timestamp :
> For input streams this is the system time (as returned by the gettimeofday()
> function) when the first data byte was captured.[...]"

it just says that the timestamp is compareable to gettimeofday() not that it
is from a (interruptable) gettimeofday() call. Thats is a big difference ...


[...]

> 
> > 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
> 
> Okay, maybe your filter performs better.
> 

> But:
> 1 - Your test code is theoretical. How does your filter perform with real
> devices, soundcards, etc..?

I do not know, it of course should be tested i agree fully about that but
doing truly scientific tests about this is not that easy, one would have
to simulate variing temperatures and have a accurate signal generator ...



> 2 - You are mesuring the jitter (or call it error). But what about the drift?

> What if your filtered time slowly drifts away from the system time?

thats part of the error, thats why iam using the error (sum of squared
differences between the true time and the filtered timestamps)


> For
> instance, the device clock has by definition no jitter (the cycle period is
> fixed) but it *always* drifts (forward or backward).
> 
> Please show us some graphs based on your filter, something similar to this:
> http://www.samalyse.com/code/pendule/benchmarks

should be attached

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jitter.gif
Type: image/gif
Size: 52690 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090306/468bb09b/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drift.gif
Type: image/gif
Size: 72649 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090306/468bb09b/attachment-0001.gif>
-------------- 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/20090306/468bb09b/attachment.pgp>



More information about the ffmpeg-devel mailing list