a quick scan of RTSP for media fragments

I did a quick scan of the rtsp spec <http://tools.ietf.org/html/rfc2326> and our wiki page on rtsp <http://www.w3.org/2008/WebVideo/Fragments/wiki/UA_Server_RTSP_Communication>.

Here's areas that I found that need work (or, at least, serious consideration):

1. I can't find any statement on what existing RTSP implementations should do when presented with unknown headers. We would need new headers to the PLAY command, as outlined in the "extending rtsp" section of the Wiki. Hmm, no, on second reading, they should be ignored (section 8.1), so that is fine, it's the same we specify for HTTP.

2. Actually, it might be argued that track and id selection should be done in the SETUP command, not the PLAY command. My reasoning: the PLAY command is also used for seeking during playback, and we probably don't want to burden the server with changing the tracks streamed half-way during playback. 

3. REDIRECT is nasty. The RTSP spec is unclear about when it can be sent (and the Location: argument isn't even mentioned in the header field overview!). So, it isn't clear whether the Range: refers to the whole original resource (in which case an MF client should recompute the time ranges) or to the range requested (in which case an MF client should re-issue the request without the MF range).

4. We should probably define some interaction with the Require: header.

5. Section 13, Caching, has interaction with our stuff.

6. The way people commonly select tracks (see section 14.3, for example) is not standardised anywhere, as far as I know, but may interact with our track selection mechanism.
 
7. RTSP specifically states that SMPTE timestamps are just notational conventions to be converted to NPT. We state that they are container-based addressing.

8. I have no idea whether there are problems with pipelining (section 9.2).
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman

Received on Wednesday, 23 June 2010 11:56:46 UTC