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

"Timothy B. Terriberry" <tterribe@xiph.org> Wed, 24 September 2014 20:14 UTC

Return-Path: <tterribe@xiph.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 8B8C91A044F for <codec@ietfa.amsl.com>; Wed, 24 Sep 2014 13:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=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 UBw7nYVx0bVL for <codec@ietfa.amsl.com>; Wed, 24 Sep 2014 13:14:22 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7CB1A03D0 for <codec@ietf.org>; Wed, 24 Sep 2014 13:14:22 -0700 (PDT)
Received: from [10.252.26.205] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 1DC9DF2742 for <codec@ietf.org>; Wed, 24 Sep 2014 13:14:21 -0700 (PDT)
Message-ID: <5423261A.9040103@xiph.org>
Date: Wed, 24 Sep 2014 13:14:18 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: "codec@ietf.org" <codec@ietf.org>
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> <5402B137.9070809@xiph.org> <CAMdZqKFFKf-vWYfQHzkbyr5H24UKE0e=D84ykc_u0K1a+Ep4HA@mail.gmail.com>
In-Reply-To: <CAMdZqKFFKf-vWYfQHzkbyr5H24UKE0e=D84ykc_u0K1a+Ep4HA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/codec/HCN1hgqJezfm85Y_KunsG2woymo
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: Wed, 24 Sep 2014 20:14:25 -0000

Mark Harris wrote:
> None of my proposals should break already-encoded files, so that
> should not be an issue.  I think that the only potential issue is that
> insufficient guidance in the Ogg Opus draft may lead to newly encoded
> files being handled poorly by older tools that are not aware of later
> extensions.  It would be best for this document to provide additional
> guidance even if details such as anything specific to attached
> pictures is specified later in another document.

To resolve this, I'm proposing (as an individual) the following text, to 
be added in a new paragraph at the end of Section 4.2:

"The comment header MAY contain additional binary data which is not 
specified here. If the least-significant bit of the first byte of this 
data is 1, then editors SHOULD attempt to preserve the contents of this 
data when updating the tags, but if this bit is 0, all such data MAY be 
treated as padding, and be truncated or discarded as desired."

Any binary extension for album art, etc., is going to have to be 
compatible with the Vorbis framing bit if we're going to use it for 
Vorbis as well, so I think this gives us a good extension mechanism with 
minimal restrictions while still allowing people to pad the comment 
header for in-place editing (so you can, e.g., update the comments 
without rewriting the whole file). Current tools use all-zero bytes for 
this padding, so they wouldn't have to change.