[要約] RFC 8251は、Opusオーディオコーデックのアップデートに関する情報を提供しています。その目的は、Opusの機能やパフォーマンスを向上させるための改善点を示すことです。
Internet Engineering Task Force (IETF) JM. Valin
Request for Comments: 8251 Mozilla Corporation
Updates: 6716 K. Vos
Category: Standards Track vocTone
ISSN: 2070-1721 October 2017
Updates to the Opus Audio Codec
Opusオーディオコーデックの更新
Abstract
概要
This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716. It updates the normative decoder implementation included in Appendix A of RFC 6716. The changes fix real and potential security-related issues, as well as minor quality-related issues.
このドキュメントでは、RFC 6716のOpusオーディオコーデックの仕様で見つかった軽微な問題について説明します。RFC6716の付録Aに含まれている規範的なデコーダの実装を更新します。この変更により、実際および潜在的なセキュリティ関連の問題と軽微な品質が修正されます-関連する問題。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8251.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8251で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Stereo State Reset in SILK . . . . . . . . . . . . . . . . . 3
4. Parsing of the Opus Packet Padding . . . . . . . . . . . . . 4
5. Resampler Buffer . . . . . . . . . . . . . . . . . . . . . . 4
6. Integer Wrap-Around in Inverse Gain Computation . . . . . . . 6
7. Integer Wrap-Around in LSF Decoding . . . . . . . . . . . . . 7
8. Cap on Band Energy . . . . . . . . . . . . . . . . . . . . . 7
9. Hybrid Folding . . . . . . . . . . . . . . . . . . . . . . . 8
10. Downmix to Mono . . . . . . . . . . . . . . . . . . . . . . . 9
11. New Test Vectors . . . . . . . . . . . . . . . . . . . . . . 9
12. Security Considerations . . . . . . . . . . . . . . . . . . . 11
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
14. Normative References . . . . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
This document addresses minor issues that were discovered in the reference implementation of the Opus codec. Unlike most IETF specifications, RFC 6716 [RFC6716] defines Opus in terms of a normative reference decoder implementation rather than from the associated text description. Appendix A of that RFC includes the reference decoder implementation, which is why only issues affecting the decoder are listed here. An up-to-date implementation of the Opus encoder can be found at <https://opus-codec.org/>.
このドキュメントでは、Opusコーデックのリファレンス実装で発見された小さな問題について説明します。ほとんどのIETF仕様とは異なり、RFC 6716 [RFC6716]は、関連するテキスト記述からではなく、規範的なリファレンスデコーダーの実装に関してOpusを定義しています。そのRFCの付録Aにはリファレンスデコーダーの実装が含まれているため、デコーダーに影響する問題のみがここにリストされています。 Opusエンコーダーの最新の実装は、<https://opus-codec.org/>にあります。
Some of the changes in this document update normative behavior in a way that requires new test vectors. Only the C implementation is affected, not the English text of the specification. This specification remains fully compatible with RFC 6716 [RFC6716].
このドキュメントの一部の変更は、新しいテストベクタを必要とする方法で規範的な動作を更新します。仕様の英語のテキストではなく、C実装のみが影響を受けます。この仕様は、RFC 6716 [RFC6716]との完全な互換性を維持しています。
Note: Due to RFC formatting conventions, lines exceeding the column width in the patch are split using a backslash character. The backslashes at the end of a line and the white space at the beginning of the following line are not part of the patch. Referenced line numbers are approximations. A properly formatted patch including all changes is available at <https://www.ietf.org/proceedings/98/slides/ materials-98-codec-opus-update-00.patch> and has a SHA-1 hash of 029e3aa88fc342c91e67a21e7bfbc9458661cd5f.
注：RFCのフォーマット規則により、パッチの列幅を超える行はバックスラッシュ文字を使用して分割されます。行の終わりのバックスラッシュと次の行の始めの空白はパッチの一部ではありません。参照されている行番号は概算です。すべての変更を含む適切にフォーマットされたパッチは、<https://www.ietf.org/proceedings/98/slides/materials-98-codec-opus-update-00.patch>で入手でき、029e3aa88fc342c91e67a21e7bfbc9458661cd5fのSHA-1ハッシュを持っています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The reference implementation does not reinitialize the stereo state during a mode switch. The old stereo memory can produce a brief impulse (i.e., single sample) in the decoded audio. This can be fixed by changing silk/dec_API.c around line 72:
リファレンス実装は、モード切り替え中にステレオ状態を再初期化しません。古いステレオメモリは、デコードされたオーディオに短いインパルス（つまり、単一のサンプル）を生成する可能性があります。これは、72行目あたりのsilk / dec_API.cを変更することで修正できます。
<CODE BEGINS>
for( n = 0; n < DECODER_NUM_CHANNELS; n++ ) {
ret = silk_init_decoder( &channel_state[ n ] );
}
+ silk_memset(&((silk_decoder *)decState)->sStereo, 0,
+ sizeof(((silk_decoder *)decState)->sStereo));
+ /* Not strictly needed, but it's cleaner that way */
+ ((silk_decoder *)decState)->prev_decode_only_middle = 0;
return ret;
}
<CODE ENDS>
This change affects the normative output of the decoder, but the amount of change is within the tolerance and is too small to make the test vector check fail.
この変更はデコーダーの規範的な出力に影響を与えますが、変更の量は許容範囲内であり、テストベクタチェックを失敗させるには小さすぎます。
It was discovered that some invalid packets of a very large size could trigger an out-of-bounds read in the Opus packet parsing code responsible for padding. This is due to an integer overflow if the signaled padding exceeds 2^31-1 bytes (the actual packet may be smaller). The code can be fixed by decrementing the (signed) len value, instead of incrementing a separate padding counter. This is done by applying the following changes around line 596 of src/opus_decoder.c:
非常に大きなサイズのいくつかの無効なパケットが、パディングを担当するOpusパケット解析コードで範囲外の読み取りをトリガーする可能性があることが発見されました。これは、シグナリングされたパディングが2 ^ 31-1バイトを超える場合、整数のオーバーフローが原因です（実際のパケットはそれよりも小さい場合があります）。別のパディングカウンターをインクリメントする代わりに、（signed）len値をデクリメントすることでコードを修正できます。これは、src / opus_decoder.cの596行目に次の変更を適用することによって行われます。
<CODE BEGINS>
/* Padding flag is bit 6 */
if (ch&0x40)
{
- int padding=0;
int p;
do {
if (len<=0)
return OPUS_INVALID_PACKET;
p = *data++;
len--;
- padding += p==255 ? 254: p;
+ len -= p==255 ? 254: p;
} while (p==255);
- len -= padding;
}
<CODE ENDS>
This packet-parsing issue is limited to reading memory up to about 60 KB beyond the compressed buffer. This can only be triggered by a compressed packet more than about 16 MB long, so it's not a problem for RTP. In theory, it could crash a file decoder (e.g., Opus in Ogg) if the memory just after the incoming packet is out of range, but our attempts to trigger such a crash in a production application built using an affected version of the Opus decoder failed.
このパケット解析の問題は、圧縮バッファを超えて最大約60 KBのメモリを読み取ることに限定されます。これは、長さが約16 MBを超える圧縮パケットによってのみトリガーされるため、RTPの問題ではありません。理論的には、着信パケットの直後のメモリが範囲外の場合、ファイルデコーダー（Opus in Oggなど）がクラッシュする可能性がありますが、影響を受けるバージョンのOpusデコーダーを使用して構築された本番アプリケーションでこのようなクラッシュをトリガーしようとしました失敗した。
The SILK resampler had the following issues:
SILKリサンプラーには次の問題がありました。
1. The calls to memcpy() were using sizeof(opus_int32), but the type of the local buffer was opus_int16.
1. memcpy()への呼び出しはsizeof（opus_int32）を使用していましたが、ローカルバッファのタイプはopus_int16でした。
2. Because the size was wrong, this potentially allowed the source and destination regions of the memcpy() to overlap on the copy from "buf" to "buf". We believe that nSamplesIn (number of input samples) is at least fs_in_khZ (sampling rate in kHz), which is at least 8. Since RESAMPLER_ORDER_FIR_12 is only 8, that should not be a problem once the type size is fixed.
2. サイズが間違っていたため、これによりmemcpy()のソース領域と宛先領域が「buf」から「buf」へのコピーでオーバーラップする可能性がありました。 nSamplesIn（入力サンプルの数）は、少なくともfs_in_khZ（kHz単位のサンプリングレート）であり、少なくとも8であると考えています。RESAMPLER_ORDER_FIR_12は8しかないので、型のサイズが固定されれば問題にはなりません。
3. The size of the buffer used RESAMPLER_MAX_BATCH_SIZE_IN, but the data stored in it was actually twice the input batch size (nSamplesIn<<1).
3. バッファのサイズはRESAMPLER_MAX_BATCH_SIZE_INを使用しましたが、バッファに格納されたデータは実際には入力バッチサイズの2倍でした（nSamplesIn << 1）。
The code can be fixed by applying the following changes around line 78 of silk/resampler_private_IIR_FIR.c:
コードは、silk / resampler_private_IIR_FIR.cの78行目に次の変更を適用することで修正できます。
<CODE BEGINS>
<コード開始>
)
{
silk_resampler_state_struct *S = \
(silk_resampler_state_struct *)SS;
opus_int32 nSamplesIn;
opus_int32 max_index_Q16, index_increment_Q16;
- opus_int16 buf[ RESAMPLER_MAX_BATCH_SIZE_IN + \
RESAMPLER_ORDER_FIR_12 ];
+ opus_int16 buf[ 2*RESAMPLER_MAX_BATCH_SIZE_IN + \
RESAMPLER_ORDER_FIR_12 ];
/* Copy buffered samples to start of buffer */
- silk_memcpy( buf, S->sFIR, RESAMPLER_ORDER_FIR_12 \
* sizeof( opus_int32 ) );
+ silk_memcpy( buf, S->sFIR, RESAMPLER_ORDER_FIR_12 \
* sizeof( opus_int16 ) );
/* Iterate over blocks of frameSizeIn input samples */
index_increment_Q16 = S->invRatio_Q16;
while( 1 ) {
nSamplesIn = silk_min( inLen, S->batchSize );
/* Upsample 2x */
silk_resampler_private_up2_HQ( S->sIIR, &buf[ \
RESAMPLER_ORDER_FIR_12 ], in, nSamplesIn );
max_index_Q16 = silk_LSHIFT32( nSamplesIn, 16 + 1 \
); /* + 1 because 2x upsampling */
out = silk_resampler_private_IIR_FIR_INTERPOL( out, \
buf, max_index_Q16, index_increment_Q16 );
in += nSamplesIn;
inLen -= nSamplesIn;
if( inLen > 0 ) {
/* More iterations to do; copy last part of \
filtered signal to beginning of buffer */
- silk_memcpy( buf, &buf[ nSamplesIn << 1 ], \
RESAMPLER_ORDER_FIR_12 * sizeof( opus_int32 ) );
+ silk_memmove( buf, &buf[ nSamplesIn << 1 ], \
RESAMPLER_ORDER_FIR_12 * sizeof( opus_int16 ) );
} else {
break;
}
}
/* Copy last part of filtered signal to the state for \
the next call */
- silk_memcpy( S->sFIR, &buf[ nSamplesIn << 1 ], \
RESAMPLER_ORDER_FIR_12 * sizeof( opus_int32 ) );
+ silk_memcpy( S->sFIR, &buf[ nSamplesIn << 1 ], \
RESAMPLER_ORDER_FIR_12 * sizeof( opus_int16 ) );
}
<CODE ENDS>
It was discovered through decoder fuzzing that some bitstreams could produce integer values exceeding 32 bits in LPC_inverse_pred_gain_QA(), causing a wrap-around. The C standard considers this behavior as undefined. The following patch around line 87 of silk/LPC_inv_pred_gain.c detects values that do not fit in a 32-bit integer and considers the corresponding filters unstable:
一部のビットストリームがLPC_inverse_pred_gain_QA()で32ビットを超える整数値を生成し、ラップアラウンドを引き起こす可能性があることが、デコーダファジングによって発見されました。 C標準では、この動作は未定義と見なされています。次のSilk / LPC_inv_pred_gain.cの87行目のパッチは、32ビット整数に適合しない値を検出し、対応するフィルターを不安定と見なします。
<CODE BEGINS>
/* Update AR coefficient */
for( n = 0; n < k; n++ ) {
- tmp_QA = Aold_QA[ n ] - MUL32_FRAC_Q( \
Aold_QA[ k - n - 1 ], rc_Q31, 31 );
- Anew_QA[ n ] = MUL32_FRAC_Q( tmp_QA, rc_mult2 , mult2Q );
+ opus_int64 tmp64;
+ tmp_QA = silk_SUB_SAT32( Aold_QA[ n ], MUL32_FRAC_Q( \
Aold_QA[ k - n - 1 ], rc_Q31, 31 ) );
+ tmp64 = silk_RSHIFT_ROUND64( silk_SMULL( tmp_QA, \
rc_mult2 ), mult2Q);
+ if( tmp64 > silk_int32_MAX || tmp64 < silk_int32_MIN ) {
+ return 0;
+ }
+ Anew_QA[ n ] = ( opus_int32 )tmp64;
}
<CODE ENDS>
It was discovered -- also from decoder fuzzing -- that an integer wrap-around could occur when decoding bitstreams with extremely large values for the high Line Spectral Frequency (LSF) parameters. The end result of the wrap-around is an illegal read access on the stack, which the authors do not believe is exploitable but should nonetheless be fixed. The following patch around line 137 of silk/ NLSF_stabilize.c prevents the problem:
高いラインスペクトル周波数（LSF）パラメーターの値が非常に大きいビットストリームをデコードすると、整数のラップアラウンドが発生する可能性があることが、デコーダーのファジングからも発見されました。ラップアラウンドの最終結果は、スタックへの不正な読み取りアクセスです。これは、作者が悪用可能であるとは信じていませんが、それでも修正する必要があります。次のSilk / NLSF_stabilize.cの137行目のパッチは、問題を回避します。
<CODE BEGINS>
/* Keep delta_min distance between the NLSFs */
for( i = 1; i < L; i++ )
- NLSF_Q15[i] = silk_max_int( NLSF_Q15[i], \
NLSF_Q15[i-1] + NDeltaMin_Q15[i] );
+ NLSF_Q15[i] = silk_max_int( NLSF_Q15[i], \
silk_ADD_SAT16( NLSF_Q15[i-1], NDeltaMin_Q15[i] ) );
/* Last NLSF should be no higher than 1 - NDeltaMin[L] */
<CODE ENDS>
On extreme bitstreams, it is possible for log-domain band energy levels to exceed the maximum single-precision floating point value once converted to a linear scale. This would later cause the decoded values to be NaN (not a number), possibly causing problems in the software using the PCM values. This can be avoided with the following patch around line 552 of celt/quant_bands.c:
極端なビットストリームでは、線形スケールに変換すると、ログドメインバンドのエネルギーレベルが最大単精度浮動小数点値を超える可能性があります。これにより、後でデコードされた値がNaN（数値ではない）になり、PCM値を使用するソフトウェアで問題が発生する可能性があります。これは、celt / quant_bands.cの552行目の次のパッチで回避できます。
<CODE BEGINS>
{
opus_val16 lg = ADD16(oldEBands[i+c*m->nbEBands],
SHL16((opus_val16)eMeans[i],6));
+ lg = MIN32(QCONST32(32.f, 16), lg);
eBands[i+c*m->nbEBands] = PSHR32(celt_exp2(lg),4);
}
for (;i<m->nbEBands;i++)
<CODE ENDS>
When encoding in hybrid mode at low bitrate, we sometimes only have enough bits to code a single Constrained-Energy Lapped Transform (CELT) band (8 - 9.6 kHz). When that happens, the second band (CELT band 18, from 9.6 - 12 kHz) cannot use folding because it is wider than the amount already coded and falls back to white noise. Because it can also happen on transients (e.g., stops), it can cause audible pre-echo.
低ビットレートのハイブリッドモードでエンコードする場合、単一の制約付きエネルギー変換（CELT）帯域（8〜9.6 kHz）をコード化するのに十分なビットしかない場合があります。その場合、2番目の帯域（CELT帯域18、9.6〜12 kHz）はフォールディングを使用できません。フォールディングは、すでにコーディングされている量よりも広く、ホワイトノイズにフォールバックするためです。トランジェント（停止など）でも発生する可能性があるため、プリエコーが聞こえる可能性があります。
To address the issue, we change the folding behavior so that it is never forced to fall back to Linear Congruential Generator (LCG) due to the first band not containing enough coefficients to fold onto the second band. This is achieved by simply repeating part of the first band in the folding of the second band. This changes the code in celt/bands.c around line 1237:
この問題に対処するために、最初のバンドに2番目のバンドにフォールドするのに十分な係数が含まれていないため、線形合同ジェネレーター（LCG）に強制的にフォールバックしないようにフォールディング動作を変更します。これは、2番目のバンドの折りたたみで最初のバンドの一部を単に繰り返すことによって達成されます。これにより、1237行目あたりのcelt / bands.cのコードが変更されます。
<CODE BEGINS>
b = 0;
}
- if (resynth && M*eBands[i]-N >= M*eBands[start] && \ (update_lowband || lowband_offset==0)) + if (resynth && (M*eBands[i]-N >= M*eBands[start] || \ i==start+1) && (update_lowband || lowband_offset==0)) lowband_offset = i;
- if（resynth && M * eBands [i] -N> = M * eBands [start] && \（update_lowband || lowband_offset == 0））+ if（resynth &&（M * eBands [i] -N> = M * eBands [start] || \ i == start + 1）&&（update_lowband || lowband_offset == 0））lowband_offset = i;
+ if (i == start+1) + { + int n1, n2; + int offset; + n1 = M*(eBands[start+1]-eBands[start]); + n2 = M*(eBands[start+2]-eBands[start+1]); + offset = M*eBands[start]; + /* Duplicate enough of the first band folding data to \ be able to fold the second band. + Copies no data for CELT-only mode. */ + OPUS_COPY(&norm[offset+n1], &norm[offset+2*n1 - n2], n2-n1); + if (C==2) + OPUS_COPY(&norm2[offset+n1], &norm2[offset+2*n1 - n2], \ n2-n1); + } + tf_change = tf_res[i]; if (i>=m->effEBands) { <CODE ENDS>
+ if（i == start + 1）+ {+ int n1、n2; + intオフセット; + n1 = M *（eBands [start + 1] -eBands [start]）; + n2 = M *（eBands [start + 2] -eBands [start + 1]）; +オフセット= M * eBands [開始]; + / * 2番目のバンドを折りたたむことができるように、最初のバンド折りたたみデータを十分に複製します。 + CELTのみのモードではデータをコピーしません。 * / + OPUS_COPY（＆norm [offset + n1]、＆norm [offset + 2 * n1-n2]、n2-n1）; + if（C == 2）+ OPUS_COPY（＆norm2 [offset + n1]、＆norm2 [offset + 2 * n1-n2]、\ n2-n1）; +} + tf_change = tf_res [i]; if（i> = m-> effEBands）{<コード終了>
as well as around line 1260:
1260行目と同様に：
<CODE BEGINS>
fold_start = lowband_offset;
while(M*eBands[--fold_start] > effective_lowband);
fold_end = lowband_offset-1;
- while(M*eBands[++fold_end] < effective_lowband+N);
+ while(++fold_end < i && M*eBands[fold_end] < \
effective_lowband+N);
x_cm = y_cm = 0;
fold_i = fold_start; do {
x_cm |= collapse_masks[fold_i*C+0];
<CODE ENDS>
<コード終了>
The fix does not impact compatibility, because the improvement does not depend on the encoder doing anything special. There is also no reasonable way for an encoder to use the original behavior to improve quality over the proposed change.
改善はエンコーダーが特別なことをすることに依存しないため、修正は互換性に影響を与えません。エンコーダーが元の動作を使用して、提案された変更よりも品質を向上させるための合理的な方法もありません。
The last issue is not strictly a bug, but it is an issue that has been reported 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 canceled, sometimes resulting in audible artifacts.
最後の問題は厳密にはバグではありませんが、Opusデコードストリームをモノラルにダウンミックスするときに、これがデコーダー内で行われるか、ステレオデコーダー出力の後処理ステップとして行われるかに関係なく報告されている問題です。 Opus Intensityステレオでは、オプションで2つのチャネルを帯域ごとに180度位相をずらしてコーディングできます。これにより、2つのチャネルを強制的に同相にするよりもステレオ品質が向上しますが、出力をモノラルにダウンミックスすると、影響を受ける帯域のエネルギーがキャンセルされ、時々可聴アーティファクトが発生します。
As a work-around for this issue, the decoder MAY choose not to apply the 180-degree phase shift. This can be useful when downmixing to mono inside or outside of the decoder (e.g., requested explicitly from an API).
この問題の回避策として、デコーダーは180度の位相シフトを適用しないことを選択できます（MAY）。これは、デコーダーの内部または外部でモノにダウンミックスする場合に役立ちます（たとえば、APIから明示的に要求されます）。
Changes in Sections 9 and 10 have sufficient impact on the test vectors to make them fail. For this reason, this document also updates the Opus test vectors. The new test vectors now include two decoded outputs for the same bitstream. The outputs with suffix 'm' do not apply the CELT 180-degree phase shift as allowed in Section 10, while the outputs without the suffix do. An implementation is compliant as long as it passes either set of vectors.
セクション9と10の変更は、テストベクトに十分な影響を与えて失敗させます。このため、このドキュメントではOpusテストベクトルも更新しています。新しいテストベクタには、同じビットストリームの2つのデコードされた出力が含まれています。接尾辞が「m」の出力は、セクション10で許可されているCELT 180度位相シフトを適用しませんが、接尾辞のない出力は適用します。実装は、いずれかのベクトルのセットを渡す限り、準拠しています。
Any Opus implementation that passes either the original test vectors from RFC 6716 [RFC6716] or one of the new sets of test vectors is compliant with the Opus specification. However, newer implementations SHOULD be based on the new test vectors rather than the old ones.
RFC 6716 [RFC6716]の元のテストベクトルまたは新しいテストベクトルセットの1つを渡すOpus実装は、Opus仕様に準拠しています。しかしながら、新しい実装は古いものではなく新しいテストベクターに基づいているべきです（SHOULD）。
The new test vectors are located at <https://www.ietf.org/proceedings/98/slides/materials-98-codec-opus-newvectors-00.tar.gz>. The SHA-1 hashes of the test vectors are:
新しいテストベクタは<https://www.ietf.org/proceedings/98/slides/materials-98-codec-opus-newvectors-00.tar.gz>にあります。テストベクトルのSHA-1ハッシュは次のとおりです。
e49b2862ceec7324790ed8019eb9744596d5be01 testvector01.bit b809795ae1bcd606049d76de4ad24236257135e0 testvector02.bit e0c4ecaeab44d35a2f5b6575cd996848e5ee2acc testvector03.bit a0f870cbe14ebb71fa9066ef3ee96e59c9a75187 testvector04.bit 9b3d92b48b965dfe9edf7b8a85edd4309f8cf7c8 testvector05.bit 28e66769ab17e17f72875283c14b19690cbc4e57 testvector06.bit bacf467be3215fc7ec288f29e2477de1192947a6 testvector07.bit ddbe08b688bbf934071f3893cd0030ce48dba12f testvector08.bit 3932d9d61944dab1201645b8eeaad595d5705ecb testvector09.bit 521eb2a1e0cc9c31b8b740673307c2d3b10c1900 testvector10.bit 6bc8f3146fcb96450c901b16c3d464ccdf4d5d96 testvector11.bit 338c3f1b4b97226bc60bc41038becbc6de06b28f testvector12.bit f5ef93884da6a814d311027918e9afc6f2e5c2c8 testvector01.dec 48ac1ff1995250a756e1e17bd32acefa8cd2b820 testvector02.dec d15567e919db2d0e818727092c0af8dd9df23c95 testvector03.dec 1249dd28f5bd1e39a66fd6d99449dca7a8316342 testvector04.dec b85675d81deef84a112c466cdff3b7aaa1d2fc76 testvector05.dec 55f0b191e90bfa6f98b50d01a64b44255cb4813e testvector06.dec 61e8b357ab090b1801eeb578a28a6ae935e25b7b testvector07.dec a58539ee5321453b2ddf4c0f2500e856b3966862 testvector08.dec bb96aad2cde188555862b7bbb3af6133851ef8f4 testvector09.dec 1b6cdf0413ac9965b16184b1bea129b5c0b2a37a testvector10.dec b1fff72b74666e3027801b29dbc48b31f80dee0d testvector11.dec 98e09bbafed329e341c3b4052e9c4ba5fc83f9b1 testvector12.dec 1e7d984ea3fbb16ba998aea761f4893fbdb30157 testvector01m.dec 48ac1ff1995250a756e1e17bd32acefa8cd2b820 testvector02m.dec d15567e919db2d0e818727092c0af8dd9df23c95 testvector03m.dec 1249dd28f5bd1e39a66fd6d99449dca7a8316342 testvector04m.dec d70b0bad431e7d463bc3da49bd2d49f1c6d0a530 testvector05m.dec 6ac1648c3174c95fada565161a6c78bdbe59c77d testvector06m.dec fc5e2f709693738324fb4c8bdc0dad6dda04e713 testvector07m.dec aad2ba397bf1b6a18e8e09b50e4b19627d479f00 testvector08m.dec 6feb7a7b9d7cdc1383baf8d5739e2a514bd0ba08 testvector09m.dec 1b6cdf0413ac9965b16184b1bea129b5c0b2a37a testvector10m.dec fd3d3a7b0dfbdab98d37ed9aa04b659b9fefbd18 testvector11m.dec 98e09bbafed329e341c3b4052e9c4ba5fc83f9b1 testvector12m.dec
e49b2862ceec7324790ed8019eb9744596d5be01 testvector01.bit b809795ae1bcd606049d76de4ad24236257135e0 testvector02.bit e0c4ecaeab44d35a2f5b6575cd996848e5ee2acc testvector03.bit a0f870cbe14ebb71fa9066ef3ee96e59c9a75187 testvector04.bit 9b3d92b48b965dfe9edf7b8a85edd4309f8cf7c8 testvector05.bit 28e66769ab17e17f72875283c14b19690cbc4e57 testvector06.bit bacf467be3215fc7ec288f29e2477de1192947a6 testvector07.bit ddbe08b688bbf934071f3893cd0030ce48dba12f testvector08.bit 3932d9d61944dab1201645b8eeaad595d5705ecb testvector09.bit 521eb2a1e0cc9c31b8b740673307c2d3b10c1900 testvector10.bit 6bc8f3146fcb96450c901b16c3d464ccdf4d5d96 testvector11.bit 338c3f1b4b97226bc60bc41038becbc6de06b28f testvector12.bit f5ef93884da6a814d311027918e9afc6f2e5c2c8 testvector01 .dec 48ac1ff1995250a756e1e17bd32acefa8cd2b820 testvector02.dec d15567e919db2d0e818727092c0af8dd9df23c95 testvector03.dec 1249dd28f5bd1e39a66fd6d99449dca71fb1700e7c7cfaf7c140c1cf176c1140c1cca7dc7f7c140c1cca7dc7c7f140c7c7fa7c7dc7c1cf7c7c140c1cdc7c7c7c7fdcdcfa7d0c7c9c9fdcdcfdcdcd7c0f0f0f0f0e3.de 48ac1ff1995250a756e1e17bd32acefa8cd2b820 6f98b50d01a64b44255cb4813e testvector06.dec 61e8b357ab090b1801eeb578a28a6ae935e25b7b testvector07.dec a58539ee5321453b2ddf4c0f2500e856b3966862 testvector08.dec bb96aad2cde188555862b7bbb3af6133851ef8f4 testvector09.dec 1b6cdf0413ac9965b16184b1bea129b5c0b2a37a testvector10.dec b1fff72b74666e3027801b29dbc48b31f80dee0d testvector11.dec 98e09bbafed329e341c3b4052e9c4ba5fc83f9b1 testvector12.dec 1e7d984ea3fbb16ba998aea761f4893fbdb30157 testvector01m.dec 48ac1ff1995250a756e1e17bd32acefa8cd2b820 testvector02m.dec d15567e919db2d0e818727092c0af8dd9df23c95 testvector03m.dec 1249dd28f5bd1e39a66fd6d99449dca7a8316342 testvector04m.dec d70b0bad431e7d463bc3da49bd2d49f1c6d0a530 testvector05m.dec 6ac1648c3174c95fada565161a6c78bdbe59c77d testvector06m .dec fc5e2f709693738324fb4c8bdc0dad6dda04e713 testvector07m.dec aad2ba397bf1b6a18e8e09b50e4b19627d479f00 testvector08m.dec 6feb7a7b9d7cdc1383baf8d5739e2a514bd0ba08 testvector09m.dec 1b6cdf0413ac9965b16184b1bea129b5c0b2a37a testvector10m.dec fd3d3a7b0dfbdab98d 37ed9aa04b659b9fefbd18 testvector11m.dec 98e09bbafed329e341c3b4052e9c4ba5fc83f9b1 testvector12m.dec
Note that the decoder input bitstream files (.bit) are unchanged.
デコーダー入力ビットストリームファイル（.bit）は変更されていないことに注意してください。
This document fixes two security issues reported on Opus that affect the reference implementation in RFC 6716 [RFC6716]: CVE-2013-0899 <https://nvd.nist.gov/vuln/detail/CVE-2013-0899> and CVE-2017-0381 <https://nvd.nist.gov/vuln/detail/CVE-2017-0381>. CVE-2013-0899 theoretically could have caused an information leak. The leaked information would have gone through the decoder process before being accessible to the attacker. The update in Section 4 fixes this. CVE-2017-0381 could have resulted in a 16-bit out-of-bounds read from a fixed location. The update in Section 7 fixes this. Beyond the two fixed Common Vulnerabilities and Exposures (CVEs), this document adds no new security considerations beyond those in RFC 6716 [RFC6716].
このドキュメントは、RFC 6716 [RFC6716]の参照実装に影響を与えるOpusで報告された2つのセキュリティ問題を修正します：CVE-2013-0899 <https://nvd.nist.gov/vuln/detail/CVE-2013-0899>およびCVE- 2017-0381 <https://nvd.nist.gov/vuln/detail/CVE-2017-0381>。 CVE-2013-0899は理論的には情報漏えいの原因でした。漏洩した情報は、攻撃者がアクセスできるようになる前に、デコーダプロセスを通過します。セクション4のアップデートはこれを修正します。 CVE-2017-0381により、固定位置から16ビットの範囲外の読み取りが行われる可能性がありました。セクション7のアップデートでは、これを修正しています。このドキュメントでは、2つの修正されたCommon Vulnerabilities and Exposures（CVE）を超えて、RFC 6716 [RFC6716]のセキュリティに関する考慮事項を超える新しいセキュリティ上の考慮事項を追加していません。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, <https://www.rfc-editor.org/info/rfc6716>.
[RFC6716] Valin、JM。、Vos、K。、およびT. Terriberry、「Definition of the Opus Audio Codec」、RFC 6716、DOI 10.17487 / RFC6716、2012年9月、<https://www.rfc-editor.org / info / rfc6716>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
Acknowledgements
謝辞
We would like to thank Juri Aedla for reporting the issue with the parsing of the Opus padding. Thanks to Felicia Lim for reporting the LSF integer overflow issue. Also, thanks to Tina le Grand, Jonathan Lennox, and Mark Harris for their feedback on this document.
オーパスパディングの解析に関する問題を報告してくださったJuri Aedlaに感謝いたします。 LSF整数オーバーフローの問題を報告してくれたFelicia Limに感謝します。また、このドキュメントに関するフィードバックを提供してくれたTina le Grand、Jonathan Lennox、Mark Harrisにも感謝します。
Authors' Addresses
著者のアドレス
Jean-Marc Valin Mozilla Corporation 331 E. Evelyn Avenue Mountain View, CA 94041 United States of America
Jean-Marc Valin Mozilla Corporation 331 E. Evelyn Avenue Mountain View、CA 94041アメリカ合衆国
Phone: +1 650 903-0800
Email: jmvalin@jmvalin.ca
Koen Vos vocTone
こえん ゔぉｓ ゔぉｃとね
Email: koenvos74@gmail.com