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

Ron <> Sun, 15 July 2012 14:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3701621F84E7 for <>; Sun, 15 Jul 2012 07:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bL21zGISXOkk for <>; Sun, 15 Jul 2012 07:09:46 -0700 (PDT)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by (Postfix) with ESMTP id CDEA721F84E1 for <>; Sun, 15 Jul 2012 07:09:45 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EADjOAlB20o5H/2dsb2JhbABFhWmyQIEIgiABAQQBIw8BIyEHCwsYAgImAgIUGA03iAcFqDaRVoEgiiAUglKCCoESA4hJhR6HUwGQBoJvgUY
Received: from (HELO audi.shelbyville.oz) ([]) by with ESMTP; 15 Jul 2012 23:40:26 +0930
Received: from localhost (localhost []) by audi.shelbyville.oz (Postfix) with ESMTP id DF8154F8F3 for <>; Sun, 15 Jul 2012 23:32:40 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([]) by localhost (audi.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id FJjhzlaBDKpV for <>; Sun, 15 Jul 2012 23:32:40 +0930 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 18F6E4F8FE; Sun, 15 Jul 2012 23:32:40 +0930 (CST)
Date: Sun, 15 Jul 2012 23:32:40 +0930
From: Ron <>
Message-ID: <20120715140124.GZ18009@audi.shelbyville.oz>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 15 Jul 2012 14:09:51 -0000

On Wed, Jul 11, 2012 at 09:45:17AM -0700, Gregory Maxwell wrote:
> Ron []:
> > 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.