From XiphWiki
Revision as of 21:21, 29 December 2009 by Rillian (talk | contribs) (Q: support HH:MM:SS?)
Jump to navigation Jump to search

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.


  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
  Status: provisional
     Specify: "provisional".  This will be updated if and when the
     header registration is subsequently moved to the permanent
  Author/Change controller: Ralph Giles <> 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):
     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
  Related information:
     Optionally, citations to additional documents containing further
     relevant information.