Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt

[Ron <[e-mail]>]

On Wed, Jul 11, 2012 at 09:45:17AM -0700, Gregory Maxwell wrote:
> Ron [[e-mail]]:
> > and I get a version 2 header that is several MB in size, should I
> > really just blindly accept that Nothing Is Wrong
> 
> Well—You'll blindly accept that nothing is wrong with
> several MB of junk in the comments or in Opus padding.

There is a chance that _might_ not actually be wrong though, for instance
there could be base64 encoded cover art in comments etc.  while a MB of
junk in the OpusHead packet would 'clearly' always be wrong.

What wasn't clear is how much more accurately I could bound that given
the "MUST accept extra header data" condition that was proposed.

> But, see RFC 3533. The initial header packet must be on a single
> page, so its limited by the container spec to 64K.

That RFC is actually a little handwavy on this detail, and mostly delegates
to the codec mapping to define what is a valid BOS packet.  It does say:

 So, a physical bitstream begins with the bos pages of all logical
 bitstreams containing one initial header packet per page, followed by
 the subsidiary header packets of all streams, followed by pages
 containing data packets.

But that's not a MUST, and hinges on 'containing' meaning the packet
completes on that page and is not continued to a subsequent page.

I agree that is the only sane interpretation for the current set of
mappings, where the BOS packet is quite small, and that it probably
was the original intention, but the stronger requirement is:

 The format of the bos page is dependent on the codec and therefore
 MUST be given in the encapsulation specification of that logical
 bitstream type.


So if we are going to add the condition:
"MUST accept new minor numbers which have additional data."

Then amending section 3 which says the BOS packet "MUST be placed alone"
to also explicitly explain that it "MUST complete on that page", at least
places a clear constraint on the amount of additional data that may ever
appear in some later version - and gives us a chance that application
authors won't just make up their own arbitrary 'sanity check' bounds
(or accept dozens of pages of carefully crafted rubbish) - which is the
main problem I worried we could be newly introducing here.

 Cheers,
 Ron