[MPlayer-cvslog] r26069 - in trunk/libmpdemux: demuxer.c demuxer.h

[Nico Sabbi]

Il Saturday 23 February 2008 20:08:59 Uoti Urpala ha scritto:
> On Sat, 2008-02-23 at 11:31 +0100, nicodvb wrote:
> > New member in demuxer_t: reference_clock.
> > If it's != MP_NOPTS_VALUE ds_fill_buffer() will keep
> > on demuxing until the pts of the next_pts is <= reference_clock.
> 
> If the video packets and reference clock packets are read synchronously
> from the same stream why would this do anything useful? You could do the
> same even inside the demuxer as it doesn't involve realtime behavior at
> all.

the same principle can be used by other demuxers (rt[s]p comes to mind),
and in the future broadcast streams using NUT, too.
The idea for this patch originated from a thread in nut-devel where 
were discussed techniques to make NUT suitable for streaming

> 
> > It guarantees the compliance with the buffering model indicated
> > by the transmitter of the multiplex and a long-time stability
> > of playback (at least for me).
> 
> It cannot possibly guarantee long-time stability. You're doing nothing
> to sync MPlayer's playback speed to that of the broadcast source. If it
> differs playback won't be stable. Demuxing packets a bit earlier or
> later will not fix anything.
> 
> Isn't this similar to your suggestion that was was discussed on IRC
> earlier? I thought that back then you understood it would not work...
> 

no, it's not the same: at the time I was suggesting to relent decoding,
while this patch permits something different: following the transmitter
clock mplayer will always have in the demuxer->(audio|video) queues
as much data as the transmitter suggests; in practice the patch
is intended to always keep the demuxer's queues full enough.
I see a lot of improvements with it