<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 11/06/2010 1:06 p.m., Benjamin M. Schwartz wrote:
    <blockquote cite="mid:4C118BFD.1040105@fas.harvard.edu" type="cite">
      <pre wrap="">On 06/10/2010 08:16 PM, Chris Pearce wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">I have no plans to change the 'index' packet format further.
</pre>
      </blockquote>
      <pre wrap="">
I have proposed an alternative formulation of the index packet at

<a class="moz-txt-link-freetext" href="http://github.com/bemasc/OggIndex/blob/master/Proposed-modified-spec.txt">http://github.com/bemasc/OggIndex/blob/master/Proposed-modified-spec.txt</a>

That repository also contains a working implementation of the alternative
formulation.  I have reviewed the details with Chris extensively.

</pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    We're better of with a simpler approach because:<br>
    <ol>
      <li>Most other existing index schemes have very simple index
        format.</li>
      <li>Simple schemes are easier to implement. We don't want to do
        anything to discourage people to implement support!</li>
      <li>The more complex schemes are, the more likelihood of bugs
        during implementation.</li>
      <li>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.<br>
      </li>
    </ol>
    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.<br>
    <br>
    <br>
    Chris P.<br>
    <br>
    <blockquote cite="mid:4C118BFD.1040105@fas.harvard.edu" type="cite">
      <pre wrap="">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

</pre>
    </blockquote>
    <br>
  </body>
</html>