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 _______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
