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

[Uoti Urpala]

On Mon, 2008-02-25 at 00:13 +0100, Nico Sabbi wrote:
> > 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.
> 
> not only at the beginning, but at any time. Why do you say that
> my patch doesn't do it?

It doesn't seem to try getting the transport time at the start before
demuxing anything (which would be when it might still help). And it
certainly isn't a proper implementation of that idea as it mixes it with
later non-startup behavior, plus having the intentional delays hidden
inside the demuxer code (even in cases where waiting would be useful) is
a bad idea IMO.

> #if0 the code if you want, but don't remove it, please.
> I'll try to find a way to change the playback speed dynamically
> if you believe it's more correct (IIRC something like this was
> your proposal on irc)

Are you sure you can do that? It's nontrivial to sync with the source,
and the "correct" behavior is not necessarily even well defined. Some
issues:
- it cannot work if you only read in response to demuxing requests;
you'll never notice falling behind the source that way
- as a consequence it must necessarily involve the stream layer
- it's nontrivial to distinguish sources that really have their own
speed, and ones that are willing to send data at whatever speed you want
to read; the same stream contents over HTTP could be either
- random fluctuations in TCP stream speeds will cause more variation
than source/playback rate differences unless you've been collecting data
for a long time

I haven't used network or other such streams very much so I'm not 100%
sure which practical problems you're trying to find a solution for. One
problem case I've seen is that MPlayer tries to catch back up if
playback is delayed by a blocking demuxer; it'd probably be better to
completely stop playback for a while in that case. But nothing in your
patch, or source timestamps in general, is likely to be useful for
improving the handling of that case. In principle source timestamps
could be used to determine how much to buffer before starting playback,
but my guess is that if cache is enabled then its buffering is more than
the timestamps would indicate anyway.