[Live-devel] scale & timestamps

[Matthew Romaine]

> No, the current (correct) behavior is actually intuitive, if you think 
> of "Scale:" as meaning the rate at which the *underlying source media* 
> plays - not the speed at which the media is streamed.
So I take it the RTSP "Speed: " command is for when changing the speed 
at which the media is streamed...but it looks like reverse speed is not 
part of the RTSP spec...What are plans to implement this? Is the main 
difference between "scale:" and "speed:" about bandwidth?

> Imagine, for example, that you have a streaming server that takes its 
> input by digitizing audio/video that comes from a video tape player. 
> "Scale:" just affects the speed at which the underlying video tape 
> plays. It has no effect on the way in which the streaming server 
> works.
>
> Similarly, RTSP/RTP clients should not (and do not) take the scale 
> factor into account when they play the received media. They just use 
> the presentation time (computed from the RTP timestamps using RTCP) as 
> usual.
hm... but the time-codes on a VCR player will progress at the "scaled" 
rate as well (I believe; haven't used a VCR in a while ;)  Going by the 
above interpretation (where timestamp is unaffected), if a negative 
rate is used, the timestamp still progresses forward.  Since clients 
often visualize a file's playback with a progress bar based on these 
timestamps, won't this lead to a desynchronization between where in the 
media-file we are and what the progress bar indicates? So it is fully 
the client's responsibility to keep track of the rate to maintain 
synchronization, even though if fractional rates were used in the 
future error accumulation could lead to potential drifting...does this 
make sense?

thanks,
matt