[theora] Ogg index and Skeleton 4.0
chris at pearce.org.nz
Thu Apr 29 16:12:47 PDT 2010
On 29/04/2010 10:21 p.m., xiphmont at xiph.org wrote:
>>> I assume that the streams with and without 'keyframes' are clearly
>>> distinguished, correct?
>> A client which mapped serialnos to codecs could make this distinction. Why
>> would you need to?
> Just to have it in Skeleton somewhere so that you wouldn't necessarily
> need a list of codec mappings. There's the tension of the original
> design (always ask the codec programmatically) and the Skeleton
> (replicate the data when encoded so there's no need to ask the codec),
> so it seemed sensible to have this declared in the skeleton as well.
An index-assisted seek algorithm doesn't need to distinguish between a
keypoint which references a keyframe and one which references or a
non-keyframe. Why would you need this? Purely for the purposes of
providing more metadata? Would we want to also include flags for
discontinuous streams as well?
>>> Is the rational timebase required to have any relation to the timebase
>>> of the granulepos itself?
>> Not explicitly. I imagine an indexer would do so in order to preserve
>> accuracy though.
> OK. I'm not actually a fan of there being several ways to do things
> and just leaving it up to the implementor to figure out. Is there a
> reason not to just use the stream timebase?
Then we'd run into the Skeleton metadata vs codec tension above while
>> Beginning of bitstream, so 0 for the first segment, and from the start of
>> each fisbone packet in each subsequent segment/link in a chained ogg.
> This means you need to know how long the index will be before encoding
> any offsets. But the offsets are variable-length-encoded... How are
> you predicting index size?
So note that you don't need to fill the index packet, so if you
over-estimate the space needed for the index, provided you've not
overestimated too much, it's not a huge loss. If you do under estimate,
you can just start dropping keypoints out of your indexes until they fit.
My current approach in ffmpeg2theora is to estimate the number of
keypoints required as duration/keypoint_interval, and the size is then
5.1 * num_keypoints. This has seemed to work for me. There are probably
smarter approaches to estimating this, but I've not had the chance to it
yet. It's probably a function of the bitrate.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the theora