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

Mark Harris <mark.hsj@gmail.com> Mon, 01 September 2014 06:29 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 B32A51A007F for <codec@ietfa.amsl.com>; Sun, 31 Aug 2014 23:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 lIz8_TTIOd_j for <codec@ietfa.amsl.com>; Sun, 31 Aug 2014 23:29:15 -0700 (PDT)
Received: from mail-ie0-x243.google.com (mail-ie0-x243.google.com [IPv6:2607:f8b0:4001:c03::243]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2951A0061 for <codec@ietf.org>; Sun, 31 Aug 2014 23:29:15 -0700 (PDT)
Received: by mail-ie0-f195.google.com with SMTP id at20so1743069iec.2 for <codec@ietf.org>; Sun, 31 Aug 2014 23:29:15 -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=etf5WXSOy1W3J5Vjzffnw4I8xzFWY0utZr+X1IDo9xU=; b=WczvpoPO3mjMCDw4cTL4la3eTOrWTp3olWgjwSgqTusqdhQntKsZPmvfceVRKUBRtG ZuVZ6UcK7+c3YaSNkGin/6fsJU1yyQlkUTydK/DtyOKxJtiC7SnWOSYrCgMFqZOL6rFC VEEhFkNTPoS0gPQO+WH0p4uMlg9VInZxgLsapOX0l3+uHyYu4tU7QpcsZ2RV0GwPBfEo Jw2OrBGYQib0UkTqoQ9L4BfXm+xYuqftQWC7e9a4Hke+hVGc0bTILBXKj24rmvnhQKLv P07j7Gr4HoPt0SprfMqNIril2lYnzPYkMhTIV6uWb67or7ZS4cl+W3pGlvuKKaICnToj mcVQ==
MIME-Version: 1.0
X-Received: by 10.42.114.130 with SMTP id g2mr5035601icq.46.1409552954507; Sun, 31 Aug 2014 23:29:14 -0700 (PDT)
Sender: markh.sj@gmail.com
Received: by 10.107.1.81 with HTTP; Sun, 31 Aug 2014 23:29:14 -0700 (PDT)
In-Reply-To: <5402B137.9070809@xiph.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>
Date: Sun, 31 Aug 2014 23:29:14 -0700
X-Google-Sender-Auth: hfj-d86CxI-InRtkaLRMw7AB7-k
Message-ID: <CAMdZqKFFKf-vWYfQHzkbyr5H24UKE0e=D84ykc_u0K1a+Ep4HA@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/d0cRw2_r5HCHGhNOg05kRhhfpQo
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: Mon, 01 Sep 2014 06:29:17 -0000

Timothy B. Terriberry wrote:
> There are two possibilities:
>
> 1) A proposal for adding binary metadata breaks already-encoded files, in
> which case I don't think we should do it, considering people have been
> producing those files for over two years now under the expectation that they
> would continue to work, or
>
> 2) A proposal for adding binary metadata does not break already-encoded
> files, in which case we have exactly the future extension mechanism you want
> (emphasis on "future").


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.

For proposal (1) (tags named with an initial "@" are binary rather
than UTF-8): even if no tags are specified in the document, the
document should state that values of tags whose name begins with "@"
need not conform to UTF-8, so that binary tags can be defined later
without having conforming tools reject them as invalid or treating
such tags poorly.  For the record, Firefox and Chrome do not seem to
have any issue playing files with such tags.  Only tools that try to
validate the UTF-8 or that assume that all tags are UTF-8 text should
be impacted, and if they do things like display or allow editing of
arbitrary tags they may want to provide a different way of doing that
for binary tags.  Tools are likely to already provide different
display or editing mechanisms for certain tags such as
METADATA_BLOCK_PICTURE, but currently the only way they can do that is
to check for specific tag names.  A naming convention allows tools to
provide a somewhat more appropriate display and editing capability
even for unknown future tags if they so choose.

For proposal (2) (new OpusTags section for binary blocks, separate
from comments): even if the format of pictures and any other binary
blocks are defined later in another document, this document should
provide guidance for tools that wish to modify tags in an existing
file or provide padding for other tools to do so without re-writing
the whole file.  Currently no such guidance is provided, which could
lead to interoperability failure between some tools which write files
and other tools that modify existing files, if they have different
assumptions about the data in the OpusTags packet following the
comment table.  For example without any guidance different tools
modifying tags in the file might assume that additional data in the
packet should be retained, or that it may be overwritten with the
unused portion left as-is, or may be overwritten with the unused
portion zero'd.  This makes it difficult to ensure that any extension
to this packet will be handled reasonably by any conforming tool.

For proposal (3) (use a different multiplexed stream): it might be
nice if the document had at least a SHOULD-level suggestion that
playback of an Ogg Opus stream not be impacted by the presence of
unrecognized multiplexed streams.

 - Mark