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

[D Richard Felker III]

Sounds good! Is there any chance we'll see this also working with v4l
anytime soon?

Rich



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 :(
> 
> -Crh
> 
>        Charles Henrich                                   henrich at msu.edu
> 
>                        http://www.sigbus.com:81/~henrich
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng