[theora] X-Content-Duration HTTP header

[Chris Pearce]

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 
so! :)

> 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,
Chris P.