Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt

[Ralph Giles <[e-mail]>]

On 12-07-11 9:45 AM, Gregory Maxwell wrote:

> But, Opus is new and hits some new applications and it
> would seem to be foolish to leave no graceful way out
> in the case of currently unanticipated needs.

Another versioning example, although it doesn't address the length
issue: The draft defines three channel mapping familes which give
semantic meaning to the various output channels, and specifies that any
unrecognized channel mapping should be treated like mapping 255, which
is discrete multichannel with no specific channel meanings.

If an a new surround audio encoding became popular, like an ambisonic
expansion or a 24 speaker configuration for immersive environments, a
revision of this specification could define a new channel mapping family
for that encoding. But, and this is something I think the draft could
describe more clearly, encoders producing files with that family number
could reasonably increment the minor version nibble to indicate a
compatible change. This would signal to updated decoders how to
interpret the new channel mapping family value, while older decoders
would produce discrete output without confusion.

> No one who's contributed to the draft so far is new at this,
> and, apparently, based on the collective experience with
> vorbis, speex, flac, theora, (and the many non Ogg formats
> we've all worked with), it doesn't appear that there will
> ever need to be anything added to the header.

This is my expectation as well. I think it's still valuable to specify
decoders MUST ignore extra data at the end of the header packets so
later drafts can take advange of the extension flag if it is needed.

 -r