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

Ron <> Sun, 15 July 2012 12:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5CDD21F85B4 for <>; Sun, 15 Jul 2012 05:46:42 -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 lzv-xfEbiBIY for <>; Sun, 15 Jul 2012 05:46:42 -0700 (PDT)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by (Postfix) with ESMTP id D371721F85AC for <>; Sun, 15 Jul 2012 05:46:41 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAHK7AlB20o5H/2dsb2JhbABFuCmBCIIgAQEEATocIQcLCxguFBgNiD4FugCLQIJmgxwDiEmFHodTAZAGgm8
Received: from (HELO audi.shelbyville.oz) ([]) by with ESMTP; 15 Jul 2012 22:17:20 +0930
Received: from localhost (localhost []) by audi.shelbyville.oz (Postfix) with ESMTP id 28EFF4F8F3 for <>; Sun, 15 Jul 2012 22:17:19 +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 KjsOISksdOVu for <>; Sun, 15 Jul 2012 22:17:18 +0930 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 6B3594F8FE; Sun, 15 Jul 2012 22:17:18 +0930 (CST)
Date: Sun, 15 Jul 2012 22:17:18 +0930
From: Ron <>
Message-ID: <20120715124718.GY18009@audi.shelbyville.oz>
References: <> <> <> <> <20120711053951.GL18009@audi.shelbyville.oz> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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 12:46:42 -0000

On Wed, Jul 11, 2012 at 11:19:23AM -0700, Timothy B. Terriberry wrote:
> Ron wrote:
> >might from a first linear reading of the document.  It probably
> >could usefully be split into some subsections - with the pre-skip
> >definition in section 5 then providing a back reference to 4.1
> >about how it fits together with granule position etc.
> Yes, this is a pretty good idea. Feel free to offer some suggestions
> for section titles, etc.

As currently written, the logical sub-section breaks to me look
something like:

 4.1 - Pre-skip
   There is some amount of latency introduced ...

 4.2 - PCM sample position
   The PCM sample position is ...

The paragraph beginning "Vorbis streams use a granule position", should
perhaps become a footnote, or possibly move up into section 4.1.  That
seems like useful information for people who already understand the
Vorbis Ogg mapping, but may just add confusion to people who first look
at this in the context of Opus.  As part of the rationale for why we
have preskip there is useful information in it that should be included
somewhere here though.

 4.3 - EOS trimming
   The page with the 'end of stream' flag ...

 4.4 - Streams beginning after time 0
   The granule position of the first audio data page with a completed
   packet MAY be larger ...

   [Someone might have a better section title for this ...]

> >Section 6 I suspect should be folded back into appropriate places
> >in the rest of the document and that section dropped entirely.
> >That was kind of a placeholder for various issues that came up in
> >discussion, but didn't otherwise already have a place in the wiki
> >where it obviously fit at the time.
> The first paragraph probably belongs in Section 4 somewhere, but I
> worried that introducing it too early would confuse the issue with
> pre-skip, when the concepts are totally independent. I should
> probably also add a sentence about what to do if the seek point is
> before the first 80 ms.

We could maybe add a: 4.5 - Seeking within a stream
and elaborate a little on general best practices for that there too.
Since this seems to be something people commonly do badly on their
first attempt, despite good methods having been detailed elsewhere.
Some references to those might be enough.

> The rest (discussing packet size limitations) arguably belongs in
> Section 3, but it really is a complete aside. Having it off the
> critical path for "things you need to understand to implement this
> specification" is an advantage, I think.
> I may move the first paragraph out and re-title Section 6 to reflect
> the fact that it just discusses packet size limitations.

Yes, that makes good sense to me.  I agree that once the first paragraph
is taken out of section 6, the rest does fairly coherently talk about
just packet size issues, and is distinct enough from everything else to
put in its own specific section as a final discussion point.