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

Mark Harris <> Sat, 30 August 2014 23:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 329F11A6EDE for <>; Sat, 30 Aug 2014 16:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 01dXlHEU8_q8 for <>; Sat, 30 Aug 2014 16:03:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D6941A6EDC for <>; Sat, 30 Aug 2014 16:03:38 -0700 (PDT)
Received: by with SMTP id rl12so1372431iec.9 for <>; Sat, 30 Aug 2014 16:03:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=JSkW8r96Ze3zB3T4vq+CQz8Ocg2uvGcySuF+APkLhgk=; b=jnBzme61jh15noiGyxhFmSTASSrRccmXB6IaOCJmRzA52TJdddnsWWw1ScPrnA2Ym9 PvZKsSHOTyG7mFEI7aJA73epVmsiRY0m82Z0DxWyrv3iOHJPn1nRMk/Jk3FJSBw+VasO Xb0vu8HGVwk0dkW3Pse9UFOxNQLd8xxOfKyFh9dsFqZuhYvcghCIgXbV/6Q85NXUoX4f 8JYwYta3YjkpFyJLQ3ExDAoPC0Se/Tvu2OsbKwsjkDzpZhtwaPFWmYGLh2mjW9K8c6Mz 8HqIG1tPdS7qmHzdlZyZy/lo8d4d6wvD6kg+ImME7u4yeGvKrz3ffsaakkCaYGr4KErR pG0w==
MIME-Version: 1.0
X-Received: by with SMTP id n6mr12681531igj.24.1409439816460; Sat, 30 Aug 2014 16:03:36 -0700 (PDT)
Received: by with HTTP; Sat, 30 Aug 2014 16:03:36 -0700 (PDT)
In-Reply-To: <20140830162119.GG326@hex.shelbyville.oz>
References: <> <> <> <20140830072745.GF326@hex.shelbyville.oz> <> <20140830162119.GG326@hex.shelbyville.oz>
Date: Sat, 30 Aug 2014 16:03:36 -0700
X-Google-Sender-Auth: vI73STtZ5FE_DRALdjLdEwjHiAY
Message-ID: <>
From: Mark Harris <>
To: "" <>
Content-Type: text/plain; charset="UTF-8"
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 23:03:41 -0000

Ron wrote:
> 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.

I have no objection to adding the pictures in a separate multiplexed
stream; in fact that is my proposal (3).  That is the only one that I
did not specify with enough detail to create interoperable
implementations, because it is a much larger change to the way that
opus-tools currently attaches pictures, and I therefore did not expect
that approach to be favored.  However if there is consensus that that
is the way to go, I can propose something more concrete, and in that
case the only change that I think is needed in the Ogg Opus draft is
to allow these streams in an "Ogg Opus file".  In particular, when
attached pictures are not specifically mentioned, no requirements or
recommendations (such as recommended file extension) should depend on
whether attached pictures are present.

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

Oh I agree completely that this should ideally not be codec-specific.
Not only attached pictures but also tags such as TITLE and ARTIST,
channel mapping, output gain, and loudness/gain required for
normalization would ideally all be maintained by the container and not
be specific to any codec.  The reason that I proposed adding attached
pictures in the codec-specific stream is because Ogg does not provide
metadata at the container level, and all of the metadata I mentioned
is currently being stored on a codec-specific page of the
codec-specific stream.  I would love to see all of this moved out of
the codec-specific stream and into an extensible codec-independent
format elsewhere in the file, and the codec-specific stream reduced to
only what is truly codec-specific, but that is not the direction that
was taken for other metadata.

 - Mark