ContentDuration: Difference between revisions

From XiphWiki
Jump to navigation Jump to search
(Q: support HH:MM:SS?)
Line 1: Line 1:
We've been using the Content-Duration header with http servers to provide the length (in time) of a particular Ogg physical bitstream. This speeds up ui display and, if Content-Length is also set, allows faster seeking dispatch over remote protocols by priming the binary search with an initial average bitrate.
We've been using the Content-Duration message header with http servers to provide the length (in time) of a particular Ogg physical bitstream. This speeds up ui display and, if Content-Length is also set, allows faster seeking dispatch over remote protocols by priming the binary search with an initial average bitrate.


Older applications used X-Content-Duration instead. This SHOULD be supported by user agents for backwards compatibility with older server implementations, but new servers should use Content-Duration. This page is a draft spec for registering that message header.
The header specifies the duration of a temporal-tracked media resource in decimal seconds, e.g.
 
  Content-Duration: 2189.242
 
This is intended to be the playback duration of the resource, regardless of any time offset in internal timestamps.
 
Older applications used X-Content-Duration instead. This SHOULD be supported by user agents for backwards compatibility with older server  
implementations, but new servers should use Content-Duration. This page is a draft spec for registering that message header.
 
Question: should we allow the [[[DDD]:HH]:MM]:SS.sss format as well? It's more work to parse, but seems more natural for a message header.


== PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE ==
== PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE ==

Revision as of 21:21, 29 December 2009

We've been using the Content-Duration message header with http servers to provide the length (in time) of a particular Ogg physical bitstream. This speeds up ui display and, if Content-Length is also set, allows faster seeking dispatch over remote protocols by priming the binary search with an initial average bitrate.

The header specifies the duration of a temporal-tracked media resource in decimal seconds, e.g.

  Content-Duration: 2189.242

This is intended to be the playback duration of the resource, regardless of any time offset in internal timestamps.

Older applications used X-Content-Duration instead. This SHOULD be supported by user agents for backwards compatibility with older server implementations, but new servers should use Content-Duration. This page is a draft spec for registering that message header.

Question: should we allow the [[[DDD]:HH]:MM]:SS.sss format as well? It's more work to parse, but seems more natural for a message header.

PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE

  Header field name: Content-Duration
     The name proposed for the new header field.  This SHOULD conform
     to the field name specification details noted in Section 4.1.
  Applicable protocol: http (applicable to mime in general?)
     Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616),
     "netnews" (RFC 1036), or cite any other standards-track RFC
     defining the protocol with which the header is intended to be
     used.
  Status: provisional
     Specify: "provisional".  This will be updated if and when the
     header registration is subsequently moved to the permanent
     registry.
  Author/Change controller: Ralph Giles <giles@xiph.org> Xiph.org Foundation
     The name, email address, and organization name of the submission
     author, who may authorize changes to or retraction of the
     repository entry.  A postal address, home page URI, telephone and
     fax numbers may also be included.
     If the proposal comes from a standards body working group, give
     the name and home page URI of the working group, and an email
     address for discussion of or comments on the specification.
  Specification document(s): http://wiki.xiph.org/ContentDuration
     Reference to document that specifies the header for use with the
     indicated protocol.  The document MUST be an RFC, a current
     Internet-draft or the URL of a publicly accessible document (so
     IANA can verify availability of the specification).  An indication
     of the relevant sections MAY also be included, but is not
     required.
  Related information:
     Optionally, citations to additional documents containing further
     relevant information.