[theora] X-Content-Duration HTTP header

[Chris Pearce]

On 12/31/2009 12:43 PM, Ralph Giles wrote:
> If this is only being used to prime the seek bar, than integer seconds
> are good enough, and we can just register a provisional http header
> referencing RFC 3803. It's already in the permanent registry for MIME,
> as documented in rfc 4021.
>    
Whole seconds is too coarse, we've encountered plenty of cases with 
HTML5 <audio> where people have short audio samples which are less than 
a second long, and having the duration rounded up or down way is annoying.

>> 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! :)
>>      
> Ooch, please don't do it that way. milliseconds isn't accurate for
> either audio *or* video,
The millisecond timestamps are calculated from the packets' granulepos. 
Are timestamps calculated from packets' granulepos not accurate? Can you 
give an example where a fraction of a millisecond would matter and would 
be noticeable to a human observer?

I used milliseconds because all seek operations and frame-timestamping 
I've done so far have been rounded to and done in those units. I had 
wondered if it was better to store the timestamps as fractions, similar 
to how the existing skeleton header packet does for its 
"Presentationtime" and Basetime fields. It would be a pretty easy change 
at this stage.

> so it would just be more sloppy metadata an
> application can't really use outside of casual display and playback.
> Besides, what if it's 2020 and I want to store a packet dump from my
> THz router in Ogg?
>    
Are 64bit granulepos not large enough to represent timestamps after 
2020? That would be a fundamental problem with Ogg that needs to be 
addressed in Ogg?

> Is this per chain segment, or per logical stream? Each logical stream
> generally has a duration in terms of samples or clock ticks which is
> convertible to seconds through a rational sample rate which is already
> stored in skeleton. Combining them is a little messy, since you need
> rules for what do do when they don't align at the ends, and finding
> the least common multiple between the rates makes for big numbers.
This is per chain segment. I store the start/presentation time of the 
first sample/frame in the segment. This is the lowest start time of all 
streams' first samples in the segment. I also store the end time of the 
last sample in the segment, again of all streams. The stored start/end 
times may be for different streams, so I'm assuming that a player will 
play provided at least one stream still has samples. These timestamps 
are stored in milliseconds, as calculated from the streams' packets' 
granulepos.

>   I couldn't find your 3.1 skeleton draft in the wiki or in annodex svn.
>    
http://github.com/cpearce/OggIndex/blob/master/Skeleton-3.1-Index-Specification.txt

I lost my password for my Xiph wiki account, and the password reset 
hasn't emailed me a new one yet, so I can't update the xiph wiki... :(


Thanks,
Chris P.