[MPlayer-dev-eng] pts audio sync/-tv audio/video interleaving
D Richard Felker III
dalias at aerifal.cx
Sun Mar 3 10:16:31 CET 2002
Sounds good! Is there any chance we'll see this also working with v4l
On Sun, Mar 03, 2002 at 12:47:57AM -0800, Charles Henrich wrote:
> > 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 :(
> Charles Henrich henrich at msu.edu
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
More information about the MPlayer-dev-eng