Subject: [MMUSIC] ISMA on trick modes and cookies

From: Dave Singer <[email-masked]>
Date: Thu, 14 Jun 2007 09:45:46 -0700

Hi.  At the recent ISMA <http://www.isma.tv/> meeting we had a 
discussion on trick modes in RTSP, and what we'd like.  We also 
discussed cookies.

The overall model for RTSP+RTP is that the RTP receivers are unaware 
of RTSP operations.  So we have suggestions on how to handle trick 
modes there.  However, it's worth pointing out that this model is 
rather restrictive.  The issues are most obvious with audio;  playing 
a video stream at a different rate can be achieved by re-timing the 
frames (and maybe dropping some),  Playing an audio stream at a 
different rate really means treating it as if it were at a different 
sampling rate.  Think of a server that has an AAC coded 44.1 audio 
stream;  playing at double really would be best done by decoding it, 
treating that as if it were coded at 88.2, and maybe pitch-shifting 
it back down, and re-sampling that to 44.1 and re-encoding and 
packetizing that. Few servers are willing to do such a loop. So we 
think it's worth exploring the 'RTP aware' model.

In the RTP-unaware model, the 'scale' parameter seems fine.  We think 
it should be clear that the server is re-timing the media to achieve 
the scale.  It needs a companion parameter which allows the client to 
indicate how much bandwidth, compared to normal, the server can use. 
The server can use less than this, but not more;  it should probably 
default to 1.0.  So, scale=2;bandwidthmultiplier=1 means I want 
double-speed but you cannot use more bandwidth.  scale=2; 
bandwidthmultiplier=2 means that from the client's point of view, 
it's OK to use twice the bandwidth (but the server may still thin for 
some other reason).

The current suggested use of the 'speed' parameter -- to send data at 
the 'wrong' speed for the current play rate -- seems wrong.  The 
suggestion is that it can be used for managing client buffer-fill, 
but that is better done, in our opinion, at the RTP level, using a 
client-server bandwidth and buffer management protocol, like TCP or 
the 3GPP RTP buffer management protocol.

However, it does work for the RTP aware case.  If I ask the server to 
send at speed=2, and then run my RTP stack treating the clockrate as 
having doubled, and the audio output (if it's audio) as if the sample 
rate had doubled, then this works.  Again, it could do with an 
explicit bandwidth management companion parameter.

Finally, we think cookies should be supported, that it should be 
clear whether the client cookie database is per-protocol (i.e. 
distinct for HTTP and RTSP) or shared.  It does seem as if more and 
more people are using cookies with RTSP, and this ought to be 
standardized.

-- 
David Singer
Apple/QuickTime

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