[MPlayer-dev-eng] pts audio sync/-tv audio/video interleaving

[Charles Henrich]

> so do GETIDELAY before reading out buffer, then GetTimer and sub/add value
> from GETIDELAY
> 
> >         dp->pts=cframe/sh_video->fps;
> GetTimer here too
> 
> if you have audio and video coming from different sources, then calculating
> audio pts from video frame no is a VERY BAD IDEA.

GETIDELAY doesnt exist in the BSD oss driver.  I think I finally got this one
working, and I believe my troubles were with the following.  I have three
different clocking sources, (audio, video, wall) and two of the three lie
(audio and video).  The audio rate captured by the card isnt really 44100
samples per second, it varies by card, and is off a little here or there.  I
cant tell for sure, but it may even be off at any given time.  The same
problem occurs with video.  We get a frame every 40ms +/- 1 ms.  The card
seems much more reliable, and in fact I think its just OS delays on signal
notification that is causing the video troubles.

How I solved it.

Video PTS is calculated by wall clock (gettimeofday()).  Current time -
begintime.  (PTS subsystems seems to want 0 based calcs, which is fine, as in
some places PTS gets hacked into floats which really messes things up, rather
than change all PTS references to double, I just normalied to the start time.
Which turns out I will require later to keep sync).

Audio PTS is calculated NOT using gettimeofday(), if you do, you get audio
clipping and popping as data packets are munged to match up the bps rate, and
the actual timestamps.  Instead the audio PTS is calculated as purely if the
card is accurate based on bytes read since the card started to capture data.
At each audio grab, gettimeofday() is queried to find out how much time has
actually passed.  The difference between the wall clock and calculated data
rate is then used to skew the video timestamp (it either increases or
decreases the starttime timestamp to compress or stretch the video to the
audiostream rate).  

This appears to work in my tests with 1min, 30min, 1.5hour capture sessions.
Im doing a 4hour one right now just to make absolutely sure.  It also looks
like mencoder is using ftell() instead of ftello() to figureout where to
update the indexes at the end of the write.  This fails on files bigger than
2gb.  I've modified the code to do a ftello, testing w/ my four hour capture
right now.

If this is all actually working properly, I'll submit new patches tommorow.

As this requires great cooperation between the audio and video capture, any
separate dsp capturing demuxer will need to be able to tell us whats really
going on to skew the video samples during capture.  Wall clock wont work :(

-Crh

       Charles Henrich                                   henrich at msu.edu

                       http://www.sigbus.com:81/~henrich