Re: [codec] draft-ietf-codec-oggopus: attached pictures
Ron <ron@debian.org> Sat, 30 August 2014 16:21 UTC
Return-Path: <ron@debian.org>
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 A62341A8A99 for <codec@ietfa.amsl.com>; Sat, 30 Aug 2014 09:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS1tbDbKxhUl for <codec@ietfa.amsl.com>; Sat, 30 Aug 2014 09:21:24 -0700 (PDT)
Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id A6F971A8A96 for <codec@ietf.org>; Sat, 30 Aug 2014 09:21:23 -0700 (PDT)
Received: from ppp121-45-54-132.lns20.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([121.45.54.132]) by ipmail04.adl6.internode.on.net with ESMTP; 31 Aug 2014 01:51:22 +0930
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 6A3EBFFF3F for <codec@ietf.org>; Sun, 31 Aug 2014 01:51:20 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ITMFH0taKVeR for <codec@ietf.org>; Sun, 31 Aug 2014 01:51:19 +0930 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 9869EFF8BF for <codec@ietf.org>; 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 <ron@debian.org>
To: codec@ietf.org
Message-ID: <20140830162119.GG326@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> <CAMdZqKEztz_b_tGkGAqWMkZ63wgb9MVswozSyxiJDQOV_TkuNA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMdZqKEztz_b_tGkGAqWMkZ63wgb9MVswozSyxiJDQOV_TkuNA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/iTEQ929cjyOp6o3UmPCfDeYGUtc
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 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? Ron
- [codec] draft-ietf-codec-oggopus: attached pictur… Mark Harris
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Timothy B. Terriberry
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Ron
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Basil Mohamed Gohar
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Timothy B. Terriberry
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Mark Harris
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Ron
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Mark Harris
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Ron
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Mark Harris
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Timothy B. Terriberry
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Ron
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Ralph Giles
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Mark Harris
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Ron
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Timothy B. Terriberry
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Mark Harris
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Timothy B. Terriberry
- Re: [codec] draft-ietf-codec-oggopus: attached pi… Ralph Giles