Re: [codec] Discussion around ITU LS

[Gregory Maxwell <[e-mail]>]

Michael Ramalho (mramalho) [[e-mail]]:
> I find it amazing that Anisse's constructive comments are being met with
> such resistance ... as such capabilities were touted as a major reason
> why this work needed to be performed in the IETF.

I find it unfortunate that Jean-Marc's comments are being interpreted as 
"resistance" as he plainly invited the contribution of such functionality
while saying that he still thought it would best be done another way.

(And, for whatever it's worth,  I think he's right:  It's the jitter buffer
this functionality needs to be integrated with far more so than
the codec itself  I also think that Christian is right and the codec could
export some information which would be useful)

Personally, I don't understand how simply not jumping at the opportunity
to do a bunch of software development and IPR clearance work for
functionality that you aren't interested in, won't use, and think 
could better be done another way can fairly be called resistance.

I also think you should take a careful look at the old discussion
surrounding the requirements like this— you'll see that there was
clear opposition to reinventing the whole of the internet inside the
codec.  There is a careful balancing act.

Generally I think we should avoid adding functionality to the codec
specification which isn't itself important for interoperability or making
the codec functional.

I expect future Opus implementers will add a variety of useful things
to their implementations— better error concealment, more intelligent
encoders, echo cancellation, etc.  We can't hope to match in finite
time the quality and brilliance of the work the whole world can
produce in the indefinite future.

I would probably have let out the loss concealment and the _encoder_
from the draft,  except that having these things was essential for
proving that a codec meeting the community's needs would actually
be available to them and it's needed for the reference implementation
to be functionally complete. But I can't say the same thing about
stretching.

Or perhaps there is a miscommunication here:  Opus _does_ have
rudimentary "stretching" of the at least of the level required
to make the code usable over the internet:  If you invoke the decoder
without input (null data buffer) it will generate filler audio, making
the signal longer. Likewise, if you skip a packet on decode (especially
an inactive one) you'll shorten the signal without anything bad
happening.

This works fine, and it's how all of the pre-final adoption of CELT
in the open source world has worked. As far as I know _none_
of our great many early adopters have requested anything
more.

When JM and I hear complaint that Opus doesn't provide "time
stretching" we're mostly thinking about  high complexity/high fidelity
algorithms for this purpose instead of that basic one.  We think of
Non-basic functionality which isn't needed to interop, which will have
a platform and application specific nature— (since you can usually
afford better stretching on a desktop than on a phone), and which
can be added by anyone at any time in the future...  

One way to address this, if people consider it important, would be
to develop another draft for that purpose.  It's something I would
have instantly proposed in response to the request— except I know
that many people here are concerned about working group
scope creep.  

(Though, if it isn't opposed it as scope creep as part of the
codec draft, why oppose it as a freestanding draft?)

> How exactly is OPUS technically differentiated (other than marginal
> differences in quality at bit rates within a factor of ~ 1.3x *) from
> existing codecs developed in other SDOs?

Can you suggest a comparable codec which supports latency at the 
5ms level? Another codec that can operate at _any_ bitrate congestion
control permits it?  Another codec that supports good fidelity speech at
11kbit/sec? another codec that gives good stereo music at 64kbit/sec?
Transparent stereo music near 100kbit/sec while giving latencies which
are acceptable for communication?  Another with similar licensing
status to Opus?

You can find examples for each of these, though you'll find
that Opus is still best of breed in each considered alone— but
you can not find anything that matches the composition overall or
even comes close.

When I look at the applications and requirements the strongest theme
visible to me is this theme of versatility— it's one that underlies many
of the devices being added to the network today (such as smartphones,
with their 1,00 1 "apps") as well as the the trends in webbrowser 
technology where small collections of flexible tools and development
glue are being used to invent applications that where never dreamed
of by the developers of the infrastructure.

We are already _well_ differentiated, and if you're not willing to
accept that then why would you accept that adding additional
stretching would resolve it? After all, the same code could be copied
to the implementation of any other codec.