Re: video use-case

Hi Dave, all,

On Tue, Oct 7, 2008 at 3:03 AM, Dave Singer <singer@apple.com> wrote:
>
> I rather suspect that these points have been covered before, but in case
> not, here they are:

Roughly, but I think we still have some disagreements here.


> As I understand it, fragment identifiers follow a "#" in URIs, and they are
> interpreted by the user-agent.

Just making sure we're on the same page: when we talk about fragment
addressing here, we are not directly talking about "#" as a means of
addressing. The word "fragment" is overloaded in that we use it both
to discuss subsegments of media resources, as well as the URI fragment
mechanism, which is the one you are referring to here.


> The syntax and semantics of the fragment
> identifier are defined by the resource type.  That is, what constitutes a
> legal fragment for say HTML may look very different from a legal fragment
> for say MP4.

Correct.

> The fact that they are interpreted by the UA does NOT mean
> that the entire resource is automatically downloaded and then the fragment
> interpreted, however.

This is a point of contention. By definition of URI fragements, the
fragment identifier is not being communicated to the Web server.
Instead, it is only interpreted locally by the UA. I have had this
discussion extensively with the URI working group as we were trying to
formalise temporal URIs
(http://lists.w3.org/Archives/Public/uri/2003Jul/0016.html).

Therefore, using only URIs and HTTP, there is no other means of
communicating the fragment specifiction to the server than using the
"?" query component of URIs.


> For example, in a media file that has an index and is
> in time-order, a user-agent wanting a time-based subset may be able to use
> byte-range requests to get the index, and then the part(s) of the file
> containing the desired media. (We do this today for MP4 and MOV files).

Yes, byte-ranges are possible. However, the Web server is the only
component in the system that knows about converting a time offset to a
byte range. Therefore, you have to first communicate with a URI
reference to the server which subsegment you would like to have, the
server can then convert that to byte ranges, return to the UA which
byte range he has to request, and then we can do a normal byte-range
request on the full URI.

When you say that you do this today for MP4 and MOV files, how do you
communicate the fragment to the Web server?


> Query identifiers follow a "?" and are interpreted by the server. The syntax
> and semantics are defined by the server you are using.  To the UA, the
> result is "the resource".  I'm not aware of servers that can do time-based
> trimming of media files, but it's certainly possible that they exist.

Annodex does this. Metavid is making extensive use of this:
http://metavid.org/wiki/Main_Page


> I think it would be fairly easy, however, to do server-based time-trimming
> of, for example, RTSP/RTP-based streams.

It also works for HTTP.

>  I rather think the same would be
> true for mpeg-2 streams.  (This would be query-based).  It would also be
> easy for a client to interpret fragments and do the corresponding seek
> request(s) over RTSP.  I am unclear on the ownership of fragment identifiers
> in RTSP, however.

The meaning of fragement identifiers is defined by the media type and
not by the protocol.


> This 'ownership' of fragment and query identifiers rather suggests to me
> that the best we can do is a 'best practices' document.  It would be great
> if a whole variety of media files were to adopt the same fragment syntax,
> and a whole variety of HTTP servers were to adopt the same query syntax, but
> I doubt that we can mandate it.

Yes, I agree. The point of this working group is to develop a best
practices document that can then be picked up by media types. The idea
is to analyse what already exists (the mechanisms in RTSP, MP4,
temporal URI etc) and develop a syntax that is agreeable by everyone.


> This also raises the question of whether the work will be HTTP-specific, or
> whether other delivery protocols will be considered.  (e.g. RTSP/RTP,
> shoutcast, ultravox, mpeg-2 transport, and so on).

The mandate says to cover at least the HTTP protocol:
http://www.w3.org/2008/01/media-fragments-wg.html. I think making a
best practices recommendation beyond that at this stage may make it
too complicated and impossible to get agreement and adoption.

It's a shame that we have to deal with every
protocol-media-type-combination individually to solve the URI
addressing of media fragments, but that is the world we find ourselves
in.

Regards,
Silvia.

Received on Monday, 6 October 2008 22:17:34 UTC