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

Mark Harris <mark.hsj@gmail.com> Sat, 30 August 2014 15:05 UTC

Return-Path: <markh.sj@gmail.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1051A8A64 for <codec@ietfa.amsl.com>; Sat, 30 Aug 2014 08:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_gt7nwG1t8i for <codec@ietfa.amsl.com>; Sat, 30 Aug 2014 08:05:57 -0700 (PDT)
Received: from mail-ig0-x242.google.com (mail-ig0-x242.google.com [IPv6:2607:f8b0:4001:c05::242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B631A8A63 for <codec@ietf.org>; Sat, 30 Aug 2014 08:05:56 -0700 (PDT)
Received: by mail-ig0-f194.google.com with SMTP id r2so1321191igi.1 for <codec@ietf.org>; Sat, 30 Aug 2014 08:05:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=C24nNYkPbv0tInvung+bn4yrC//GgrRhabMWMLTji7I=; b=N2BykkkfFo4I4d4f7xYYj2gt/BEh3JJwp7imSGNqIS4Dl7JxAYe/rO/HfIvhYeuTLi n7X3k7ItVGPQAyQfwjuYxnHlbjARMEvHjZeiCNfCgVbx25E6UVFXDi7U9QCdryJb81Pu aATrVCFWAkA80CBVzpoqOVQJv1Gcfz+ulU2tuSiA8VzNbFgOZr4xqlBS2k6iqrQEc66f ivVvQ8nkEms3MoRU7d6BSFLvjK4gDOu78aeaAYUFqakKcfbgIwcNlRKvnEFF7MZxdHn4 ZdL6KDuNEHDzqBUZWmsN0gZPQYlxfq/hGf44tWgYPukzRLe4FGGImfugl9aN3SJTMDV9 NJCQ==
MIME-Version: 1.0
X-Received: by 10.50.26.66 with SMTP id j2mr11167865igg.45.1409411156273; Sat, 30 Aug 2014 08:05:56 -0700 (PDT)
Sender: markh.sj@gmail.com
Received: by 10.107.1.81 with HTTP; Sat, 30 Aug 2014 08:05:56 -0700 (PDT)
In-Reply-To: <20140830072745.GF326@hex.shelbyville.oz>
References: <CAMdZqKEOfNEXEAGjyx2+5xW7QkrA2ekNVZym+ZLRsNoA0+cSYQ@mail.gmail.com> <53FBBCA1.8060708@xiph.org> <CAMdZqKGRjcj8L+Wqh+pZ2KstDRMWZi6ejW8RqJLchXOiCD3AOw@mail.gmail.com> <20140830072745.GF326@hex.shelbyville.oz>
Date: Sat, 30 Aug 2014 08:05:56 -0700
X-Google-Sender-Auth: O8PsU5swaSc9yaGyZn2Nd14IlUQ
Message-ID: <CAMdZqKEztz_b_tGkGAqWMkZ63wgb9MVswozSyxiJDQOV_TkuNA@mail.gmail.com>
From: Mark Harris <mark.hsj@gmail.com>
To: "codec@ietf.org" <codec@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/A9HYLwtFY4CjGxsOUNIrfF_V0EY
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 30 Aug 2014 15:05:58 -0000

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

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

 - Mark