Ben Campbell wrote:
That makes me wonder why the end-of-stream flag part is a SHOULD and not
a MUST, though. Are there reasonable circumstances to violate that SHOULD?
The usual case is again, saving a live stream that gets interrupted
before it ends.
This might be better stated as non-normative guidance.
Given that this is a general Ogg requirement, and not really
Opus-specific, I think you are right.
Here are the changes I propose:
-The first audio data page SHOULD NOT have the 'continued packet' flag set
- (which would indicate the first audio data packet is continued from a
previous
- page).
-Packets MUST be placed into Ogg pages in order until the end of stream.
-Audio packets MAY span page boundaries.
+Packets are placed into Ogg pages in order until the end of stream.
+Audio data packets might span page boundaries.
+The first audio data page could have the 'continued packet' flag set
+ (indicating the first audio data packet is continued from a previous
page) if,
+ for example, it was a live stream joined mid-broadcast, with the headers
+ pasted on the front.
+A demuxer SHOULD NOT attempt to decode the data for the first packet on
a page
+ with the 'continued packet' flag set if the previous page with packet data
+ does not end in a continued packet (i.e., did not end with a lacing
value of
+ 255) or if the page sequence numbers are not consecutive, unless the
demuxer
+ has some special knowledge that would allow it to interpret this data
+ despite the missing pieces.
Along with
-The last page SHOULD have the 'end of stream' flag set, but implementations
- need to be prepared to deal with truncated streams that do not have a page
- marked 'end of stream'.
-The final packet on the last page SHOULD NOT be a continued packet,
i.e., the
- final lacing value SHOULD be less than 255.
+A logical stream ends with a page with the 'end of stream' flag set, but
+ implementations need to be prepared to deal with truncated streams
that do not
+ have a page marked 'end of stream'.
+There is no reason for the final packet on the last page to be a continued
+ packet, i.e., for the final lacing value to be less than 255.
+However, demuxers might encounter such streams, possibly as the result of a
+ transfer that did not complete or of corruption.
+A demuxer SHOULD NOT attempt to decode the data from a packet that
continues
+ onto a subsequent page (i.e., when the page ends with a lacing value
of 255)
+ if the next page with packet data does not have the 'continued packet'
flag
+ set or does not exist, or if the page sequence numbers are not
consecutive,
+ unless the demuxer has some special knowledge that would allow it to
interpret
+ this data despite the missing pieces.
That gives specific guidance on what a demuxer needs to do to avoid
corrupting the Opus state machine with garbage data (which is generally
worse for Opus than simply skipping decode of a packet). It is also what
is most broadly implemented.
It would be helpful to mention that in the text.
I added something about that.
2119 :-) It's not so much how big of a stick you need to get people to
do the right thing as it is how bad do things break if people do the
wrong thing. (I do agree with the sentiment to not put in MUSTs that you
Given that historically, many audio formats (including MP3) did not
support sample-accurate durations at all, I don't think the world ends.
But it certainly would break features like gapless playback that some
users find important.
The current wording says "see [seeking] for general implementation
guidelines." If those are optional guidelines, it would help to say so,
or describe it as "some example guidelines". OTOH, if you really prefer
the approach in [seeking], then it still makes sense for it to be
normative.
I've added the optional/example qualifier.
I also updated the claim on the number of bisections required, as our
implementations have improved since the draft was first written.
What does it mean, in context, to "reject" headers?
The same thing as rejecting a stream (i.e., don't try to play/decode
it). Changed to say that instead.
Which "that"?
To quote the attached diff:
-Implementations SHOULD reject ID headers which do not contain enough
data for
- these fields, even if they contain a valid Magic Signature.
+Implementations SHOULD reject streams with ID headers that do not contain
+ enough data for these fields, even if they contain a valid Magic
Signature.
Maybe this is a conventional way to say things in the codec community,
but when I see "reject" I usually think that means you generate some
sort of error back to the source of the thing you reject. (As opposed to
"ignore")
Well, the most likely behavior here is to tell the user that the file is
not a valid Ogg Opus file, so your sense of "generating some sort of
error back" is in fact correct. But that makes some application-level
assumptions I'm not sure I'm comfortable writing normative text around.
Any ideas for a better way to phrase this?
If this spec reserves those values, then people still need to update it
to assign them. If you want to make it extensible, then perhaps it needs
an IANA registry, which, depending on the assignment policy, may not
require an RFC at all (seems like "expert review" or "specification
required" might make sense).
An IANA registry actually does not seem like a terrible idea. Reading
RFC 5226 it doesn't seem too hard to set one up. I attempted to draft
some text.
it's what our "UPDATES" process is for. The idea that you might want to
informally experiment with different approaches is more convincing. But
if that is the case, it would be helpful to have a sentence to that
effect in the text.
Okay, I will add one.
(I do agree "Excessive" is a bit vague, so if there were a way to state
this more concretely it would improve things. But that's true for a
SHOULD as much as for a MUST).
The problem is that it depends very much on context. 60 kB might already
be seen as excessive for an embedded system, but would never be noticed
on a desktop.
In some contexts, there may be no confusion with multiple
normalization schemes. The language in this section was debated a good
[...]
I agree that SHOULD NOT may be appropriate here. My point is the text
should explain why. Almost anytime a SHOULD occurs, it's helpful to
I agree with your point very much in principle. We just may not have
been as careful about it in practice as we should have been (and I
appreciate you forcing us to clarify our thinking now). I'll add
something to the effect of what I said above.
Did 6716 use a SHOULD?
It imposed no restrictions on the amount of padding at all.
attributed). But in any case, I'm looking for justification in the text.
(I do consider preventing the use of excessive bandwidth a good enough
reason for a MUST
I attempted to add some.
For the second, this is the same as the previous comment about
excessive allocations. I have no objection to changing this one, either.
I realize now there were 3 SHOULDs in that paragraph. I mean the one
about avoiding excessive allocations. It sounds like
You may have forgotten to complete your thought here.
Please consider saying something like "For more information on linear
prediction, see [XXX]." As it's currently stated, it looks like it says
MAY do X, where the reference specified X, which would require a
normative reference.
That's a good suggestion. Done.
That language is a bit of a problem for a standards track RFC. If people
You mean the current text, or the actual text that wound up in RFC 6716?
are really attached to it, we can pursue allowing it. But I expect
objections down the line. Keep in mind "NOTE WELL" says that any
contributions are subject to the rules of BCP 78 and 79.
Yes, I think this has more to do with letting people use such
contributions _outside_ the context of the IETF (i.e., it grants
additional rights to those already granted in BCP 78 and 79, which I
understand is allowed).
You are probably right about people objecting down the line (again), but
I am happy to address those objections when they come, as we did for RFC
6716.
In any case, 6716 is a bit more code centric , so the discussion made
more sense there.
Well, from our point of view, the XML source for both RFCs is included
in the repository with libopus, which is distributed in Debian. If we
didn't have some kind of grant like this, they would have to somehow
strip those documents out. So it is not so much the code being in the
RFC as the draft being distributed with the code.
In any case, I have attempted to draft an RFC Editor's note requesting
the same text that RFC 6716 used. Since that text grants a license from
the IETF Trust, instead of the authors, I assume that someone from the
Trust will have to approve of it, however (and reading
<http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-15.ppt>
it seems that the current opinion of the Trust is that this approach is
legally required).
I have also gone through and finished removing the 2119 language for
general Ogg requirements.
The diff of all changes is attached. If these look good (or if it's
simply helps in reviewing them) I can publish a new version.
diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml
index b95e5bc..7489c20 100644
--- a/doc/draft-ietf-codec-oggopus.xml
+++ b/doc/draft-ietf-codec-oggopus.xml
@@ -1,14 +1,15 @@
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3533 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3533.xml'>
<!ENTITY rfc3629 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'>
<!ENTITY rfc4732 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4732.xml'>
+<!ENTITY rfc5226 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
<!ENTITY rfc5334 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5334.xml'>
<!ENTITY rfc6381 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6381.xml'>
<!ENTITY rfc6716 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6716.xml'>
<!ENTITY rfc6982 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6982.xml'>
<!ENTITY rfc7587 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7587.xml'>
]>
<?rfc toc="yes" symrefs="yes" ?>
@@ -135,19 +136,19 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
<t>
An Ogg Opus stream is organized as follows.
</t>
<t>
There are two mandatory header packets.
The first packet in the logical Ogg bitstream MUST contain the identification
(ID) header, which uniquely identifies a stream as Opus audio.
The format of this header is defined in <xref target="id_header"/>.
-It MUST be placed alone (without any other packet data) on the first page of
- the logical Ogg bitstream, and MUST complete on that page.
-This page MUST have its 'beginning of stream' flag set.
+It is placed alone (without any other packet data) on the first page of
+ the logical Ogg bitstream, and completes on that page.
+This page has its 'beginning of stream' flag set.
</t>
<t>
The second packet in the logical Ogg bitstream MUST contain the comment header,
which contains user-supplied metadata.
The format of this header is defined in <xref target="comment_header"/>.
It MAY span multiple pages, beginning on the second page of the logical
stream.
However many pages it spans, the comment header packet MUST finish the page on
@@ -182,31 +183,46 @@ The TOC sequence at the beginning of each Opus packet indicates the coding
frames per packet, as described in Section 3.1
of <xref target="RFC6716"/>.
The coding mode is one of SILK, Hybrid, or Constrained Energy Lapped Transform
(CELT).
The combination of coding mode, audio bandwidth, and frame size is referred to
as the configuration of an Opus packet.
</t>
<t>
-The first audio data page SHOULD NOT have the 'continued packet' flag set
- (which would indicate the first audio data packet is continued from a previous
- page).
-Packets MUST be placed into Ogg pages in order until the end of stream.
-Audio packets MAY span page boundaries.
+Packets are placed into Ogg pages in order until the end of stream.
+Audio data packets might span page boundaries.
+The first audio data page could have the 'continued packet' flag set
+ (indicating the first audio data packet is continued from a previous page) if,
+ for example, it was a live stream joined mid-broadcast, with the headers
+ pasted on the front.
+A demuxer SHOULD NOT attempt to decode the data for the first packet on a page
+ with the 'continued packet' flag set if the previous page with packet data
+ does not end in a continued packet (i.e., did not end with a lacing value of
+ 255) or if the page sequence numbers are not consecutive, unless the demuxer
+ has some special knowledge that would allow it to interpret this data
+ despite the missing pieces.
An implementation MUST treat a zero-octet audio data packet as if it were a
malformed Opus packet as described in
Section 3.4 of <xref target="RFC6716"/>.
</t>
<t>
-The last page SHOULD have the 'end of stream' flag set, but implementations
- need to be prepared to deal with truncated streams that do not have a page
- marked 'end of stream'.
-The final packet on the last page SHOULD NOT be a continued packet, i.e., the
- final lacing value SHOULD be less than 255.
+A logical stream ends with a page with the 'end of stream' flag set, but
+ implementations need to be prepared to deal with truncated streams that do not
+ have a page marked 'end of stream'.
+There is no reason for the final packet on the last page to be a continued
+ packet, i.e., for the final lacing value to be less than 255.
+However, demuxers might encounter such streams, possibly as the result of a
+ transfer that did not complete or of corruption.
+A demuxer SHOULD NOT attempt to decode the data from a packet that continues
+ onto a subsequent page (i.e., when the page ends with a lacing value of 255)
+ if the next page with packet data does not have the 'continued packet' flag
+ set or does not exist, or if the page sequence numbers are not consecutive,
+ unless the demuxer has some special knowledge that would allow it to interpret
+ this data despite the missing pieces.
There MUST NOT be any more pages in an Opus logical bitstream after a page
marked 'end of stream'.
</t>
</section>
<section anchor="granpos" title="Granule Position">
<t>
The granule position MUST be zero for the ID header page and the
@@ -219,18 +235,18 @@ The granule position of an audio data page encodes the total number of PCM
samples in the stream up to and including the last fully-decodable sample from
the last packet completed on that page.
The granule position of the first audio data page will usually be larger than
zero, as described in <xref target="start_granpos_restrictions"/>.
</t>
<t>
A page that is entirely spanned by a single packet (that completes on a
- subsequent page) has no granule position, and the granule position field MUST
- be set to the special value '-1' in two's complement.
+ subsequent page) has no granule position, and the granule position field is
+ set to the special value '-1' in two's complement.
</t>
<t>
The granule position of an audio data page is in units of PCM audio samples at
a fixed rate of 48 kHz (per channel; a stereo stream's granule position
does not increment at twice the speed of a mono stream).
It is possible to run an Opus decoder at other sampling rates, but the value
in the granule position field always counts samples assuming a 48 kHz
@@ -372,17 +388,18 @@ These samples need to be stored and decoded, as Opus is an asymptotically
convergent predictive codec, meaning the decoded contents of each frame depend
on the recent history of decoder inputs.
However, a player will want to skip these samples after decoding them.
</t>
<t>
A 'pre-skip' field in the ID header (see <xref target="id_header"/>) signals
the number of samples that SHOULD be skipped (decoded but discarded) at the
- beginning of the stream.
+ beginning of the stream, though some specific applications might have a reason
+ for looking at that data.
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.
</t>
<t>
For example, if the first Opus frame uses the CELT mode, it will always
produce 120 samples of windowed overlap-add data.
@@ -520,19 +537,19 @@ Both of these will be greater than '0' in this case.
</t>
</section>
<section anchor="seeking_and_preroll" title="Seeking and Pre-roll">
<t>
Seeking in Ogg files is best performed using a bisection search for a page
whose granule position corresponds to a PCM position at or before the seek
target.
-With appropriately weighted bisection, accurate seeking can be performed with
- just three or four bisections even in multi-gigabyte files.
-See <xref target="seeking"/> for general implementation guidance.
+With appropriately weighted bisection, accurate seeking can be performed in
+ just one or two bisections on average, even in multi-gigabyte files.
+See <xref target="seeking"/> for an example of general implementation guidance.
</t>
<t>
When seeking within an Ogg Opus stream, an implementation SHOULD start decoding
(and discarding the output) at least 3840 samples (80 ms) prior to
the seek target in order to ensure that the output audio is correct by the
time it reaches the seek target.
This 'pre-roll' is separate from, and unrelated to, the 'pre-skip' used at the
@@ -655,18 +672,18 @@ The original sample rate of the audio passed to the encoder is not preserved
<vspace blankLines="1"/>
An Ogg Opus player SHOULD select the playback sample rate according to the
following procedure:
<list style="numbers">
<t>If the hardware supports 48 kHz playback, decode at 48 kHz.</t>
<t>Otherwise, if the hardware's highest available sample rate is a supported
rate, decode at this sample rate.</t>
<t>Otherwise, if the hardware's highest available sample rate is less than
- 48 kHz, decode at the next highest supported rate above this and
- resample.</t>
+ 48 kHz, decode at the next higher Opus supported rate above the highest
+ available hardware rate and resample.</t>
<t>Otherwise, decode at 48 kHz and resample.</t>
</list>
However, the 'Input Sample Rate' field allows the muxer to pass the sample
rate of the original input stream as metadata.
This is useful when the user requires the output sample rate to match the
input sample rate.
For example, when not playing the output, an implementation writing PCM format
samples to disk might choose to resample the audio back to the original input
@@ -1179,16 +1196,18 @@ Making this check before allocating the associated memory to contain the data
<t>
Immediately following the user comment list, the comment header MAY
contain zero-padding or other binary data which is not specified here.
If the least-significant bit of the first byte of this data is 1, then editors
SHOULD preserve the contents of this data when updating the tags, but if this
bit is 0, all such data MAY be treated as padding, and truncated or discarded
as desired.
+This allows informal experimentation with the format of this binary data until
+ it can be specified later.
</t>
<t>
The comment header can be arbitrarily large and might be spread over a large
number of Ogg pages.
Implementations MUST avoid attempting to allocate excessive amounts of memory
when presented with a very large comment header.
To accomplish this, implementations MAY reject a comment header larger than
@@ -1252,17 +1271,18 @@ If a player chooses to make use of the R128_TRACK_GAIN tag or the
If a tool modifies the ID header's 'output gain' field, it MUST also update or
remove the R128_TRACK_GAIN and R128_ALBUM_GAIN comment tags if present.
A muxer SHOULD place the gain it wants other tools to use by default into the
'output gain' field, and not the comment tag.
</t>
<t>
To avoid confusion with multiple normalization schemes, an Opus comment header
SHOULD NOT contain any of the REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEAK,
- REPLAYGAIN_ALBUM_GAIN, or REPLAYGAIN_ALBUM_PEAK tags.
+ REPLAYGAIN_ALBUM_GAIN, or REPLAYGAIN_ALBUM_PEAK tags, unless they are only
+ to be used in some context where there is guaranteed to be no such confusion.
<xref target="EBU-R128"/> normalization is preferred to the earlier
REPLAYGAIN schemes because of its clear definition and adoption by industry.
Peak normalizations are difficult to calculate reliably for lossy codecs
because of variation in excursion heights due to decoder differences.
In the authors' investigations they were not applied consistently or broadly
enough to merit inclusion here.
</t>
</section> <!-- end comment_format -->
@@ -1272,21 +1292,22 @@ In the authors' investigations they were not applied consistently or broadly
<section anchor="packet_size_limits" title="Packet Size Limits">
<t>
Technically, valid Opus packets can be arbitrarily large due to the padding
format, although the amount of non-padding data they can contain is bounded.
These packets might be spread over a similarly enormous number of Ogg pages.
When encoding, implementations SHOULD limit the use of padding in audio data
packets to no more than is necessary to make a variable bitrate (VBR) stream
- constant bitrate (CBR).
+ constant bitrate (CBR), unless they have no reasonable way to determine what
+ is necessary.
Demuxers SHOULD reject audio data packets (treat them as if they were malformed
Opus packets with an invalid TOC sequence) larger than 61,440 octets per
- Opus stream.
-Such packets necessarily contain more padding than needed for this purpose.
+ Opus stream, unless they have a specific reason for allowing extra padding.
+Such packets necessarily contain more padding than needed to make a stream CBR.
Demuxers MUST avoid attempting to allocate excessive amounts of memory when
presented with a very large packet.
Demuxers MAY reject or partially process audio data packets larger than
61,440 octets in an Ogg Opus stream with channel mapping families 0
or 1.
Demuxers MAY reject or partially process audio data packets in any Ogg Opus
stream if the packet is larger than 61,440 octets and also larger than
7,680 octets per Opus stream.
@@ -1339,20 +1360,21 @@ In encoders derived from the reference
</t>
<figure align="center">
<artwork align="center"><![CDATA[
opus_encoder_ctl(encoder_state, OPUS_GET_LOOKAHEAD(&delay_samples));
]]></artwork>
</figure>
<t>
To achieve good quality in the very first samples of a stream, implementations
- MAY use linear predictive coding (LPC) extrapolation
- <xref target="linear-prediction"/> to generate at least 120 extra samples at
- the beginning to avoid the Opus encoder having to encode a discontinuous
- signal.
+ MAY use linear predictive coding (LPC) extrapolation to generate at least 120
+ extra samples at the beginning to avoid the Opus encoder having to encode a
+ discontinuous signal.
+For more information on linear prediction, see
+ <xref target="linear-prediction"/>.
For an input file containing 'length' samples, the implementation SHOULD set
the pre-skip header value to (delay_samples + extra_samples), encode
at least (length + delay_samples + extra_samples)
samples, and set the granule position of the last page to
(length + delay_samples + extra_samples).
This ensures that the encoded file has the same duration as the original, with
no time offset. The best way to pad the end of the stream is to also use LPC
extrapolation, but zero-padding is also acceptable.
@@ -1509,51 +1531,96 @@ In such cases the the '.opus' filename extension is NOT RECOMMENDED.
<t>
In either case, this document updates <xref target="RFC5334"/>
to add 'opus' as a codecs parameter value with char[8]: 'OpusHead'
as Codec Identifier.
</t>
</section>
-<section title="IANA Considerations">
+<section anchor="iana" title="IANA Considerations">
<t>
This document updates the IANA Media Types registry to add .opus
as a file extension for "audio/ogg", and to add itself as a reference
alongside <xref target="RFC5334"/> for "audio/ogg", "video/ogg", and
"application/ogg" Media Types.
</t>
+<t>
+This document defines a new registry "Opus Channel Mapping Families" to
+ indicate how the semantic meanings of the channels in a multi-channel Opus
+ stream are described.
+IANA SHALL create a new name space of "Opus Channel Mapping Families".
+All maintenance within and additions to the contents of this name space MUST be
+ according to the "Specification Requried with Expert Review" registration
+ policy as defined in <xref target="RFC5226"/>.
+Each registry entry consists of a Channel Mapping Family Number, which is
+ specified in decimal in the range 0 to 255, inclusive, and a Reference (or
+ list of references)
+Each Reference must point to sufficient documentation to describe what
+ information is coded in the Opus identification header for this channel
+ mapping family, how a demuxer determines the Stream Count ('N') and Coupled
+ Stream Count ('M') from this information, and how it determines the proper
+ interpretation of each of the decoded channels.
+</t>
+<t>
+This document defines three initial assignments for this registry.
+</t>
+<texttable>
+<ttcol>Value</ttcol><ttcol>Reference</ttcol>
+<c>0</c><c>[RFCXXXX] <xref target="channel_mapping_0"/></c>
+<c>1</c><c>[RFCXXXX] <xref target="channel_mapping_1"/></c>
+<c>255</c><c>[RFCXXXX] <xref target="channel_mapping_255"/></c>
+</texttable>
+<t>
+The designated expert will determine if the Reference points to a specification
+ that meets the requirements for permanence and ready availability laid out
+ in <xref target="RFC5226"/> and that it specifies the information
+ described above with sufficient clarity to allow interoperable
+ implementations.
+</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
-Thanks to Mark Harris, Greg Maxwell, Christopher "Monty" Montgomery, and
- Jean-Marc Valin for their valuable contributions to this document.
+Thanks to Ben Campbell, Mark Harris, Greg Maxwell, Christopher "Monty"
+ Montgomery, Jean-Marc Valin, and Mo Zanaty for their valuable contributions to
+ this document.
Additional thanks to Andrew D'Addesio, Greg Maxwell, and Vincent Penquerc'h for
their feedback based on early implementations.
</t>
</section>
-<section title="Copying Conditions">
+<section title="RFC Editor Notes">
+<t>
+In <xref target="iana"/>, "RFCXXXX" is to be replaced with the RFC number
+ assigned to this draft.
+</t>
+<t>
+In the Copyright Notice at the start of the document, the following paragraph
+ is to be appended after the regular copyright notice text:
+</t>
<t>
-The authors agree to grant third parties the irrevocable right to copy, use,
- and distribute the work, with or without modification, in any medium, without
- royalty, provided that, unless separate permission is granted, redistributed
- modified works do not contain misleading author, version, name of work, or
- endorsement information.
+"The licenses granted by the IETF Trust to this RFC under Section 3.c of
+ the Trust Legal Provisions shall also include the right to extract text from
+ Sections 1 through 14 of this RFC and create derivative works from
+ these extracts, and to copy, publish, display, and distribute such derivative
+ works in any medium and for any purpose, provided that no such derivative work
+ shall be presented, displayed, or published in a manner that states or implies
+ that it is part of this RFC or any other IETF Document."
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3533;
&rfc3629;
&rfc4732;
+ &rfc5226;
&rfc5334;
&rfc6381;
&rfc6716;
<reference anchor="EBU-R128" target="https://tech.ebu.ch/loudness";>
<front>
<title>Loudness Recommendation EBU R128</title>
<author>
_______________________________________________
codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/codec
