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: woensdag 23 juni 2010 13:56
> To: public-media-fragment@w3.org Group WG
> Subject: 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_Co
> mmunication>.
> 
> 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.

Indeed, track selection is realized through the SETUP command (i.e., a SETUP
command is necessary for each requested track), while temporal selection is
done during the PLAY command (using the Range header). Note that this is
also illustrated on the wiki. This means that for both track and temporal
selection, no new _request_ mechanisms such as new request headers need to
be defined. For id selection however, things become tricky. Since the UA has
no idea what's behind the id, it needs to communicate this id to the server.
Now, the tricky part is that track and temporal selection are communicated
in different steps to the server (setup vs. play), which leaves us with the
question in which command we should send the id request ...

Note that the Range header in RTSP is also a response header, which is used
to indicate the actual returned time range, similar to our
Content-Range-Mapping header in HTTP.

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

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

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

The way tracks are discovered is out of scope: SDP is used frequently, but
one could imagine that formats such as ROE are also used for this purpose.
Regarding the way tracks are requested through the SETUP format is pretty
clear IMO when reading the spec. What the example in section 14.3 is trying
to say is that when a media resource only contains one track, the way of
working of RTSP might be confusing for implementers (since a SETUP command
is bound to one track, while a PLAY command is bound to the RTSP session),
resulting in the proposal of a number of (informative) error recovery
methods.

> 
> 7. RTSP specifically states that SMPTE timestamps are just notational
> conventions to be converted to NPT. We state that they are container-based
> addressing.

Good, one problem less :-).

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 Thursday, 24 June 2010 07:37:18 UTC