[ogg-dev] Skeleton 4.0 final draft

Chris Pearce chris at pearce.org.nz
Thu Jun 10 18:25:01 PDT 2010

  On 11/06/2010 1:06 p.m., Benjamin M. Schwartz wrote:
> On 06/10/2010 08:16 PM, Chris Pearce wrote:
>> I have no plans to change the 'index' packet format further.
> I have proposed an alternative formulation of the index packet at
> http://github.com/bemasc/OggIndex/blob/master/Proposed-modified-spec.txt
> That repository also contains a working implementation of the alternative
> formulation.  I have reviewed the details with Chris extensively.

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 

We're better of with a simpler approach because:

   1. Most other existing index schemes have very simple index format.
   2. Simple schemes are easier to implement. We don't want to do
      anything to discourage people to implement support!
   3. The more complex schemes are, the more likelihood of bugs during
   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.

I don't want to disparage Benjamin's work; he achieved an impressive 
level of compression, I just don't think the extra complexity is worth it.

Chris P.

> I believe that this formulation (which I have dubbed "Skeleton A-mod" in
> an effort to avoid confusion) offers a significant advantage in employing
> a simple lossy coding scheme that does not greatly impact seeking
> performance.  This technique reduces the amount of space required for the
> index by a large factor, typically at least 4.  It also provides a more
> explicit guarantee about the location of target information relative to
> the seek point, and is designed to work well for rolling-intra streams.
> I appreciate that Chris may be more interested in getting the system
> standardized quickly than in designing the optimal standard; I think this
> is a respectable position.  I am not very familiar with Xiph.org's
> procedures for standardization, so I await advice from others on how to
> proceed.
> --Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20100611/4a6fdcc5/attachment.htm 

More information about the ogg-dev mailing list