ContentDuration: Difference between revisions
(→PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE: fill in some defaults) |
(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.