[MPlayer-dev-eng] [RFC] auto adjustment of playback speed

Uoti Urpala uoti.urpala at pp1.inet.fi
Sat Apr 19 18:57:51 CEST 2008


On Fri, 2008-04-18 at 22:56 +0200, Nico Sabbi wrote:
> Il Friday 18 April 2008 20:11:16 Uoti Urpala ha scritto:
> > This is still fundamentally flawed. You can't match timing with a server
> > based on just the _contents_ of the stream from the server. Those will
> > be exactly the same even if the server clock is slower or faster than
> > yours. Your code would behave exactly the same if the stream came from a
> > file. Trying to "synchronize clocks with a file" is obviously nonsense.
> 
> do you mean that mplayer needs to know the sender's real clock?
> or I'm missing something? In the mpeg reference model there's no
> dependency on the sender clock: the decoder is supposed to use
> only the PCR present in the stream to drive the decoders.

In traditional broadcast the stream is received at an almost constant
rate and the receiver does timing based on when it receives particular
parts of the stream. The most fundamental flaw in what you're doing is
that you're not looking at what has been _received_, but at what portion
of that MPlayer has decided to _demux_ (which depends on MPlayer's own
timing). It's in principle possible to fix that, but the synchronization
problem is still harder than traditional broadcast. Network streams can
have variable delay so you can only base timing very loosely on the rate
at which the stream arrives, and some servers may be willing to send
data over a TCP connection however fast you read.

> > If for example the demuxer ran in a separate thread and immediately read
> > all data available from the server then an approach like this could work
> > (at least in theory, I didn't read the actual code as it was obvious it
> > could not work overall). But it doesn't; what the demuxer has seen does
> > not depend on how much data the server has sent but on how much data
> > MPlayer has wanted to read. The only case where the server speed would
> > have any effect on the behavior of this code would be if MPlayer is
> > delayed because the buffer already ran completely empty and a read
> > blocked.
> > 
> 
> then what's the right way to proceed (keeping in mind that I can't get the
> server's clock)

If you don't understand the issues yourself I doubt you can make a
working system for this based on a description from someone else.




More information about the MPlayer-dev-eng mailing list