[theora] X-Content-Duration HTTP header

[Ralph Giles]

2009/12/30 Conrad Parker <conrad at metadecks.org>:

> Durations, timestamps etc. are usually best expressed as
> timespec:hh:mm:ss::ff with the framerate given in the timespec (eg.
> smpte-30:04:23:31::07)

Is the double colon standard? I've always seen timecodes written just
HH:MM:SS:FF. It does distinguish frames from seconds, but
media-fragment style smpte-* prefix already does that.

Some systems support a .ff for fractional frames in smpte timecode.
This is probably for audio sync.

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

> Can you give an example of an application which will read over HTTP
> which requires such accurate duration?       [...]
> Only non-critical things, like seek bars, should rely on it, meta data
> is inherently untrustworthy.

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.

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

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. I
couldn't find your 3.1 skeleton draft in the wiki or in annodex svn.

 -r