Re: a quick scan of RTSP for media fragments

On 24 jun 2010, at 09:36, Davy Van Deursen wrote:

>> 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.
> 
> Indeed, track selection is realized through the SETUP command (i.e., a SETUP
> command is necessary for each requested track),

Ah, you're right! I overlooked this in the Wiki.
An example of setting up multiple tracks would be in order.

Also, in your example, with the server returning an SDP description, the track names
are available. Am I right in guessing that the SETUP command should be the
result of the user requesting "rtsp://example.com/media.mp4#track=hinted%20video%20track"?

And, if it is, we may need to look at whether SDP specifies something about character sets (sigh).

>> 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).
> 
> Yes, you're right, redirection in RTSP is not clear at all to me. On the
> other hand, one might argue why we should need redirection within RTSP,
> because byte ranges are irrelevant in RTSP. Also, track and temporal are
> natively supported by RTSP servers, so why would they redirect? The only
> valuable use case of redirection within RTSP is when we need to deal with id
> selection I think. For example, rtsp://foo/media.ogv#id=foo might redirect
> to rtsp://foo/media.ogv#t=5,10&track=audio1, which would solve the id
> problem that I mentioned above.

I'm not sure. I got the idea that an RTSP server could use REDIRECT
for similar things like our id-based selection. So, for example, if you
ask for the sports section of a news broadcast it could redirect you to
the whole news broadcast, but with Range: set to the the bit you requested.

But: that's just guesswork on my part. The spec is very vague on how REDIRECT
is to be used.

Are you familiar with any implementations that use it?

>> 4. We should probably define some interaction with the Require: header.
> 
> Maybe, we could introduce the redirection feature for id selection?
> 
>> 
>> 5. Section 13, Caching, has interaction with our stuff.
> 
> I think that, since we are only using native features of RTSP, we do not
> have to worry about 'media fragment' caching in RTSP.

Explain, please?

The RTSP spec has a short (but dense) section on what should be cached,
and, more specifically, what should not be cached.
--
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 Friday, 25 June 2010 09:03:07 UTC