RE: a quick scan of RTSP for media fragments

Hi Jack,

> -----Original Message-----
> From: public-media-fragment-request@w3.org [mailto:public-media-fragment-request@w3.org] On Behalf Of Jack Jansen
> Sent: vrijdag 25 juni 2010 11:03
> To: Davy Van Deursen
> Cc: public-media-fragment@w3.org
> Subject: 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.

Yes, indeed. I have changed the example.

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

Yes, your guessing is right. However, I provided this information (i.e., my own defined 'StreamName' attribute) as an illustration
of how SDP could be used for track discovery. Actually, SDP is not part of the RTSP protocol (although both are combined
frequently). You can consider SDP as format/protocol that _could_ be used to obtain information about the requested media resource
such as track and codec information. But other methods could be used as well of course. Similar to our HTTP discussion, we consider
track discovery out of scope.

Now, the important thing here is that the id used in the SETUP command to identify a track (which is actually a URI; for example on
the wiki, I used rtsp://example.com/media/video to identify the video track) not necessarily corresponds to the track name we
provide in a media fragment URI. In the example on the wiki, the track name "video" corresponds to rtsp://example.com/media/video
and the track name "audio en" corresponds to rtsp://example.com/media/audio_en. It is the responsibility of the UA to discover this
mapping IMO. Note that a similar mapping could be made in ROE.

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

Note that the Range header has a different meaning in the REDIRECT command than in the PLAY command (see section 10.10 in RFC 2326).
One possibility is that the server sends a REDIRECT command to the client after receiving a SETUP command extended with an id
request (new or extended header?). So, rtsp://foo/media.ogv#id=sport redirects to  rtsp://foo/media.ogv#t=5,10. Another possibility
is to use redirect responses (section 11.2 in RFC 2326), but that is even more unclear in the spec than the REDIRECT command :-(.

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

No, we don't have experience with RTSP redirects ...

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

What I meant was that if we just describe a mapping of media fragments URIs to the RTSP protocol, without defining anything new
within RTSP (new or extended headers), we can rely on the caching strategies of RTSP. You can compare it with the byte range
solution of our HTTP mapping: when we only use byte range requests to request HTTP media fragments, we can rely on existing HTTP
caches. The same is true for RTSP caches IMO. Of course, this only holds when we use RTSP out-of-the box. 

Best regards,

Davy

-- 
Davy Van Deursen

Ghent University - IBBT
Department of Electronics and Information Systems - Multimedia Lab
URL: http://multimedialab.elis.ugent.be/dvdeurse

Received on Friday, 25 June 2010 12:35:12 UTC