Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
"Timothy B. Terriberry" <tterribe@xiph.org> Wed, 11 July 2012 18:18 UTC
Return-Path: <tterribe@xiph.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4E621F85EA for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 11:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.477
X-Spam-Level:
X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8xoLKs88o10 for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 11:18:54 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 057B021F85B4 for <codec@ietf.org>; Wed, 11 Jul 2012 11:18:53 -0700 (PDT)
Received: from [10.250.6.54] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 7C046F21F6 for <codec@ietf.org>; Wed, 11 Jul 2012 11:19:23 -0700 (PDT)
Message-ID: <4FFDC3AB.8020900@xiph.org>
Date: Wed, 11 Jul 2012 11:19:23 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1
MIME-Version: 1.0
To: codec@ietf.org
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FF61755.5060205@thaumas.net> <4FF62970.5070704@xiph.org> <20120711053951.GL18009@audi.shelbyville.oz>
In-Reply-To: <20120711053951.GL18009@audi.shelbyville.oz>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2012 18:18:54 -0000
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. > 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. 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. > The defined values for Channel Mapping Family might benefit from > being moved to that field's description in 5.1 rather than being > left until the latter part of 5.1.1 - or at least moved to the > top of 5.1.1 where it flows directly on from that, since we refer > to the special cases for family 0 in the descriptions of the > mapping table fields, without having introduced family 0 except > by way of saying "it's special". I think I originally pushed it back because I wanted a clear definition of "decoded channels" vs. "output channels" in place before I tried to describe the restrictions associated with each mapping family. Upon re-reading, I agree this order creates some other problems, though. However, I do think it's beneficial to keep it in its own subsection.
- [codec] Fwd: New Version Notification for draft-t… Timothy B. Terriberry
- Re: [codec] Fwd: New Version Notification for dra… Kevin P. Fleming
- Re: [codec] Fwd: New Version Notification for dra… Timothy B. Terriberry
- Re: [codec] Fwd: New Version Notification for dra… Ralph Giles
- Re: [codec] Fwd: New Version Notification for dra… Timothy B. Terriberry
- Re: [codec] Fwd: New Version Notification for dra… Jean-Marc Valin
- Re: [codec] Fwd: New Version Notification for dra… Timothy B. Terriberry
- Re: [codec] Fwd: New Version Notification for dra… Jean-Marc Valin
- Re: [codec] Fwd: New Version Notification for dra… Ron
- Re: [codec] Fwd: New Version Notification for dra… Ron
- Re: [codec] Fwd: New Version Notification for dra… Gregory Maxwell
- Re: [codec] Fwd: New Version Notification for dra… Ralph Giles
- Re: [codec] Fwd: New Version Notification for dra… Timothy B. Terriberry
- Re: [codec] Fwd: New Version Notification for dra… Timothy B. Terriberry
- Re: [codec] Fwd: New Version Notification for dra… Ron
- Re: [codec] Fwd: New Version Notification for dra… Timothy B. Terriberry
- Re: [codec] Fwd: New Version Notification for dra… Gregory Maxwell
- Re: [codec] Fwd: New Version Notification for dra… Ron
- Re: [codec] Fwd: New Version Notification for dra… Ron
- Re: [codec] Fwd: New Version Notification for dra… Ralph Giles