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 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20100610/5acf8f67/attachment.pgp
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 complex. 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 implementation. 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
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... 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. 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 here. --Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20100610/60300621/attachment.pgp