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

Ralph Giles <giles@thaumas.net> Wed, 11 July 2012 17:29 UTC

Return-Path: <giles@thaumas.net>
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 6BE5111E8120 for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 10:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 nL1Y1JGQuKoF for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 10:29:52 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9E1611E8107 for <codec@ietf.org>; Wed, 11 Jul 2012 10:29:52 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so2465547pbc.31 for <codec@ietf.org>; Wed, 11 Jul 2012 10:30:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=thHwFxYSSTcuh/ajSoUxPCC6uRWrV6uSguxe+4m5ZjQ=; b=K7qBudNWvOWci7zWmBvilU/sAWc4AFhd5YML48/inNGgH5ryJwipJgXHzH08rqksrM HRt6lxugTKPqR/w++w029aoIOIHQj+NfBR4w3m6Azygrz0eo9LN7kCQ3MlH3173jzrjL mZduM76Lqogv6cPfce5FTiP7CjbHS8jwC+j0UVf2U9+Mr7C+NOwVP7tRtAp14Zn+K4Yf GOdDN1LmeGl/WudDUZAuvSzn4tqUDn4syAjR4Ym8kN4sdepEiDdDivtt76B3mPNwxFHw wELKgANxpbZuM52RxWVZazKtAr9GUEbIxfHK0Q34LXwkh35L0P5apbCb/1BwBcDyqkcG Oy8A==
Received: by 10.68.223.138 with SMTP id qu10mr80997311pbc.50.1342027823855; Wed, 11 Jul 2012 10:30:23 -0700 (PDT)
Received: from Glaucomys.local ([64.213.70.194]) by mx.google.com with ESMTPS id ql3sm2066205pbc.72.2012.07.11.10.30.21 (version=SSLv3 cipher=OTHER); Wed, 11 Jul 2012 10:30:22 -0700 (PDT)
Message-ID: <4FFDB82D.9000306@thaumas.net>
Date: Wed, 11 Jul 2012 10:30:21 -0700
From: Ralph Giles <giles@thaumas.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Gregory Maxwell <gmaxwell@juniper.net>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FFB851E.7040906@mozilla.com>, <4FFCD7BC.6000906@xiph.org> <BCB3F026FAC4C145A4A3330806FEFDA940BEEE25FE@EMBX01-HQ.jnpr.net>
In-Reply-To: <BCB3F026FAC4C145A4A3330806FEFDA940BEEE25FE@EMBX01-HQ.jnpr.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQn63YIRsz8uxYLTjpsL03oj6oF/m2JAQ9L4egOvmmtFurbSqS7STvJwoiP8CNDeFQ60RsuX
Cc: "codec@ietf.org" <codec@ietf.org>
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 17:29:53 -0000

On 12-07-11 9:45 AM, Gregory Maxwell wrote:

> But, Opus is new and hits some new applications and it
> would seem to be foolish to leave no graceful way out
> in the case of currently unanticipated needs.

Another versioning example, although it doesn't address the length
issue: The draft defines three channel mapping familes which give
semantic meaning to the various output channels, and specifies that any
unrecognized channel mapping should be treated like mapping 255, which
is discrete multichannel with no specific channel meanings.

If an a new surround audio encoding became popular, like an ambisonic
expansion or a 24 speaker configuration for immersive environments, a
revision of this specification could define a new channel mapping family
for that encoding. But, and this is something I think the draft could
describe more clearly, encoders producing files with that family number
could reasonably increment the minor version nibble to indicate a
compatible change. This would signal to updated decoders how to
interpret the new channel mapping family value, while older decoders
would produce discrete output without confusion.

> No one who's contributed to the draft so far is new at this,
> and, apparently, based on the collective experience with
> vorbis, speex, flac, theora, (and the many non Ogg formats
> we've all worked with), it doesn't appear that there will
> ever need to be anything added to the header.

This is my expectation as well. I think it's still valuable to specify
decoders MUST ignore extra data at the end of the header packets so
later drafts can take advange of the extension flag if it is needed.

 -r