[theora] X-Content-Duration HTTP header
chris at pearce.org.nz
Wed Dec 30 13:52:57 PST 2009
On 12/30/2009 10:25 PM, Gregory Maxwell wrote:
> The floating point values being used in X-Content-Duration can't
> *exactly* express many durations, for example 130 frames at 30 fps.
> Very close but not quite exact may be suitable for scaling a seek bar
> in a browser, but it's not hard to imagine applications where the
> *exact* duration is needed.
Can you give an example of an application which will read over HTTP
which requires such accurate duration? Wouldn't anything requiring that
level of accuracy buffer or download the file and calculate it itself
anyway? I'd tend to think that any application which requires the exact
duration would ignore the X-Content-Duration HTTP header, and calculate
the duration itself, for fear of the reported duration being incorrect.
Only non-critical things, like seek bars, should rely on it, meta data
is inherently untrustworthy.
Also the ogg segment's duration will be included in the skeleton3.1
(keyframe index) header packet. So hopefully the X-Content-Duration
header will be required less in future anyway (the header would still be
useful in the presence of ogg chains though). I spec'd the skeleton 3.1
duration field as being encoded in whole milliseconds. I'm open to being
persuaded we should encode it otherwise, now would be a good time to do
> Should an opportunity be taken to support a rational number for
> duration like is used for FPS?
That sounds like over complicating things. Do any tools currently exist
which would output the duration accurately in this format? A simple
hh:mm:ss.ms format would be simpler to understand and work with; simpler
than the current ss.ms format of X-Content-Duration. Also oggz-info
already outputs a Content-Duration line in the hh:mm:ss.ms format, so it
would be easy for webmasters to setup.
All the best,
More information about the theora