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

[Laurent]

On 10/17/08, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> 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.

I figured out that they were different for general decoders, but
identical specifically for PCM which does not decode anything.
I missed the part that stream pts_bytes was deprecated.

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

Cool.
I extracted your modifications and created a slightly modified patch
that could be applied to the current SVN repository.
* Use of av_malloc instead of talloc.
* Decoding of whole stream packets when fitting the maxlen constraint.

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

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


Thanks,
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libmpcodecs-ad_pcm-syncfix.patch
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20081020/010f925d/attachment.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mplayer-syncfix.patch
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20081020/010f925d/attachment.txt>