Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
Opus
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Xiph.Org
Opus
Commits
2c7eb787
Commit
2c7eb787
authored
11 years ago
by
Mark Harris
Committed by
Jean-Marc Valin
11 years ago
Browse files
Options
Downloads
Patches
Plain Diff
Minor nits on update draft
Signed-off-by:
Jean-Marc Valin
<
jmvalin@jmvalin.ca
>
parent
0b644be5
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/draft-ietf-codec-opus-update.xml
+5
-5
5 additions, 5 deletions
doc/draft-ietf-codec-opus-update.xml
with
5 additions
and
5 deletions
doc/draft-ietf-codec-opus-update.xml
+
5
−
5
View file @
2c7eb787
...
...
@@ -142,10 +142,10 @@
<t>
The calls to memcpy() were using sizeof(opus_int32), but the type of the
local buffer was opus_int16.
</t>
<t>
Because the size was wrong, this potentially allowed the source
and destination regions of the memcpy overlap.
and destination regions of the memcpy
() to
overlap.
We
<spanx
style=
"emph"
>
believe
</spanx>
that nSamplesIn is at least fs_in_khZ,
which is at least 8.
Since RESAMPLER_ORDER_FIR_12 is only 8,that should not be a problem once
Since RESAMPLER_ORDER_FIR_12 is only 8,
that should not be a problem once
the type size is fixed.
</t>
<t>
The size of the buffer used RESAMPLER_MAX_BATCH_SIZE_IN, but the
data stored in it was actually _twice_ the input batch size
...
...
@@ -157,7 +157,7 @@
the batch sizes are reasonable enough that none of the issues above
was ever a problem. However, proving that is non-obvious.
</t>
<t>
The code can be fixed by applying the following changes to li
k
e 70 of silk/resampler_private_IIR_FIR.c:
<t>
The code can be fixed by applying the following changes to li
n
e 70 of silk/resampler_private_IIR_FIR.c:
<figure>
<artwork>
<![CDATA[
opus_int16 out[], /* O Output signal */
...
...
@@ -208,8 +208,8 @@
<section
title=
"Downmix to Mono"
>
<t>
The last issue is not strictly a bug, but it is an issue that has been reported
when downmixing Opus decoded stream to mono, whether this is done inside the decoder
or as a post-processing on the stereo decoder output. Opus intensity stereo allows
when downmixing
an
Opus decoded stream to mono, whether this is done inside the decoder
or as a post-processing
step
on the stereo decoder output. Opus intensity stereo allows
optionally coding the two channels 180-degrees out of phase on a per-band basis.
This provides better stereo quality than forcing the two channels to be in phase,
but when the output is downmixed to mono, the energy in the affected bands is cancelled
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment