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

[Uoti Urpala]

On Sat, 2008-02-23 at 20:37 +0100, Nico Sabbi wrote:
> 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

I see no benefit from exposing this functionality outside the demuxer.
And the parts of discussion I looked at on nut-devel looked like they
were talking about the amount of data to buffer before starting
playback. What you committed doesn't really do that.

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

There's little practical difference. What your patch does in practice is
make MPlayer block in the demuxer until a certain "reference clock"
value has been read. How much data MPlayer has in the demuxed packed
buffers is mostly IRRELEVANT unless they reach max size and break. What
matters for playback is whether demuxing calls will block or not.

So demuxing more data so that "mplayer will always have in the
demuxer->(audio|video) queues as much data as the transmitter suggests"
is completely meaningless UNLESS the extra demuxing blocks, and in that
case the practical effect is to act as a delay which prevents decoding.

Using demuxers for timing is a bad idea, and IMO blocking in them should
be avoided when possible. Your patch certainly doesn't implement any
mechanism that would properly sync MPlayer playback with the source
speed.

> I see a lot of improvements with it

Maybe blocking at another moment happens to give smoother playback in
some situation, but that does not make your patch correct. If MPlayer's
playback was too slow before and buffers filled up your patch can only
make it worse. If playback stuttered because of empty buffers then
either MPlayer didn't buffer enough data before starting playback or
playback speed was too high. Your patch doesn't have anything which
could really fix either cause. Something similar could be used to
determine the amount to buffer when starting playback, but your current
code is not a proper implementation of that either.