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

[Uoti Urpala]

On Fri, 2008-10-17 at 11:16 -0400, Laurent wrote:
> Issue 1:
> * pts_bytes, which gives the number of bytes read since the last pts,
> is not computed correctly within the libmpdemux/demuxer.c file. It is
> updated when buffers are filled, while it should be updated when they
> are read.
> With the proposed patch, the a_pts calculation, that relies on
> sh_audio->pts_bytes in mplayer.c gets accurate.

Demux stream pts_bytes is different from sh_audio->pts_bytes. The former
is only used by decoders using the old timestamp mechanism.

> Issue 2:
> * the pts from the TV audio stream is not passed through the PCM
> decoder (libmpcodecs/ad_pcm.c), and hence is lost and cannot be used
> in mplayer.c for A/V sync. This is fixed by the second patch.

I've already changed the PCM decoder to use the new timestamp method in
my git tree.

> 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.

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.