[ogg-dev] Skeleton 4.0 final draft
Benjamin M. Schwartz
bmschwar at fas.harvard.edu
Thu Jun 10 18:48:28 PDT 2010
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...
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
What I'm trying to say is: the complexity is mixed bag.
> 4. The existing OggIndex format only takes up a fraction of a percent
> of the media size. Over a network capable of playing video, it
> won't be noticed.
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. This would not be a
large fraction of the total size (probably at least several hundred MB)
but because the index comes at the front of the file it would delay the
arrival of video data. Because of TCP connection ramp-up, this could
introduce a noticeable additional delay to begin playback, even on
connections with plenty of excess bandwidth.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20100610/60300621/attachment.pgp
More information about the ogg-dev