Spotted this on the URI mailing list, am forwarding to
both Timed Text WG list and www-annotation since these
proposals seem close to both concerns. Please trim cc: list
in any followups. Basic idea (see attached fwd) is use of
URI fragments to identify temporal chunks of media content.
cheers,
Dan
Forwarded message 1
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.