[RFC] auto adjustment of playback speed
This patch implements (quite naively) an auto-adjustment mechanism of the playback speed based on the proportion between the real delta_time elapsed from the beginning of the playback and the delta_reference_clock found in the multiplex. At the moment the only mux that carries this information is MPEG-TS and only if demuxed by demux_ts.c. The patch is just in an initial state, but I'd like to know if this code is (or resembles) what Uoti and Rich had in mind when they objected to my commit in ds_fill_buffer() a couple of months ago. The patch should always be used with -af scaletempo, or the audio stream will sound distorted. Possible parameters are: -autospeed to enable the auto-adjustment -autospeed-period (in seconds) indicates the smallest period between two consecutive adjustments -autospeed-threshold is the minimum difference between the two delta_times after which the adjustment will be considered necessary Unfortunately even with this patch applies the video stream sometimes still stutters ... Ideas and comments welcome
On Fri, 2008-04-18 at 10:03 +0200, Nico Sabbi wrote:
This patch implements (quite naively) an auto-adjustment mechanism of the playback speed based on the proportion between the real delta_time elapsed from the beginning of the playback and the delta_reference_clock found in the multiplex. At the moment the only mux that carries this information is MPEG-TS and only if demuxed by demux_ts.c.
The patch is just in an initial state, but I'd like to know if this code is (or resembles) what Uoti and Rich had in mind when they objected to my commit in ds_fill_buffer() a couple of months ago.
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. 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.
Il Friday 18 April 2008 20:11:16 Uoti Urpala ha scritto:
On Fri, 2008-04-18 at 10:03 +0200, Nico Sabbi wrote:
This patch implements (quite naively) an auto-adjustment mechanism of the playback speed based on the proportion between the real delta_time elapsed from the beginning of the playback and the delta_reference_clock found in the multiplex. At the moment the only mux that carries this information is MPEG-TS and only if demuxed by demux_ts.c.
The patch is just in an initial state, but I'd like to know if this code is (or resembles) what Uoti and Rich had in mind when they objected to my commit in ds_fill_buffer() a couple of months ago.
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.
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)
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.
participants (2)
-
Nico Sabbi -
Uoti Urpala