21 messages in org.w3.uritemporal fragments| From | Sent On | Attachments |
|---|---|---|
| Silv...@csiro.au | Mar 6, 2003 9:21 pm | |
| Al Gilman | Mar 10, 2003 5:57 am | |
| Silv...@csiro.au | Mar 20, 2003 7:52 pm | |
| Paul Prescod | Mar 20, 2003 10:37 pm | |
| S. Mike Dierken | Mar 20, 2003 11:29 pm | |
| Larry Masinter | Mar 21, 2003 9:37 am | |
| Silv...@csiro.au | Apr 6, 2003 11:33 pm | |
| John Cowan | Apr 7, 2003 5:34 am | |
| Silv...@csiro.au | Apr 7, 2003 5:39 pm | |
| Silv...@csiro.au | Apr 7, 2003 9:17 pm | |
| Paul Prescod | Apr 7, 2003 10:43 pm | |
| S. Mike Dierken | Apr 7, 2003 11:09 pm | |
| Etan Wexler | Apr 8, 2003 1:31 am | |
| Etan Wexler | Apr 8, 2003 1:31 am | |
| Larry Masinter | Apr 17, 2003 12:17 am | |
| Mark Baker | Apr 17, 2003 6:25 am | |
| Roy T. Fielding | Apr 17, 2003 5:40 pm | |
| Dave Singer | Apr 24, 2003 2:35 pm | |
| Mike Dierken | Apr 24, 2003 10:18 pm | |
| Larry Masinter | Apr 26, 2003 6:41 pm | |
| Dave Singer | Apr 28, 2003 3:43 pm |
| Subject: | temporal fragments | |
|---|---|---|
| From: | Larry Masinter (LM...@acm.org) | |
| Date: | Mar 21, 2003 9:37:20 am | |
| List: | org.w3.uri | |
I think I finally understood 'the issue' (or at least 'an issue'). Currently, the interpretation of fragment identifiers is defined by the media type "retrieved" (at least with HTTP and FTP). Fragment identifiers are not defined for use with URI schemes that don't "retrieve" a representation in a particular media type.
I think your proposal is that, at least for 'rtsp', that it might make sense to define a general mechanism for fragment identifiers that are associated with the _scheme_ instead of the media type. I think the idea (as I understand it) is that the rtsp fragments might be somewhat independent of the 'media type', and instead be uniformly applied to any resource accessed via rtsp.
Is that a fair characterization of the issue?
I'm trying to focus on "how the URI spec might change" issues rather than the specific details of the temporal fragments themselves.
-----Original Message----- From: Silv...@csiro.au [mailto:Silv...@csiro.au] Sent: Thursday, March 06, 2003 9:22 PM To: LM...@acm.org; uri-...@ietf.org; ur...@w3.org Cc: Conr...@csiro.au Subject: URIBOF at IETF meeting S.F.
Dear Larry, URI specialists,
My background is in multimedia, having been involved in the IETF mainly in the Audio/Video transport area. We noticed that there will be a URIBOF at S.F. and that the URI standard is getting reworked. We'd like to put some additional information into this process.
What we really want to be able to do is to reference particular events in audio and video files, and we want this to be part of the URI so that these references can be used in links from other resources, result lists of search engines, or written on the back of a beer coaster.
For some video formats it's possible for the author to include named markers, and that's great -- these can already be referenced as a normal named fragment.
What we want to standardize is a way of describing time offsets, because this is a very useful and intuitive concept, and is technically feasible in streamable file formats. With a standard notation for time offsets in the URI, user agents and servers can behave consistently and users can construct URIs in a well-known way when they find an interesting point in a media file and wish to reference it.
Our proposal: ------------- What we want is to address time offsets into videos in a simple, intuitive and human readable form. The "#fragment" part of URIs naturally lends itself to this task and have therefore come up with the following solution, inspired by the timestamp specification in RTSP:
#@npt=14.5
-> the "#" part signifies a fragment specification -> the "@" tells us to look "at" that time specification -> the "npt=" part is a time scheme just like in RTSP and we are also proposing npt, smpte, smpte-30-drop, smpte-25, and clock -> the time format itself depends on the time scheme, this one signifying a 14.5 seconds offset
More details are specified in an I-D that we have submitted as a discussion document to IETF:
http://www.ietf.org/internet-drafts/draft-pfeiffer-temporal-fragments-00 .txt
Here are examples for temporal URI fragment offsets that we envisage:
http://foo/bar.mov#@smpte=00:00:14:15 (start downloading at 14 seconds and 15 frames into bar.mov)
rtsp://foo/bar.avi#@utc=20030308T143000.00Z (start streaming data recorded on 8th March 2003 at half past 2pm)
http://foo/bar.mpg#@start (start downloading from the start)
rtsp://foo/bar.rm#@now (start streaming now)
Fragment handling ----------------- Currently, the preferred handling of "fragment" offsets is that they are
only interpreted by the client and not transmitted to the server at all.
For multimedia data and the "#@..." fragments we're proposing, it makes sense, however, to allow the server to interpret the fragment offset in order to reduce network load by serving out data only from the offset that a user is really interested in receiving.
A more detailed discussion of this is included in the draft:
http://www.ietf.org/internet-drafts/draft-pfeiffer-temporal-fragments-00 .txt
Best Regards,
Silvia Pfeiffer & Conrad Parker.