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
13078454
Commit
13078454
authored
10 years ago
by
Ralph Giles
Browse files
Options
Downloads
Patches
Plain Diff
Apply further fixes from Ron.
parent
1204ed1b
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-oggopus.xml
+4
-4
4 additions, 4 deletions
doc/draft-ietf-codec-oggopus.xml
with
4 additions
and
4 deletions
doc/draft-ietf-codec-oggopus.xml
+
4
−
4
View file @
13078454
...
...
@@ -330,7 +330,7 @@ In the example above, if the previous frame was a 20 ms SILK mode frame,
gap.
This also requires four bytes to describe the synthesized packet data (two
bytes for a CBR code 3 and one byte each for two code 0 packets) but three
bytes of Ogg lacing overhead are ne
cessary
to mark the packet boundaries.
bytes of Ogg lacing overhead are ne
eded
to mark the packet boundaries.
At 0.6 kbps, this is still a minimal bitrate impact over a naive, low quality
solution.
</t>
...
...
@@ -349,7 +349,7 @@ Since medium-band audio is an option only in the SILK mode, wideband frames
There is some amount of latency introduced during the decoding process, to
allow for overlap in the CELT mode, stereo mixing in the SILK mode, and
resampling.
The encoder introduce
s
additional latency through its own resampling
The encoder
might have
introduce
d
additional latency through its own resampling
and analysis (though the exact amount is not specified).
Therefore, the first few samples produced by the decoder do not correspond to
real input audio, but are instead composed of padding inserted by the encoder
...
...
@@ -364,7 +364,7 @@ However, a decoder will want to skip these samples after decoding them.
A 'pre-skip' field in the ID header (see
<xref
target=
"id_header"
/>
) signals
the number of samples which SHOULD be skipped (decoded but discarded) at the
beginning of the stream.
This amount
MAY
not be a multiple of 2.5
ms, MAY be smaller than a single
This amount
need
not be a multiple of 2.5
ms, MAY be smaller than a single
packet, or MAY span the contents of several packets.
These samples are not valid audio, and SHOULD NOT be played.
</t>
...
...
@@ -804,7 +804,7 @@ For channel mapping family 0, this value defaults to C-1 (i.e., 0 for mono
</t>
<t><spanx
style=
"strong"
>
Channel Mapping
</spanx>
(8*C bits):
This contains one octet per output channel, indicating which decoded channel
to be used for each one.
is
to be used for each one.
Let 'index' be the value of this octet for a particular output channel.
This value MUST either be smaller than (M+N), or be the special value 255.
If 'index' is less than 2*M, the output MUST be taken from decoding stream
...
...
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