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

[Mark Harris <[e-mail]>]

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