[ogg-dev] Skeleton 4.0 final draft

[Chris Pearce]

  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
>> complex.
> 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
> length.

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
> here.
>

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,
Chris P.