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