[Ffmpeg-devel] Question about FAQ 1.3
Mon Dec 26 12:30:46 CET 2005
On Mon, 2005-12-26 at 10:23 +0100, Michel Bardiaux wrote:
> >>>Maybe it is referring to the a-v desync that's possible if the soundcard is
> >>>not exactly clocked at the nominal sampling rate (eg. 44100 Hz). For one,
> >>>MEncoder compensates for this (the video and audio stay in sync although the
> >>>audio is faster/slower than in the original).
> >>If I understand correctly, I think ffmpeg can compensate this drift too,
> >>by properly resampling the audio to synchronize audio and video. I think
> >>this is what the async option is for, right?
> >>Maybe the FAQ entry has been written before async was implemented?
> > Of course this would better be solved with video4linux2 support, but I
> > guess I'd better shut up or get to write the code ;-)
> Exactly *what* feature of V4L2 would be useful for resync, beyond the
> availability of timestamps?
The timestamps are not always available, but if they are, yeah, they
But I was more thinking of the queueing of frames (6 frames saa7134, 32
frames bt878) plus zero-copy for free in addition ;-). My point is, if
frames get fetched and queued in the background while you're reading the
audio device, or possibly even writing to disk or do real-time encoding,
this really helps. As soon as one frame gets dropped (v4l) your sync
will be lost.
With v4l2 you'll have a less chance that frames get dropped, and if they
do, use the timestamp to re-sync.
Completely beside the point, I guess v4l1 support will get removed from
the linux kernel at some point sooner or later. The current kraxel
drivers (saa7134, bt878, cx88) already implement v4l1 as emulation layer
And no, I'm not going to write the code, I don't have any v4l(2) device
anymore, I'd rather not use analogue video anymore. ;-) ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2771 bytes
Desc: not available
More information about the ffmpeg-devel