Subject: Re: [MMUSIC] RTSP: Speed header

From: Magnus Westerlund <[email-masked]>
Date: Fri, 02 Nov 2007 13:49:04 +0100

Thanks,

We need this discussion. I hope others will continue to provide their
view on this issue. Sorry for the delay in responding, IESG Telechat
week. See below for my comments.

Dave Singer skrev:
> We've had some quite long discussions about these headers in various
> groups.  Most people find them confusing, and there are also problems in
> the model.
> 
> First, it does seem that there is a reasonable need for 'VCR' controls
> in a control protocol:  "send me the media at twice rate (fast forward),
> -1 (play reverse) and so on."
> 
> Second, the protocol should also accomodate being able to control
> bandwidth;  "send me at twice rate and you also may use twice the normal
> bandwidth".  I (and others) have thought in the past that RTSP had this
> (I can never remember which is scale and which is speed).
> 
> It seems fairly clear that in this case the usual link between RTP
> timestamp and transmission time is maintained (modulo traffic smoothing).
> 
> RTSP has a control to *detach* these two from each other, so you can ask
> for media at say, twice its *playout* rate according to its timestamps. 
> The use cases I have heard tend to center around buffer management, but
> I believe that that is more correctly handled in RTP using a protocol
> such as that defined by 3GPP.

I think I would agree with you here. I definitely want to cut out the
buffer management aspects from the specification for the moment. But I
would love seeing more work in this area. But we will not finish RTSP
2.0 if we take on this problem.

> 
> Finally, when playing at non-unitary rates, the concept that the RTP
> receiver is unaware is very hard to maintain.  Double-speed video is
> fairly easily done (if the bandwidth is there) by spacing the RTP
> timestamps closer and therefore playing the frames closer in time. This
> does not work for audio;  a frame there lasts for say 1024 samples, and
> it really doesn't achieve any useful effect to get them at 512 sample
> intervals.  Usually, one treats the new stream as being at double the
> sample rate, and you either play it at that rate, or down-sample it
> again, optionally also pitch-shifting.  These operations on the  decoded
> media are obviously well away from the RTP stack.
> 
> We have seen some interesting experiments in ISMA with dropping frames
> from compressed audio streams, and they work better than you might
> expect for at least the codecs tried, but it can hardly be considered a
> general technique.
> 
> So, in summary, should perhaps RTSP have
> a) a command to set the playout rate to non-unity; with the default that
> the same bandwidth should be used;

Yes, and here I think Scale is the right choice to maintain. What needs
to be added is that the default behavior is to maintain the bandwidth.

> b) a command to set the bandwidth limit for the stream, compared to what
> the normal stream would use at a normal play rate.

I am still wondering how useful this would be. But I think it can be
clearly specified. This definitely should be a new header to avoid
confusion around Speed. However, this header will always be subject to
the congestion control used in the media transport.

> c) documentation that the media stack below RTP is necessarily aware of
> non-unity rates and does the appropriate media management;

I hope you mean above as I think normally there is only IP/UDP below RTP
in the stack ;-). But there clearly needs guidance for this. My question
is what signalling support would be needed in relation to Scale. For
example if one plays double speed by delivering all media for receiver
handling, that is quite different from re-encoding the media to be
directly playable. I think there needs to be indication of this.

> d) pointers to buffer and bandwidth management systems such as 3GPP for
> fast buffer-fill and other considerations.

There is also need to clarify what can be done with basic RTCP on
bit-rate management. But the buffer management part is usually lacking.
I don't know of any other standardized buffer management for RTSP
controlled streaming. I would be interested in hearing more about this.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic