RE: a quick scan of RTSP for media fragments

Hi Siliva,

Great summarization of the discussion. I agree with the fact that the wiki page in its current state is not sufficient to explain
the mapping between RTSP and media fragments. I think your mail is already a very good basis for the structure we need there.

Best regards,

Davy

-- 
Davy Van Deursen

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



> -----Original Message-----
> From: public-media-fragment-request@w3.org [mailto:public-media-fragment-request@w3.org] On Behalf Of Silvia Pfeiffer
> Sent: maandag 28 juni 2010 10:50
> To: Davy Van Deursen
> Cc: Jack Jansen; public-media-fragment@w3.org
> Subject: Re: a quick scan of RTSP for media fragments
> 
> Hi Davy, Jack, all,
> 
> This is a really good discussion. I have just spend some time catching up on the RTSP specification, our wiki page, and this
discussion.
> 
> I now actually think that our wiki page is a bit too bare - it explains mainly how RTSP works, but not really how we map our URLs
to
> these RTSP actions. It seems almost obvious, but it is exactly this little bit of glue that we would need to provide in a
specification,
> IMHO.
> 
> 
> So, I want to take a step back and summarise some of the things that were discussed here and in the wiki and put it into a
structure
> that we can use for the spec.
> 
> 
> 1. Dealing with the media fragment URI dimensions in RTSP
> 
> We have the following dimensions:
> (1) temporal: #t=10,20
> (2) tracks: #track=audio&track=video
> (3) spatial: #xywh=160,120,320,24
> (4) id: #id=Airline%20Edit
> 
> Re (1): In RTSP, temporal fragment URIs are provided through the PLAY method:
> 
> a url such as
> 
>    rtsp://example.com/media#t=10,20
> 
> will be executed as a series of the following methods (all shortened for readability), data selection provided in the PLAY method:
> 
> * C->S: DESCRIBE rtsp://example.com/media
> * S->C: RTSP/1.0 200 OK (with an SDP description, see wiki)
> * C->S: SETUP rtsp://example.com/media/video
> * S->C: RTSP/1.0 200 OK
> * C->S: SETUP rtsp://example.com/media/audio
> * S->C: RTSP/1.0 200 OK
> * C->S: PLAY rtsp://example.com/media
>             Range: npt=10-20
> * S->C: RTSP/1.0 200 OK
>             Range: npt=9.5-20.1
> ...
> 
> We can explain this mapping for all of the media fragment defined time schemes.
> 
> Several temporal media fragment URI requests can be sent as pipelined commands without having to re-send the DESCRIBE and
> SETUP commands.
> 
> 
> Re (2): In RTSP, track fragment URIs are provided through the SETUP method:
> 
> a url such as
> 
>    rtsp://example.com/media#track=audio&track=video
> 
> will be executed as a series of the following method (all shortened for readability), data selection provided in the SELECTION
method:
> 
> * C->S: DESCRIBE rtsp://example.com/media
> * S->C: RTSP/1.0 200 OK (with an SDP description, see wiki)
> * C->S: SETUP rtsp://example.com/media/video
> * S->C: RTSP/1.0 200 OK
> * C->S: SETUP rtsp://example.com/media/audio
> * S->C: RTSP/1.0 200 OK
> ...
> 
> The discovery in this is provided through the SDP, but we would need to mention that it could be done through alternative methods,
> too.
> 
> Several consecutive track media fragment URI requests can only be sent with new SETUP commands and cannot be pipelined.
> 
> 
> Re (3): In RTSP, spatial fragment URIs are not specifically provided for. Just like in HTTP, it is probably not a good idea to
have the
> server deal with this dimension anyway, so it should be stripped off by the UA and be dealt with in the UA alone.
> 
> A url such as
> 
>    rtsp://example.com/media#xywh=160,120,320,24
> 
> will be executed as the url rtsp://example.com/media.
> 
> 
> Re (4): In RTSP, named fragment URIs are not specifically provided for.
> 
> This needs to be discussed, but there are probably several possibilities to resolve this.
> 
> One possibility is to extend SDP to provide all information about all named address points in a resource and then to use those as
a uri
> request, e.g.
> 
> rtsp://example.com/media#id=Airline%20Edit
> 
> could have been mapped to
> 
> rtsp:// example.com/media#t=50,70
> 
> by the UA through the SDP in the reply for the DESCRIBE command.
> 
> 
> A second possibility is to resolve these mappings through the server, e.g.
> 
> rtsp://example.com/media#id=Airline%20Edit
> 
> could have been redirected to
> 
> location rtsp:// example.com/media#t=50,70
> 
> for the UA to re-retrieve. That would even solve it in the cases where we have a realtime stream and ids are written dynamically.
> 
> 
> 2. Putting the media fragment URI dimensions together in RTSP
> 
> A url such as
> 
> rtsp://example.com/media#xywh=160,120,320,24&t=10,20&track=audio&track=video
> 
> will be executed as a series of the following methods (all shortened for readability), data selection provided both in the
SELECTION
> method and the PLAY method:
> 
> * C->S: DESCRIBE rtsp://example.com/media
> * S->C: RTSP/1.0 200 OK (with an SDP description, see wiki)
> * C->S: SETUP rtsp://example.com/media/video
> * S->C: RTSP/1.0 200 OK
> * C->S: SETUP rtsp://example.com/media/audio
> * S->C: RTSP/1.0 200 OK
> * C->S: PLAY rtsp://example.com/media
>             Range: npt=10-20
> * S->C: RTSP/1.0 200 OK
>             Range: npt=9.5-20.1
> ...
> 
> and the UA displays only the rectangle xywh=160,120,320,2 .
> 
> It is true that the resolution of the dimensions is done at different levels of the protocol, but that does not create a problem.
> 
> 
> 3. Caching and RTSP for media fragment URIs
> 
> Since media fragment URIs rely only on existing protocol negotiations in RTSP, there is no need to discuss any changes to the
caching
> approach in RTSP - it still works as before.
> 
> 
> I think this kinda covers it. Have I misunderstood something? Am I missing something?
> 
> Cheers,
> Silvia.
> 
> 
> 
> On Fri, Jun 25, 2010 at 10:34 PM, Davy Van Deursen <davy.vandeursen@ugent.be> wrote:
> > 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 Monday, 28 June 2010 12:15:31 UTC