[Live-devel] scale & timestamps

Ross Finlayson finlayson at live.com
Mon Jan 24 02:33:41 PST 2005


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

Yes.  See RFC 2326 for an explanation of "Scale:" and "Speed:".

>but it looks like reverse speed is not part of the RTSP spec...

That's because "reverse speed" doesn't make any sense.  (It would mean 
streaming backwards, from the client back to the server :-)

>What are plans to implement this?

None (unless, of course, someone wants to pay for it).  I don't think it's 
a very useful feature.

>  Is the main difference between "scale:" and "speed:" about bandwidth?

Yes.  Again, see RFC 2326.

>>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.
[...]
>>Going by the above interpretation (where timestamp is unaffected), if a 
>>negative rate is used, the timestamp still progresses forward.

Yes.

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

Yes, so it's the client's responsibility to alter the speed of the progress 
bar according to the scale factor.  (That's not what I meant when I said 
that "clients do not take the scale factor into account when they *play* 
the received media".)



	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>



More information about the live-devel mailing list