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

[Ron <[e-mail]>]

On Wed, Jul 11, 2012 at 10:30:21AM -0700, Ralph Giles wrote:
> 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.

This was the only concrete thing that really occurred to me which we
_might_ plausibly get value out of the "minor version" with -- however
the draft explicitly says "General-purpose players SHOULD NOT attempt
to play these (family 255) streams" -- which kind of conflicts with
the notion that minor version increments are backward compatible and
existing decoders SHOULD accept them and be able to play them.

If we add a new mapping family, then we sort of have created a stream
that is not really backward compatible with previously existing code.

The minor version in this case at best might act as a sort of crude
checksum, that says family 7 really is supposed to be defined, rather
than being an encoding error - but if we use it like that, we're going
to run out of minor versions long before we run out of new mapping
families that we might add ...  and what will we do then?

One alternative is we could just revise the spec to define new families
without bumping the minor version.  Since they'd basically act as you
suggest for things that don't recognise them anyway in that case.

> > 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.

I likewise don't actually expect we will ever find a reason to bump
the minor version (though defining new mapping families seems like a
real possibility), which is mostly why I wonder if this is really the
best mechanism for enabling extensions that we cannot yet imagine,
and mostly doubt we'll need ...

 Ron