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 08:51:21 UTC