Re: [codec] draft-ietf-codec-oggopus: attached pictures

Ron <> Sat, 30 August 2014 07:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E4B811A884E for <>; Sat, 30 Aug 2014 00:27:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hy6B-Nhh6_J6 for <>; Sat, 30 Aug 2014 00:27:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 695A81A8854 for <>; Sat, 30 Aug 2014 00:27:49 -0700 (PDT)
Received: from (HELO mailservice.shelbyville.oz) ([]) by with ESMTP; 30 Aug 2014 16:57:48 +0930
Received: from localhost (localhost []) by mailservice.shelbyville.oz (Postfix) with ESMTP id 686D3FFF3F for <>; Sat, 30 Aug 2014 16:57:46 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([]) by localhost (mailservice.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id 3do3g6uvuGtQ for <>; Sat, 30 Aug 2014 16:57:45 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz []) by mailservice.shelbyville.oz (Postfix) with ESMTPS id B1CA1FF9AC for <>; Sat, 30 Aug 2014 16:57:45 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id A219A80470; Sat, 30 Aug 2014 16:57:45 +0930 (CST)
Date: Sat, 30 Aug 2014 16:57:45 +0930
From: Ron <>
Message-ID: <20140830072745.GF326@hex.shelbyville.oz>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 30 Aug 2014 07:27:52 -0000

On Fri, Aug 29, 2014 at 10:38:14PM -0700, Mark Harris wrote:
> Timothy B. Terriberry wrote:
> > We could also choose not to address this _here_, and instead continue to
> > defer to the existing vorbis-comment documentation. That wouldn't block
> > publication of this draft, and give us time to get implementation feedback
> > from the authors of media players and tools who would have to deal with this
> > change. I think this is the approach that I personally prefer.
> If this is not addressed prior to the standard being finalized, it
> becomes very difficult to add later.

I don't see why you think this is so?  Ogg was designed from the outset
to be easily extensible to carry and multiplex any sort of data.

There are all sorts of things that people might want to append to an
Opus track, and we clearly can't define, let alone imagine, all of
them here and today, since some of them haven't even been invented yet.

If you think something is missing from our ability to generically
extend this to include other 'non-opus' data at a later date, then
perhaps we ought to consider that.  But I think getting bogged down
on finalising the codec mapping to Ogg, because we don't have things
that weren't part of the charter of this group, that nobody has wanted
enough to raise before now, and that there are no published and tested
implementations of, is scope creep that ought to be a separate matter
of study, with a separate proposed standard as a properly generic
extension to RFC 3533 and/or RFC 5334.

Otherwise where does this stop?  We can't give people a published
Ogg mapping for Opus until we have optimal support for embedded
pony holograms?  I'm sure someone somewhere thinks that's a very
important feature.  Like alternate image encodings though, I don't
see why a standard for that can't be created later that will work
in a standard way for anything in an Ogg container, not just Opus.
Which seems like a far better outcome than kludging something in
here at the last minute, doesn't it?

What are we missing that makes that impossible?