[theora] X-Content-Duration HTTP header
chris at pearce.org.nz
Wed Dec 30 16:28:53 PST 2009
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'
> I couldn't find your 3.1 skeleton draft in the wiki or in annodex svn.
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... :(
More information about the theora