[MPlayer-dev-eng] [PATCH] A/V sync improvement for TV streams

[Uoti Urpala]

On Mon, 2008-10-20 at 19:23 -0400, Laurent wrote:
> On 10/17/08, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> > I've already changed the PCM decoder to use the new timestamp method in
> > my git tree.
> 
> Cool.
> I extracted your modifications and created a slightly modified patch
> that could be applied to the current SVN repository.

I think it's a bad idea to try porting random individual changes from
the git tree to svn. If you start doing that exactly which ones would
they be? Applying patches like this to svn would cause extra work when
merging svn changes (it'd conflict with the corresponding code already
in git). If you need some functionality from the git tree I think the
effort is better spent on making the git version work for you if it
doesn't already. In an earlier mail you mentioned using Windows; I can't
test code under Windows myself and the git tree hasn't been tested much
there, but if someone reports problems I'll fix them (I know there's
currently at least one include problem in libvo on Windows, I haven't
committed a fix because it hasn't been tested).

> > > Issue 3:
> > > * TV streams are particular because mplayer cannot read frames faster
> > > than they are acquired. Eventually, you can get short of audio frames
> > > to grab from the demuxer. This is usually not a problem as there are
> > > still audio frames buffered in the audio pipe to the speakers (in
> > > audio filters and audio output drivers), and new audio frames will be
> > > available soon enough from the demuxer.
> > > The proposed (3rd) patch just ensure that mplayer continues to make
> > > its sync work as long as there is some audio frames to sync with in
> > > the audio pipe.
> >
> > If the condition is really only temporary then this shouldn't matter;
> > playing video for a short while based on wallclock time rather than
> > audio adjustments shouldn't make much difference. If the condition is
> > not temporary but playback is really proceeding faster than data is
> > received then this patch at most delays problems for a short period.
> 
> In fact, when in this state, it happens that mplayer reads 100% of the
> available audio buffers from the demuxer quite permanently.
> As a result, the sync routines are never enabled, which causes a permant desync.

If the status is permanent then this is not a good fix. A better simple
workaround would be to pause playback for a while if there isn't enough
data.

> > I fixed one case where the demux stream eof flag was unnecessarily left
> > enabled in the git tree. The same problem may make this problem
> > situation more permanent than it should be. However the main problem is
> > that there is no mechanism to sync MPlayer playback speed to a
> > fixed-speed data source. As long as no such mechanism is implemented
> > there will be some playback problems.
> 
> Yes. There could always be playback issues (frames dropped or missing
> data to play). Though this should happen sparsely, and might not be
> really noticeable (unless the speed drift is indecent).
> Though, this does not create A/V sync issue.

If you try to keep playing without enough audio you'll eventually get
audio buffer underruns. Exactly what effect those have depends on the
audio driver, but it's something that should be avoided.