On Fri, Aug 29, 2014 at 10:38:14PM -0700, Mark Harris wrote: > Timothy B. Terriberry wrote: > > We could also choose not to address this _here_, and instead continue to > > defer to the existing vorbis-comment documentation. That wouldn't block > > publication of this draft, and give us time to get implementation feedback > > from the authors of media players and tools who would have to deal with this > > change. I think this is the approach that I personally prefer. > > 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. There are all sorts of things that people might want to append to an Opus track, and we clearly can't define, let alone imagine, all of them here and today, since some of them haven't even been invented yet. If you think something is missing from our ability to generically extend this to include other 'non-opus' data at a later date, then perhaps we ought to consider that. But I think getting bogged down on finalising the codec mapping to Ogg, because we don't have things that weren't part of the charter of this group, that nobody has wanted enough to raise before now, and that there are no published and tested implementations of, is scope creep that ought to be a separate matter of study, with a separate proposed standard as a properly generic extension to RFC 3533 and/or RFC 5334. Otherwise where does this stop? We can't give people a published Ogg mapping for Opus until we have optimal support for embedded pony holograms? I'm sure someone somewhere thinks that's a very important feature. Like alternate image encodings though, I don't see why a standard for that can't be created later that will work in a standard way for anything in an Ogg container, not just Opus. Which seems like a far better outcome than kludging something in here at the last minute, doesn't it? What are we missing that makes that impossible? Ron _______________________________________________ codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/codec
