- From: Dave Singer <singer@apple.com>
- Date: Mon, 6 Oct 2008 09:03:59 -0700
- To: Media Fragment <public-media-fragment@w3.org>
I rather suspect that these points have been covered before, but in case not, here they are: As I understand it, fragment identifiers follow a "#" in URIs, and they are interpreted by the user-agent. 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. 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. 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). 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. I think it would be fairly easy, however, to do server-based time-trimming of, for example, RTSP/RTP-based streams. 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. 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. 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). -- David Singer Apple/QuickTime
Received on Monday, 6 October 2008 16:04:41 UTC