[ogg-dev] Skeleton 4.0 final draft
chris at pearce.org.nz
Thu Jun 10 20:03:01 PDT 2010
On 11/06/2010 1:48 p.m., Benjamin M. Schwartz wrote:
> On 06/10/2010 09:25 PM, Chris Pearce wrote:
>> I looked at Benjamin's proposal, it does indeed produce much better
>> compression. However I decided not to use it because I felt it was too
> For the record, the Skeleton 4.0, as implemented by OggIndex, currently
> requires a multi-round iteration to produce. The encoder produces the
> index, then shifts the file content downstream to make room for the index
> packet ... but doing so changes the byte offsets, forcing the index to be
> recalculated. This potentially changes the length of the index, which
> forces the output to be shifted again, and changes the byte offsets again...
Right, this is an implementation decision. You need to encode the index
usually twice, in rare cases three times. It is cheap and easy to just
recall the function to recalculate the index. I'd rather do that than to
mess around figuring out the perfect size up front. There's nothing
stopping me from doing something cleverer here, except my desire to
apply my cleverness elsewhere.
> Skeleton A-mod solves this problem, separately from the issue of the
> variable-length coding of the index, by coding the initial offset in fixed
Right, so I could encode the offset of the first keypoint with extra
empty bytes using my unicode-style-variable-byte-encoding, in order to
remove one potential re-encode. I decided there was no reason to bother
with this, since re-encoding the index was so cheap and easy.
> For a two hour movie with frequent keyframes, like on DVD, the index could
> easily be in excess of 50 KB, maybe even 100 KB.
As a data point here, I indexed a 2 hour 55 minute theora+vorbis movie I
have here with a 2000ms keyframe index interval, the index used 38404
bytes, for an overhead of 0.00184199%. I doubt any network capable of
playing this video in real time would notice an extra 37KB at the start
of the file.
> I should repeat that I think Chris's Skeleton 4.0 is a totally acceptable
> index implementation, and I'm not sure how to weigh the various tradeoffs
Thanks. As you correctly guessed, I want to wrap this up. We've spent
enough time on this. We have something that's good enough, let's ship it!
All the best,
More information about the ogg-dev