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

Ron <> Sat, 30 August 2014 16:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A62341A8A99 for <>; Sat, 30 Aug 2014 09:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PS1tbDbKxhUl for <>; Sat, 30 Aug 2014 09:21:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A6F971A8A96 for <>; Sat, 30 Aug 2014 09:21:23 -0700 (PDT)
Received: from (HELO mailservice.shelbyville.oz) ([]) by with ESMTP; 31 Aug 2014 01:51:22 +0930
Received: from localhost (localhost []) by mailservice.shelbyville.oz (Postfix) with ESMTP id 6A3EBFFF3F for <>; Sun, 31 Aug 2014 01:51:20 +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 ITMFH0taKVeR for <>; Sun, 31 Aug 2014 01:51:19 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz []) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 9869EFF8BF for <>; Sun, 31 Aug 2014 01:51:19 +0930 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 820B380470; Sun, 31 Aug 2014 01:51:19 +0930 (CST)
Date: Sun, 31 Aug 2014 01:51:19 +0930
From: Ron <>
Message-ID: <20140830162119.GG326@hex.shelbyville.oz>
References: <> <> <> <20140830072745.GF326@hex.shelbyville.oz> <>
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 16:21:25 -0000

On Sat, Aug 30, 2014 at 08:05:56AM -0700, Mark Harris wrote:
> Ron wrote:
> > On Fri, Aug 29, 2014 at 10:38:14PM -0700, Mark Harris wrote:
> >> 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.
> Yes, arbitrary binary data is allowed by Ogg, and none of my proposals
> involved changes to Ogg.  This is about Ogg Opus files as defined by
> the draft draft-ietf-codec-oggopus-04.  The current version of the
> draft does include some binary metadata within an Ogg Opus stream,
> such as channel mappings, but does not provide any mechanism for
> adding additional metadata to the Ogg Opus stream in a binary format.
> Furthermore the current draft does not permit an Ogg Opus file to
> contain any other multiplexed streams (section 10).

Am I reading a different Section 10 to you?
I don't see anywhere that it prohibits that, and it explicitly defers
to the other RFCs which define how that should be done.

All it says is they are 'not strictly "Ogg Opus files"' - in the same
way that vorbis muxed with theora (or anything else) are "not strictly
Vorbis files".  You use the same mapping as defined here for the Opus
streams, and include whatever else you want along with them.

People have already been doing this for video with Opus.

> > What are we missing that makes that impossible?
> If the draft included a way to add arbitrary binary metadata to the
> Ogg Opus stream, or allowed an Ogg Opus file to contain attached
> pictures that are stored in another multiplexed stream, then the
> details of the picture format could be specified outside of this
> specification.

The OggOpus draft refers to the RFCs which define how to do that.
Which is why I'm suggesting that one option if you want still
pictures, is to define a generic Ogg mapping for them - which could
then be used with any other format that also has an Ogg mapping,
including this one.

There may be better ways to do that, but any optimal way should not
be Opus specific, it should be reusable for any Ogg stream.  This
standard shows you the mapping for an Opus audio stream.  Ogg lets
you combine that with any other stream that anyone might define in
the future.

Since the number of possible permutation for that is unbounded, it
makes perfect sense to me that each reusable part should be defined
separately, and we already have the general rules for combining them.

If there's something in this draft that would block that somehow,
I'm not seeing it yet.  If the codec mapping itself is ok (and we've
got lots of implementations of it now, with no new issues shaking
out from them about that part of it), then anything extra is really
just a "how do we make this work with RFC 3533" problem, isn't it?