[FFmpeg-devel] How to drop audio samples?

[Richard Neill]

Dear All,

I wonder whether anyone can offer me advice on how to start tweaking the
source of ffmpeg. What I'm trying to do is fix the unlocked(*) audio in
a DV stream (from dvgrab): the camera is actually running its audio
clock too fast, and sampling at about 48009 Hz, but claiming to sample
at 48000 exactly. This causes the audio to drift with respect to the
video - it starts out in sync, but the audio gets behind by about 1
sec/hour.

So far, I've tried

  i)Using -ar 48009 to force the input sample rate to be defined as
48009, rather than 48000. However, ffmpeg still treats it as 48000,
presumably because it trusts the internal DV header. [Is this a bug?]

ii)Using -async  (which does nothing useful).

iii)Saving the stream, de-muxing, resampling with sox, and re-muxing:
   sox -r 48009 input.wav -r 48000 fixed.wav resample
This works fine, but it's no good for a live stream.


What I want to do:

Implement a trivial filter in ffmpeg to drop every nth byte-pair from
the audio stream.


An ideal fix (probably beyond my ability) would be to implement proper
re-sampling (as done by sox), or to lock the audio exactly to the video,
which would keep it exactly synced, even over several weeks.


Thanks very much for your help and advice.

Richard



(*) What happens, as far as I can establish, is that the DV camera (a
canon XL1, which is particularly bad, although other cameras also do
this) has the audio sample-clock and the video sample-clock running from
entirely different oscillators. This saves the requirement for a precise
PLL, and guarantees the audio clock will be jitter-free.

However, unlike "correct" unlocked audio, where the audio clock is
constrained by a PLL to never be out by more than 1/3 frame wrt video
(this causes imperceptible flutter), Canon seem to have decided that
perfect stability is more important than long-term synchronisation!

More details here: http://www.adamwilt.com/DV-FAQ-tech.html