[FFmpeg-devel] [PATCH] ALSA for libavdevice
Wed Dec 10 21:27:03 CET 2008
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. 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?
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
"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...
As for your other remarks on the patch, I have read them, but I had not time
yet to work on them. Thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
More information about the ffmpeg-devel