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

Ron <ron@debian.org> Thu, 12 July 2012 00:39 UTC

Return-Path: <ron@debian.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 0DD2B11E8176 for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 17:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qosv2efsMz1 for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 17:39:56 -0700 (PDT)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id C2E6C11E816D for <codec@ietf.org>; Wed, 11 Jul 2012 17:39:55 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAIoc/k95LQwo/2dsb2JhbABFt3mBCIIgAQEEATocIRILGC4UGA2IPgW+C4tAhW4DiEmFHodSAZAGgm8
Received: from ppp121-45-12-40.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.12.40]) by ipmail06.adl2.internode.on.net with ESMTP; 12 Jul 2012 10:10:25 +0930
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 8CECE4F8F3 for <codec@ietf.org>; Thu, 12 Jul 2012 10:04:39 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fuK2VavjGANr for <codec@ietf.org>; Thu, 12 Jul 2012 10:04:38 +0930 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id A22064F8FE; Thu, 12 Jul 2012 10:04:38 +0930 (CST)
Date: Thu, 12 Jul 2012 10:04:38 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20120712003438.GR18009@audi.shelbyville.oz>
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> <4FFDB82D.9000306@thaumas.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4FFDB82D.9000306@thaumas.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
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: Thu, 12 Jul 2012 00:39:57 -0000

On Wed, Jul 11, 2012 at 10:30:21AM -0700, Ralph Giles wrote:
> 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.

This was the only concrete thing that really occurred to me which we
_might_ plausibly get value out of the "minor version" with -- however
the draft explicitly says "General-purpose players SHOULD NOT attempt
to play these (family 255) streams" -- which kind of conflicts with
the notion that minor version increments are backward compatible and
existing decoders SHOULD accept them and be able to play them.

If we add a new mapping family, then we sort of have created a stream
that is not really backward compatible with previously existing code.

The minor version in this case at best might act as a sort of crude
checksum, that says family 7 really is supposed to be defined, rather
than being an encoding error - but if we use it like that, we're going
to run out of minor versions long before we run out of new mapping
families that we might add ...  and what will we do then?

One alternative is we could just revise the spec to define new families
without bumping the minor version.  Since they'd basically act as you
suggest for things that don't recognise them anyway in that case.

> > 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.

I likewise don't actually expect we will ever find a reason to bump
the minor version (though defining new mapping families seems like a
real possibility), which is mostly why I wonder if this is really the
best mechanism for enabling extensions that we cannot yet imagine,
and mostly doubt we'll need ...

 Ron