[theora] X-Content-Duration HTTP header

[Ralph Giles]

2009/12/30 Chris Pearce <chris at pearce.org.nz>:

> 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?

Sub-millisecond errors aren't noticeable with video (unless they
accumulate) but they're very noticeable with audio, for example if the
durations are used to schedule playback. If the clips are designed to
loop together, there will be a glitch from the missing samples (a
millisecond is 48 or 44.1 samples for normal audio).

In general, frame/sample accurate durations are the best one can do
for a given logical stream, so I think it's best to base the duration
on that.

>> 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?

It's enough with a millisecond timebase. It's not with something like
theora which has a granule shift. But that wasn't what I meant; the
important part was "THz" not "2020". You're designing skeleton
assuming current audio and video content, but Ogg is a general
container for time-sequential data. Already, today, things like
network traffic or radio signals can present the "shorter than the
minimum Content-Duration" problem you pointed with integer
seconds...because the elements are less than a millisecond long, and
timed in nanoseconds.

> http://github.com/cpearce/OggIndex/blob/master/Skeleton-3.1-Index-Specification.txt

Aha, thanks! Are you interested in maintaining another mirror at git.xiph.org?

> 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... :(

Oops. You *could* create another account, of course...

Cheers,
 -r