[FFmpeg-devel] [PATCH] ALSA for libavdevice

[Michael Niedermayer]

On Wed, Dec 10, 2008 at 09:27:03PM +0100, Nicolas George wrote:
> Le decadi 20 frimaire, an CCXVII, Michael Niedermayer a ?crit?:
> > you should print the duration of packets in samples based on the actual
> > number of samples and in samples based on the pts difference, if these
> > differ by more than +-1 you should try hard to fix it because this will
> > cause problems on some players IMHO. and the various specs likely dont
> > allow it.
> > I do not know if alsa provides timestamps to this accuracy, but if
> > av_gettime() + correction is everything they have then the awnser is
> > no and some timestamp correction filter will be required. audio.c
> > needs one as well so it should be in the common code.
> 
> I am not really sure what you are talking about here.

This: (correct)
packet0, 512 samples pts=0
packet1, 512 samples pts=511
packet2, 512 samples pts=1023
packet3, 512 samples pts=1534

vs.
(unacceptable)
packet0, 512 samples pts=0
packet1, 512 samples pts=498
packet2, 512 samples pts=1109
packet3, 512 samples pts=1612


> I believe that is the
> fact that the system clock and the sound card timer are probably not
> perfectly in sync, and therefore #samples/samplerate and elapsed system time
> will slowly drift. Is it so?

of course they will drift on normal systems and thats no problem unless its
excessiv but the
timestamps must represent the system clock at the first sound sample.
calling any get "system time" function cannot achive this unless you disable
all interrupts and anything else that might execute in the background between
the sound recording and you checking the time.

Thus in practice either
A. the audio API provides the time 
B. you are in some priviledged code that can really stop everything
C. you will not be able to use the time as is as pts


> 
> If so, this is indeed a problem, and it raises a question: what _should_ the
> PTS actually be? I see no correct way to force the number of samples to
> match the elapsed system time to agree. I would rather not see on-the-fly
> resampling enabled by default, for example.
> 
> By the way, the PTS of an audio packet with a non-zero duration, what is it
> supposed to be exactly: the timestamp of the beginning of the first sample
> in the packet?
> 
> > You could try the filter described at 
> > http://en.wikipedia.org/wiki/Alpha_beta_filter
> 
> "All or part of this article may be confusing or unclear.
> An alpha beta filter (or alpha-beta filter) is a simplified form of observer
> for estimation, data smoothing and control applications."
> 
> That will take some time...

look at Filter equations and Algorithm Summary there, this should not take
more than 5 min to understand.

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- 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/20081210/2b8dc912/attachment.pgp>