Ralph Giles authored 9 years ago and Ralph Giles committed 9 years ago

This is a reasonable choice for the (non-linear) dynamic
range of mu-law. A-law is technically 13 bit, maybe 12;
experimentation is needed.

Per irc discussion with Jean-Marc, Ron, and Mark Harris.

Also alphabetize the rest of the file.

Avoids accidental name collisions

ISO C90 forbids mixed declarations and code, r=bustage

Add a reset function for the TonalityAnalysisState struct
and call it on encoder reset.

Move the state struct above the clear line in OpusEncoder
so reset doesn't clobber reusable fields. Currently this
is only the arch field, which is moved to to top of the
struct so we can use the same memset-to-the-end pattern
as OpusEncoder.

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

This interns the asm flags parameter in the state struct
so we don't need to pass it with every call. It can be
expensive, so we don't want to query every run_analysis()
call, but since this (private) api is used by webrtc code
we need to provide a supportable interface for filling in
the correct value.

Note the initialization code is partially duplicated between
opus_encoder_init and the OPUS_RESET_STATE switch case, so we
must re-initialize it there.

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Removed 2119 language for general Ogg requirements.
Added IANA registry for channel mapping families.
Adjusted additional copyright grant to match RFC 6716.
Additional comments addressed (see the CODEC mailing list).

...and also make it not ignore the right channel

Mark Harris convinced me that the significant delay between "WG
 consensus" and "RFC" means we shouldn't rely on RFC updates to
 give people permission to start deploying new things.

Thanks to Mark Harris for the report.

Reported in https://trac.xiph.org/ticket/2241

Should no longer cause discontinuities in the noise after 5 packets

Previously silence would cause the divide approximation on 0/0 to return a
very large value, which would be interpreted as a transient

Also remove most <preamble>/<postamble> usage for expository text,
 as most places center the result, which looks ugly (only local
 xml2rfc HTML output does not center: tools.ietf.org HTML output
 still does, as does the .txt version).

To avoid confusion with an RFC 6716 encoder/decoder.
No part of this document is intended to update RFC 6716.

Jonathan Lennox authored 9 years ago and Jean-Marc Valin committed 9 years ago

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

I *think* all we need to do is document this and the RFC editors
will take care of it.

We mention this in the description of Channel Mapping Family 0.
Might as well link to RFC 7587.

Review comment from Mo Zanaty.

This improves readability in the xml2rfc html output, but
generates Markdown-style *bold* in the txt output, and
more importantly in the nroff-like html output of the
tools.ietf.org toolchain, which Mo Zanaty and some in
IRC objected to.

Based on Mo Zanaty's review comments.

Response to comments from Mo Zanaty. Using "muxer/demuxer"
really isn't less ambiguous than "encoder/decoder" but does
help distinguish between this draft and a 'codec encoder/decoder'
described by the Opus RFC.

Radu Velea authored 9 years ago and Timothy B. Terriberry committed 9 years ago

Signed-off-by: Timothy B. Terriberry <tterribe@xiph.org>

Radu Velea authored 9 years ago and Timothy B. Terriberry committed 9 years ago

Signed-off-by: Timothy B. Terriberry <tterribe@xiph.org>