[MPlayer-dev-eng] [PATCH] v4l2 interface

[Jindrich Makovicka]

Martin Olschewski wrote:

>On Mon, Jan 13, 2003 at 06:09:22PM +0100, Jindrich Makovicka wrote:
>  
>
>>There's a well known problem that the timestamps of the video stream and 
>>sample counts are related to different timebases. It took me a while to 
>>make the a/v sync work and it required a lot of tedious hacking (see the 
>>*skew* stuff in tvi_v4l.c). If tvi_v4l2 isn't still capable to do 
>>internal a/v sync, it has to be compensated for in mencoder. tvi_v4l2 
>>corrects the video timestamps by the difference between theoretical and 
>>real audio sample count. On my hardware the difference does about 1s pes 
>>hour so it's not negligible.
>>    
>>
>Even after a deep look in tvi_v4l.c I still do not understand all the
>details.  As far as I understand the sample counts of the audio stream
>are related to an internal clock of the audio device, which may drift
>from the system clock, one second per hour in your case.  If this does
>not get compensated a/v sync gets lost obviously.  So it would be
>better to use timestamps from the system clock on audio frames too,
>like video frames, but if the audio device is to fast I have to buffer
>more and more audio frames, if it is to slow, I run dry.  Ok?
>
ok. The current solution is measuring the drift (done in the audio 
capturing thread) while doing some averaging. The drift is simply 
added/subtracted to the video timestamps so the timestamps are (quite) 
related to the audio timebase. The rest is upon the higher layers.

When in "immediate" mode, no audio is captured and the timestamps are 
returned with consequent values according to the framerate. When 
pressing pause, the subsequent frames are silently dropped (because of 
the short 2-frame buffer) and when pressing it again, the current frame 
will have the timestamp only 1/25s higher so the video is still synced 
to the audio, which is fed through the analog loobpack (or at maximum 1 
frame desynced).

>What I am still missing is the principal solution.  Drop audio/video
>frames that does not have a matching partner?
>
Sure but it's done in the higher layers because it's more effective to 
just insert an empty i-frame than feeding the encoder with a duplicated 
frame and let it analyze. You don't have to care about this.

>I will try to add something like this to v4l2 (hopefully I can use
>parts from v4l) but I think I have to fully undestand the problem and
>it's solution first.  Until now I have not found any documentation
>about this.
>
Just use the source and feel free to ask. I think most of the code 
should be reusable by doing a simple copy&paste. Roughly, finding all 
lines containing 'skew' and copying them should be enough ;)

-- 
Jindrich Makovicka