[要約] 要約： RFC 6569は、IETF内でオーディオコーデックの開発に関するガイドラインを提供しています。目的： 1. IETFメンバーに対して、オーディオコーデックの開発におけるベストプラクティスを提供する。 2. オーディオコーデックの標準化プロセスを効果的に進めるための指針を提供する。 3. オーディオコーデックの開発者間でのコミュニケーションと協力を促進する。
Internet Engineering Task Force (IETF) JM. Valin
Request for Comments: 6569 Mozilla
Category: Informational S. Borilin
ISSN: 2070-1721 SPIRIT DSP
K. Vos
C. Montgomery Xiph.Org Foundation R. Chen Broadcom Corporation March 2012
C. Montgomery Xiph.Org Foundation R. Chen Broadcom Corporation 2012年3月
Guidelines for Development of an Audio Codec within the IETF
IETF内のオーディオコーデックの開発に関するガイドライン
Abstract
概要
This document provides general guidelines for work on developing and specifying an interactive audio codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues.
このドキュメントは、IETF内でインタラクティブオーディオコーデックを開発および指定する作業に関する一般的なガイドラインを提供します。これらのガイドラインは、開発プロセス、評価、要件の準拠、および知的財産の問題をカバーしています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6569.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6569で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Development Process .............................................2
3. Evaluation, Testing, and Characterization .......................5
4. Specifying the Codec ............................................6
5. Intellectual Property ...........................................8
6. Relationship with Other SDOs ...................................10
7. Security Considerations ........................................12
8. Acknowledgments ................................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................12
This document describes a process for work in the IETF codec WG on standardization of an audio codec that is optimized for use in interactive Internet applications and that can be widely implemented and easily distributed among application developers, service operators, and end users.
このドキュメントでは、インタラクティブなインターネットアプリケーションでの使用に最適化され、アプリケーション開発者、サービスオペレーター、エンドユーザーに簡単に配布できる、オーディオコーデックの標準化に関するIETFコーデックWGでの作業プロセスについて説明します。
The process outlined here is intended to make the work on a codec within the IETF transparent, predictable, and well organized, in a way that is consistent with [PROCESS]. Such work might involve development of a completely new codec, adaptation of an existing codec to meet the requirements of the working group, or integration of two or more existing codecs that results in an improved codec combining the best aspects of each. To enable such procedural transparency, the contributor of an existing codec must be willing to cede change control to the IETF and should have sufficient knowledge of the codec to assist in the work of adapting it or applying some of its technology to the development or improvement of other codecs. Furthermore, contributors need to be aware that any codec that results from work within the IETF is likely to be different from any existing codec that was contributed to the Internet Standards Process.
ここで概説するプロセスは、[プロセス]と一貫した方法で、IETF内のコーデックでの作業を透過的、予測可能、かつ適切に構成することを目的としています。そのような作業には、完全に新しいコーデックの開発、ワーキンググループの要件を満たすための既存のコーデックの適応、またはそれぞれの最良の側面を組み合わせた改善されたコーデックをもたらす2つ以上の既存のコーデックの統合が含まれます。このような手続きの透明性を実現するには、既存のコーデックの寄稿者がIETFへの変更管理を喜んで承諾する必要があり、コーデックの十分な知識を持っている必要があります。他のコーデック。さらに、寄稿者は、IETF内の作業から生じるコーデックは、インターネット標準プロセスに寄稿された既存のコーデックとは異なる可能性があることを認識する必要があります。
Work on developing an interactive audio codec is expected to proceed as follows:
インタラクティブオーディオコーデックの開発作業は、次のように進められます。
1. IETF participants will identify the requirements to be met by an Internet codec in the form of an Internet-Draft.
1. IETFの参加者は、インターネットドラフトの形式でインターネットコーデックが満たすべき要件を特定します。
2. Interested parties are encouraged to make contributions proposing existing or new codecs, or elements thereof, to the codec WG as long as these contributions are within the scope of the WG. Ideally, these contributions should be in the form of Internet-Drafts, although other forms of contributions are also possible, as discussed in [PROCESS].
2. 利害関係者は、これらの寄稿がWGの範囲内である限り、コーデックWGに既存または新しいコーデックまたはその要素を提案する寄稿を行うことをお勧めします。 [PROCESS]で説明されているように、他の形式の投稿も可能ですが、これらの投稿はインターネットドラフトの形式であることが理想的です。
3. Given the importance of intellectual property rights (IPR) to the activities of the working group, any IPR disclosures must be made in a timely way. Contributors are required, as described in [IPR], to disclose any known IPR, both first and third party. Timely disclosures are particularly important, since those disclosures may be material to the decision process of the working group.
3. ワーキンググループの活動に対する知的財産権（IPR）の重要性を考えると、IPRの開示はタイムリーに行う必要があります。 [IPR]で説明されているように、寄稿者は、既知のIPRをファーストパーティとサードパーティの両方で開示する必要があります。タイムリーな開示は、ワーキンググループの決定プロセスにとって重要になる可能性があるため、特に重要です。
4. As contributions are received and discussed within the working group, the group should gain a clearer understanding of what is achievable within the design space. As a result, the authors of the requirements document should iteratively clarify and improve their document to reflect the emerging working group consensus. This is likely to involve collaboration with IETF working groups in other areas, such as collaboration with working groups in the Transport area to identify important aspects of packet transmission over the Internet and to understand the degree of rate adaptation desirable and with working groups in the RAI area to ensure that information about and negotiation of the codec can be easily represented at the signaling layer. In parallel with this work, interested parties should evaluate the contributions at a higher level to see which requirements might be met by each codec.
4. 作業グループ内で貢献が受け取られ、議論されると、グループは設計空間内で何が達成可能であるかをより明確に理解する必要があります。その結果、要件ドキュメントの作成者は、新たに作成されたワーキンググループのコンセンサスを反映するために、ドキュメントを繰り返し明確化および改善する必要があります。これには、インターネットを介したパケット送信の重要な側面を特定し、望ましいレート適応の度合いを理解し、RAIのワーキンググループとの理解を深めるために、トランスポートエリアのワーキンググループとのコラボレーションなど、他のエリアのIETFワーキンググループとのコラボレーションが含まれる可能性があります。コーデックの情報とネゴシエーションがシグナリング層で簡単に表現できることを保証する領域。この作業と並行して、関係者はより高いレベルで貢献を評価して、各コーデックがどの要件を満たすことができるかを確認する必要があります。
5. Once a sufficient number of proposals has been received, the interested parties will identify the strengths, weaknesses, and innovative aspects of the contributed codecs. This step will consider not only the codecs as a whole, but also key features of the individual algorithms (predictors, quantizers, transforms, etc.).
5. 十分な数の提案を受け取ったら、関係者は、提供されたコーデックの長所、短所、革新的な側面を特定します。このステップでは、コーデック全体だけでなく、個々のアルゴリズム（予測子、量子化器、変換など）の主要な機能も考慮します。
6. Interested parties are encouraged to collaborate and combine the best ideas from the various codec contributions into a consolidated codec definition, representing the merging of some of the contributions. Through this iterative process, the number of proposals will reduce, and consensus will generally form around one of them. At that point, the working group should adopt that document as a working group item, forming a baseline codec.
6.利害関係者は、さまざまなコーデックの貢献からの最良のアイデアを協力して結合し、統合されたコーデックの定義にまとめることが推奨されます。この反復プロセスにより、提案の数は減少し、コンセンサスは一般にそのうちの1つを中心に形成されます。その時点で、ワーキンググループはそのドキュメントをワーキンググループアイテムとして採用し、ベースラインコーデックを形成する必要があります。
7. IETF participants should then attempt to iteratively add to or improve each component of the baseline codec reference implementation, where by "component" we mean individual algorithms such as predictors, transforms, quantizers, and entropy coders. The participants should proceed by trying new designs, applying ideas from the contributed codecs, evaluating "proof of concept" ideas, and using their expertise in codec development to improve the baseline codec. Any aspect of the baseline codec might be changed (even the fundamental principles of the codec), or the participants might start over entirely by scrapping the baseline codec and designing a completely new one. The overriding goal shall be to design a codec that will meet the requirements defined in the requirements document [CODEC-REQ]. Given the IETF's open standards process, any interested party will be able to contribute to this work, whether or not they submitted an Internet-Draft for one of the contributed codecs. The codec itself should be normatively specified with code in an Internet-Draft.
7. IETFの参加者は、ベースラインコーデックのリファレンス実装の各コンポーネントを繰り返し追加または改善しようとする必要があります。「コンポーネント」とは、予測子、変換、量子化器、エントロピーコーダーなどの個々のアルゴリズムを意味します。参加者は、新しいデザインを試し、寄付されたコーデックからのアイデアを適用し、「概念実証」のアイデアを評価し、コーデック開発の専門知識を使用してベースラインコーデックを改善することから始めます。ベースラインコーデックの任意の側面が変更される可能性があります（コーデックの基本的な原理でさえも）。または、参加者はベースラインコーデックを破棄して完全に新しいコーデックを設計することから始めます。最優先の目標は、要件ドキュメント[CODEC-REQ]で定義された要件を満たすコーデックを設計することです。 IETFのオープンスタンダードプロセスを考慮すると、提供されたコーデックの1つにインターネットドラフトを提出したかどうかに関係なく、関係者はこの作業に貢献できます。コーデック自体は、インターネットドラフトのコードで規範的に指定する必要があります。
8. In parallel with work on the codec reference implementation, developers and other interested parties should perform evaluation of the codec as described under Section 3. IETF participants should define (within the PAYLOAD working group) the codec's payload format for use with the Real-time Transport Protocol [RTP]. Ideally, application developers should test the codec by implementing it in code and deploying it in actual Internet applications. Unfortunately, developers will frequently wait to deploy the codec until it is published as an RFC or until a stable bitstream is guaranteed. As such, this is a nice-to-have and not a requirement for this process. Lab implementations are certainly encouraged.
8. コーデックリファレンス実装の作業と並行して、開発者およびその他の関係者は、セクション3で説明されているようにコーデックの評価を実行する必要があります。IETF参加者は、リアルタイムトランスポートで使用するコーデックのペイロード形式を（PAYLOADワーキンググループ内で）定義する必要がありますプロトコル[RTP]。理想的には、アプリケーション開発者は、コードをコードに実装して実際のインターネットアプリケーションに展開することにより、コーデックをテストする必要があります。残念ながら、開発者は、コーデックがRFCとして公開されるか、安定したビットストリームが保証されるまで、コーデックの展開を頻繁に待ちます。したがって、これは便利な機能であり、このプロセスの要件ではありません。ラボの実装は確かに推奨されます。
9. The group will produce a testing results document. The document will be a living document that captures testing done before the codec stabilized, after it has stabilized, and after the codec specification is issued as an RFC. The document serves the purpose of helping the group determine whether the codec meets the requirements. Any testing done after the codec RFC is issued helps implementers understand the final performance of the codec. The process of testing is described in Section 3.
9. グループはテスト結果のドキュメントを作成します。ドキュメントは、コーデックが安定する前、安定した後、およびコーデック仕様がRFCとして発行された後に行われたテストをキャプチャする生きたドキュメントになります。このドキュメントは、コーデックが要件を満たしているかどうかをグループが判断するのに役立つ目的を果たします。コーデックRFCの発行後に行われたテストは、実装者がコーデックの最終的なパフォーマンスを理解するのに役立ちます。テストのプロセスについては、セクション3で説明します。
Lab evaluation of the codec being developed should happen throughout the development process because it will help ensure that progress is being made toward fulfillment of the requirements. There are many ways in which continuous evaluation can be performed. For minor, uncontroversial changes to the codec, it should usually be sufficient to use objective measurements (e.g., Perceptual Evaluation of Speech Quality (PESQ) [ITU-T-P.862], Perceptual Evaluation of Audio Quality (PEAQ) [ITU-R-BS.1387-1], and segmental signal-to-noise ratio) validated by informal subjective evaluation. For more complex changes (e.g., when psychoacoustic aspects are involved) or for controversial issues, internal testing should be performed. An example of internal testing would be to have individual participants rate the decoded samples using one of the established testing methodologies, such as MUltiple Stimuli with Hidden Reference and Anchor (MUSHRA) [ITU-R-BS.1534].
開発中のコーデックのラボ評価は、開発プロセス全体を通じて行う必要があります。これは、要件の達成に向けて確実に進歩するためです。継続的な評価を行う方法はたくさんあります。コーデックに対する問題のないマイナーな変更については、通常、客観的な測定値（たとえば、音声品質の知覚評価（PESQ）[ITU-TP.862]、音声品質の知覚評価（PEAQ）[ITU-R- BS.1387-1]、および非公式の主観的評価によって検証されたセグメント信号対雑音比）。より複雑な変更（たとえば、心理音響学的側面が関与する場合）や物議を醸す問題については、内部テストを実行する必要があります。内部テストの例は、確立されたテスト方法論の1つを使用して、デコードされたサンプルを個々の参加者に評価させることです。たとえば、隠れた参照とアンカーを備えたMUltiple刺激（MUSHRA）[ITU-R-BS.1534]です。
Throughout the process, it will be important to make use of the Internet community at large for real-world distributed testing. This will enable many different people with different equipment and use cases to test the codec and report any problems they experience. In the same way, third-party developers will be encouraged to integrate the codec into their software (with a warning about the bitstream not being final) and provide feedback on its performance in real-world use cases.
プロセス全体を通して、実際の分散テストにインターネットコミュニティ全体を利用することが重要です。これにより、さまざまな機器と使用例を持つ多くの異なる人々がコーデックをテストし、彼らが経験する問題を報告することができます。同様に、サードパーティの開発者は、コーデックをソフトウェアに統合し（ビットストリームが最終的なものではないという警告付き）、実際の使用例でのパフォーマンスに関するフィードバックを提供することが推奨されます。
Characterization of the final codec must be based on the reference implementation only (and not on any "private implementation"). This can be performed by independent testing labs or, if this is not possible, by testing labs of the organizations that contribute to the Internet Standards Process. Packet-loss robustness should be evaluated using actual loss patterns collected from use over the Internet, rather than theoretical models. The goals of the characterization phase are to:
最終的なコーデックの特性評価は、リファレンス実装のみに基づいている必要があります（「プライベート実装」には基づいていません）。これは、独立したテストラボで実行できます。これが不可能な場合は、インターネット標準プロセスに貢献している組織のテストラボで実行できます。パケット損失の堅牢性は、理論上のモデルではなく、インターネット上での使用から収集された実際の損失パターンを使用して評価する必要があります。特性評価フェーズの目標は次のとおりです。
o ensure that the requirements have been fulfilled
o 要件が満たされていることを確認する
o guide the IESG in its evaluation of the resulting work
o 結果として生じる作業の評価においてIESGを導く
o assist application developers in understanding whether the codec is suitable for a particular application
o コーデックが特定のアプリケーションに適しているかどうかをアプリケーション開発者が理解するのを支援する
The exact methodology for the characterization phase can be determined by the working group. Because the IETF does not have testing resources of its own, it has to rely on the resources of its participants. For this reason, even if the group agrees that a particular test is important, if no one volunteers to do it, or if volunteers do not complete it in a timely fashion, then that test should be discarded. This ensures that only important tests be done -- in particular, the tests that are important to participants.
特性評価フェーズの正確な方法論は、ワーキンググループが決定できます。 IETFには独自のテストリソースがないため、参加者のリソースに依存する必要があります。このため、特定のテストが重要であるとグループが同意した場合でも、誰も志願していない場合、または志願者がタイムリーにテストを完了していない場合は、そのテストを破棄する必要があります。これにより、重要なテスト、特に参加者にとって重要なテストのみが実行されます。
Specifying a codec requires careful consideration regarding what is required versus what is left to the implementation. The following text provides guidelines for consideration by the working group:
コーデックを指定するには、何が必要であるか、何が実装に任されているかについて慎重に検討する必要があります。次のテキストは、ワーキンググループによる検討のためのガイドラインを提供します。
1. Any audio codec specified by the codec working group must include source code for a normative software implementation, documented in an Internet-Draft intended for publication as a Standards Track RFC. This implementation will be used to verify conformance of an implementation. Although a text description of the algorithm should be provided, its use should be limited to helping the reader in understanding the source code. Should the description contradict the source code, the latter shall take precedence. For convenience, the source code may be provided in compressed form, with base64 [BASE64] encoding.
1. コーデックワーキンググループによって指定されたすべてのオーディオコーデックには、Standards Track RFCとして公開することを目的としたInternet-Draftに文書化されている、規範的なソフトウェア実装のソースコードを含める必要があります。この実装は、実装の適合性を検証するために使用されます。アルゴリズムのテキストによる説明を提供する必要がありますが、その使用は、読者がソースコードを理解するのに役立つように制限する必要があります。説明がソースコードと矛盾する場合は、後者が優先されます。便宜上、ソースコードはbase64 [BASE64]エンコーディングを使用して圧縮形式で提供できます。
2. Because of the size and complexity of most codecs, it is possible that even after publishing the RFC, bugs will be found in the reference implementation, or differences will be found between the implementation and the text description. As usual, an errata list should be maintained for the RFC. Although a public software repository containing the current reference implementation is desirable, the normative implementation would still be the RFC.
2. ほとんどのコーデックのサイズと複雑さのため、RFCを公開した後でも、リファレンス実装にバグが見つかるか、実装とテキストの説明に違いが見つかる可能性があります。いつものように、RFCのエラッタリストを維持する必要があります。現在のリファレンス実装を含む公開ソフトウェアリポジトリが望ましいですが、規範的な実装はRFCのままです。
3. It is the intention of the group to allow the greatest possible choice of freedom in implementing the specification. Accordingly, the number of binding RFC 2119 [KEYWORDS] keywords will be the minimum that still allows interoperable implementations. In practice, this generally means that only the decoder needs to be normative, so that the encoder can improve over time. This also enables different trade-offs between quality and complexity.
3. グループの意図は、仕様を実装する際に最大限の自由の選択を可能にすることです。したがって、バインディングRFC 2119 [KEYWORDS]キーワードの数は、相互運用可能な実装を可能にする最小数になります。実際には、これは一般にデコーダーのみが規範的である必要があることを意味し、エンコーダーは時間とともに改善することができます。これにより、品質と複雑さの間のさまざまなトレードオフも可能になります。
4. To reduce the risk of bias towards certain CPU/DSP (central processing unit / digital signal processor) architectures, ideally the decoder specification should not require "bit-exact" conformance with the reference implementation. In that case, the output of a decoder implementation should only be "close enough" to the output of the reference decoder, and a comparison tool should be provided along with the codec to verify objectively that the output of a decoder is likely to be perceptually indistinguishable from that of the reference decoder. An implementation may still wish to produce an output that is bit-exact with the reference implementation to simplify the testing procedure.
4.特定のCPU / DSP（中央処理装置/デジタル信号プロセッサ）アーキテクチャへの偏りのリスクを低減するために、理想的には、デコーダの仕様は、リファレンス実装との「ビット厳密な」適合を要求してはなりません。その場合、デコーダー実装の出力は、参照デコーダーの出力に「十分に近い」だけであり、比較ツールをコーデックと共に提供して、デコーダーの出力が知覚的になりそうであることを客観的に検証する必要があります。参照デコーダーと区別がつかない。実装では、テスト手順を簡略化するために、リファレンス実装とビット正確な出力を生成したい場合があります。
5. To ensure freedom of implementation, decoder-side-only error concealment does not need to be specified, although the reference implementation should include the same packet-loss concealment (PLC) algorithm as used in the testing phase. Is it up to the working group to decide whether minimum requirements on PLC quality will be required for compliance with the specification. Obviously, any information signaled in the bitstream intended to aid PLC needs to be specified.
5. 実装の自由を確保するために、参照実装にはテスト段階で使用されたのと同じパケット損失隠蔽（PLC）アルゴリズムを含める必要がありますが、デコーダー側のみのエラー隠蔽を指定する必要はありません。 PLC品質の最小要件が仕様に準拠するために必要かどうかを決定するのはワーキンググループの責任ですか。明らかに、PLCを支援することを目的としたビットストリームでシグナリングされた情報はすべて指定する必要があります。
6. An encoder implementation should not be required to make use of all the "features" (tools) in the bitstream definition. However, the codec specification may require that an encoder implementation be able to generate any possible bitrate. Unless a particular "profile" is defined in the specification, the decoder must be able to decode all features of the bitstream. The decoder must also be able to handle any combination of bits, even combinations that cannot be generated by the reference encoder. It is recommended that the decoder specification shall define how the decoder should react to "impossible" packets (e.g., reject or consider as valid). However, an encoder must never generate packets that do not conform to the bitstream definition.
6. エンコーダー実装は、ビットストリーム定義のすべての「機能」（ツール）を利用する必要はありません。ただし、コーデックの仕様では、エンコーダの実装でビットレートを生成できる必要がある場合があります。特定の「プロファイル」が仕様で定義されていない限り、デコーダーはビットストリームのすべての機能をデコードできなければなりません。デコーダーはまた、ビットの任意の組み合わせを処理できなければなりません。リファレンスエンコーダーで生成できない組み合わせでも可能です。デコーダー仕様は、デコーダーが「不可能な」パケットにどのように反応するかを定義することをお勧めします（たとえば、拒否または有効と見なす）。ただし、エンコーダはビットストリーム定義に準拠しないパケットを生成してはなりません。
7. Compressed test vectors should be provided as a means to verify conformance with the decoder specification. These test vectors should be designed to exercise as much of the decoder code as possible.
7. デコーダー仕様との適合性を検証する手段として、圧縮されたテストベクトルを提供する必要があります。これらのテストベクトルは、可能な限り多くのデコーダコードを実行するように設計する必要があります。
8. While the exact encoder will not be specified, it is recommended to specify objective measurement targets for an encoder, below which use of a particular encoder implementation is not recommended. For example, one such specification could be: "the use of an encoder whose PESQ mean opinion score (MOS) is better than 0.1 below the reference encoder in the following conditions is not recommended".
8. 正確なエンコーダーは指定されませんが、エンコーダーの客観的な測定ターゲットを指定することをお勧めします。これを下回ると、特定のエンコーダー実装の使用は推奨されません。たとえば、そのような仕様の1つは、「以下の条件では、PESQ平均オピニオンスコア（MOS）が参照エンコーダーの0.1未満であるエンコーダーの使用は推奨されません」です。
Producing an unencumbered codec is desirable for the following reasons:
次の理由により、障害のないコーデックを作成することが望ましいです。
o It is the experience of a wide variety of application developers and service providers that encumbrances such as licensing and royalties make it difficult to implement, deploy, and distribute multimedia applications for use by the Internet community.
o ライセンスや使用料などの問題により、インターネットコミュニティで使用するマルチメディアアプリケーションの実装、展開、配布が困難になるのは、さまざまなアプリケーション開発者やサービスプロバイダーの経験です。
o It is beneficial to have low-cost options whenever possible, because innovation -- the hallmark of the Internet -- is hampered when small development teams cannot deploy an application because of usage-based licensing fees and royalties.
o 少額の開発チームが使用量ベースのライセンス料とロイヤリティのためにアプリケーションを展開できない場合、イノベーション（インターネットの特徴）が妨げられるため、可能な限り低コストのオプションを用意することは有益です。
o Many market segments are moving away from selling hard-coded hardware devices and toward freely distributing end-user software; this is true of numerous large application providers and even telcos themselves.
o 多くの市場セグメントは、ハードコードされたハードウェアデバイスの販売から、自由に配布できるエンドユーザーソフトウェアへと移行しています。これは、多数の大規模アプリケーションプロバイダー、さらには電話会社自体にも当てはまります。
o Compatibility with the licensing of typical open source applications implies the need to avoid encumbrances, including even the requirement to obtain a license for implementation, deployment, or use (even if the license does not require the payment of a fee).
o 典型的なオープンソースアプリケーションのライセンスとの互換性は、実装、展開、または使用のためのライセンスを取得するための要件も含めて（ライセンスが料金の支払いを必要としない場合でも）、負担を回避する必要があることを意味します。
Therefore, a codec that can be widely implemented and easily distributed among application developers, service operators, and end users is preferred. Many existing codecs that might fulfill some or most of the technical attributes listed above are encumbered in various ways. For example, patent holders might require that those wishing to implement the codec in software, deploy the codec in a service, or distribute the codec in software or hardware need to request a license, enter into a business agreement, pay licensing fees or royalties, or adhere to other special conditions or restrictions. Because such encumbrances have made it difficult to widely implement and easily distribute high-quality codecs across the entire Internet community, the working group prefers unencumbered technologies in a way that is consistent with BCP 78 [IPR] and BCP 79 [TRUST]. In particular, the working group shall heed the preference stated in BCP 79: "In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing." Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall follow and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to redistribute and use.
したがって、広く実装でき、アプリケーション開発者、サービスオペレーター、エンドユーザーの間で簡単に配布できるコーデックが推奨されます。上記の技術的属性の一部またはほとんどを満たす既存のコーデックの多くは、さまざまな方法で妨げられています。たとえば、特許権者は、ソフトウェアにコーデックを実装する、サービスにコーデックを展開する、またはソフトウェアまたはハードウェアにコーデックを配布することを希望する人に、ライセンスの要求、ビジネス契約の締結、ライセンス料の支払い、または使用料の支払いを要求する場合があります。または、他の特別な条件または制限を遵守します。このような制約により、高品質のコーデックをインターネットコミュニティ全体に広く実装して簡単に配布することが難しくなっているため、ワーキンググループは、BCP 78 [IPR]およびBCP 79 [TRUST]と一貫した方法で、妨げられないテクノロジを好みます。特に、ワーキンググループは、BCP 79に記載されている優先事項に注意する必要があります。この選好は、ワーキンググループが邪魔されないコーデックを生成することを保証することはできませんが、ワーキンググループはBCP 79の精神に従い、それに従うものとします。ワーキンググループは、邪魔なテクノロジーを採用する可能性を明確に除外できません。ただし、作業グループは、ロイヤリティやその他の負担が必要なテクノロジーを再配布して使用するのを容易にする妨げとなるテクノロジーの回避を試みます。
When considering license terms for technologies with IPR claims against them, some members of the working group have expressed their preference for license terms that:
それらに対するIPR主張のあるテクノロジーのライセンス条項を検討するとき、ワーキンググループの一部のメンバーは、次のようなライセンス条項への選好を表明しました。
o are available to all, worldwide, whether or not they are working group participants
o ワーキンググループの参加者であるかどうかにかかわらず、世界中のすべての人が利用できます。
o extend to all essential claims owned or controlled by the licensor
o ライセンサーが所有または管理するすべての重要なクレームに拡大
o do not require payment of royalties, fees, or other consideration
o 使用料、手数料、その他の対価の支払いを必要としない
o do not require licensees to adhere to restrictions on usage (though, licenses that apply only to implementation of the standard are acceptable)
o ライセンシーが使用制限を遵守する必要はありません（ただし、標準の実装にのみ適用されるライセンスは許容されます）
o do not otherwise impede the ability of the codec to be implemented in open-source software projects
o それ以外の場合は、コーデックがオープンソースソフトウェアプロジェクトに実装される機能を妨げない
The following guidelines will help to maximize the odds that the codec will be unencumbered:
次のガイドラインは、コーデックが妨げられない確率を最大化するのに役立ちます。
1. In accordance with BCP 79 [IPR], contributed codecs should preferably use technologies with no known IPR claims or technologies with an offer of royalty-free licensing.
1. BCP 79 [IPR]に従って、寄付されたコーデックは、既知のIPRクレームのないテクノロジ、またはロイヤリティフリーのライセンスを提供するテクノロジを使用する必要があります。
2. As described in BCP 79, the working group should use technologies that are perceived by the participants to be safer with regard to IPR issues.
2. BCP 79で説明されているように、ワーキンググループは、IPRの問題に関してより安全であると参加者が認識しているテクノロジーを使用する必要があります。
3. Contributors must disclose IPR as specified in BCP 79.
3. 貢献者は、BCP 79で指定されているIPRを開示する必要があります。
4. In cases where no royalty-free license can be obtained regarding a patent, BCP 79 suggests that the working group consider alternative algorithms or methods, even if they result in lower quality, higher complexity, or otherwise less desirable characteristics.
4. 特許に関して著作権使用料なしのライセンスを取得できない場合、BCP 79は、ワーキンググループが代替のアルゴリズムまたは方法を検討することを提案します。これにより、品質や複雑性が低下したり、その他の望ましくない特性が発生したりする場合でも同様です。
5. In accordance with BCP 78 [TRUST], the source code for the reference implementation must be made available under a BSD-style license (or whatever license is defined as acceptable by the IETF Trust when the Internet-Draft defining the reference implementation is published).
5. BCP 78 [TRUST]に従って、リファレンス実装のソースコードは、BSDスタイルのライセンス（または、リファレンス実装を定義するインターネットドラフトが公開されたときにIETFトラストによって受諾可能と定義されているすべてのライセンス）の下で利用可能にする必要があります。 。
Many IPR licenses specify that a license is granted only for technologies that are adopted by the IETF as a standard. While reasonable, this has the unintended side effect of discouraging implementation prior to RFC status. Real-world implementation is beneficial for evaluation of the codec. As such, entities making IPR license statements are encouraged to use wording that permits early implementation and deployment.
多くのIPRライセンスは、IETFが標準として採用しているテクノロジーに対してのみライセンスが付与されることを指定しています。これは妥当ですが、RFCステータスの前に実装を阻止するという意図しない副作用があります。実際の実装は、コーデックの評価に役立ちます。したがって、IPRライセンスステートメントを作成するエンティティは、早期の実装と展開を可能にする表現を使用することが推奨されます。
IETF participants should be aware that, given the way patents work in most countries, the resulting codec can never be guaranteed to be free of patent claims because some patents may not be known to the contributors, some patent applications may not be disclosed at the time the codec is developed, and only courts of law can determine the validity and breadth of patent claims. However, these observations are no different within the Internet Standards Process than they are for standardization of codecs within other Standards Development Organizations (SDOs) (or development of codecs outside the context of any SDO); furthermore, they are no different for codecs than for other technologies worked on within the IETF. In all these cases, the best approach is to minimize the risk of unknowingly incurring encumbrance on existing patents. Despite these precautions, participants need to understand that, practically speaking, it is nearly impossible to _guarantee_ that implementers will not incur encumbrance on existing patents.
IETFの参加者は、ほとんどの国で特許が機能する方法を考えると、一部の特許はコントリビューターに知られていない可能性があり、一部の特許出願は現時点では開示されていない可能性があるため、結果として得られるコーデックが特許クレームがないことは決して保証できません。コーデックが開発され、法廷のみが特許クレームの有効性と幅を決定できます。ただし、これらの観察は、他の標準開発組織（SDO）内のコーデックの標準化（またはSDOのコンテキスト外のコーデックの開発）の場合と同じで、インターネット標準プロセス内でも同じです。さらに、コーデックについても、IETF内で機能する他のテクノロジーと同じです。これらすべての場合において、最善のアプローチは、既存の特許に無意識に負担をかけるリスクを最小限に抑えることです。これらの予防策にもかかわらず、参加者は、実際には、実装者が既存の特許に負担をかけないことを_保証することはほぼ不可能であることを理解する必要があります。
It is understood that other SDOs are also involved in the codec development and standardization, including but not necessarily limited to:
他のSDOもコーデックの開発と標準化に関与していると理解されています。
o The Telecommunication Standardization Sector (ITU-T) of the International Telecommunication Union (ITU), in particular Study Group 16
o 国際電気通信連合（ITU）の電気通信標準化部門（ITU-T）、特に研究グループ16
o The Moving Picture Experts Group (MPEG) of the International Organization for Standardization and International Electrotechnical Commission (ISO/IEC)
o 国際標準化機構および国際電気標準会議（ISO / IEC）の動画専門家グループ（MPEG）
o The European Telecommunications Standards Institute (ETSI)
o 欧州電気通信標準協会（ETSI）
o The 3rd Generation Partnership Project (3GPP)
o 第3世代パートナーシッププロジェクト（3GPP）
o The 3rd Generation Partnership Project 2 (3GPP2)
o 第3世代パートナーシッププロジェクト2（3GPP2）
It is important to ensure that such work does not constitute uncoordinated protocol development of the kind described in [UNCOORD] in the following principle:
このような作業が、[UNCOORD]で説明されている次のような非協調的なプロトコル開発を構成しないようにすることが重要です。
[T]he IAB considers it an essential principle of the protocol development process that only one SDO maintains design authority for a given protocol, with that SDO having ultimate authority over the allocation of protocol parameter code-points and over defining the intended semantics, interpretation, and actions associated with those code-points.
[T] IABは、1つのSDOだけが特定のプロトコルの設計権限を維持することがプロトコル開発プロセスの重要な原則であると考えており、そのSDOはプロトコルパラメータコードポイントの割り当てと意図されたセマンティクスの定義、解釈に対する最終的な権限を持っています。 、およびそれらのコードポイントに関連付けられたアクション。
The work envisioned by this guidelines document is not uncoordinated in the sense described in the foregoing quote, since the intention of this process is that two possible outcomes might occur:
このプロセスの目的は2つの可能な結果が発生する可能性があるためです。このガイドラインドキュメントで想定されている作業は、前述の引用で説明されている意味で調整されていません。
1. The IETF adopts an existing audio codec and specifies that it is the "anointed" IETF Internet codec. In such a case, codec ownership lies entirely with the SDO that produced the codec, and not with the IETF.
1. IETFは既存のオーディオコーデックを採用し、それが「油そそがれた」IETFインターネットコーデックであることを指定します。このような場合、コーデックの所有権は完全にコーデックを生成したSDOにあり、IETFにはありません。
2. The IETF produces a new codec. Even if this codec uses concepts, algorithms, or even source code from a codec produced by another SDO, the IETF codec is a specification unto itself and under complete control of the IETF. Any changes or enhancements made by the original SDO to the codecs whose components the IETF used are not applicable to the IETF codec. Such changes would be incorporated as a consequence of a revision or extension of the IETF RFC. In no case should the new codec reuse a name or code point from another SDO.
2. IETFは新しいコーデックを生成します。このコーデックが概念、アルゴリズム、または別のSDOによって生成されたコーデックからのソースコードを使用する場合でも、IETFコーデックはそれ自体に対する仕様であり、IETFの完全な制御下にあります。 IETFが使用したコンポーネントがIETFコーデックに適用されないコーデックに対して、元のSDOによって行われた変更または拡張。このような変更は、IETF RFCの改訂または拡張の結果として組み込まれます。新しいコーデックが別のSDOの名前またはコードポイントを再利用してはなりません。
Although there is already sufficient codec expertise available among IETF participants to complete the envisioned work, additional contributions are welcome within the framework of the Internet Standards Process in the following ways:
IETF参加者の間で想定される作業を完了するのに十分なコーデックの専門知識がすでに利用可能ですが、インターネット標準プロセスのフレームワーク内で次のように追加の貢献を歓迎します。
o Individuals who are technical contributors to codec work within other SDOs can participate directly in codec work within the IETF.
o 他のSDO内のコーデック作業への技術的な貢献者である個人は、IETF内のコーデック作業に直接参加できます。
o Other SDOs can contribute their expertise (e.g., codec characterization and evaluation techniques) and thus facilitate the testing of a codec produced by the IETF.
o 他のSDOは専門知識（コーデックの特性評価や評価手法など）に貢献できるため、IETFによって生成されたコーデックのテストを容易にすることができます。
o Any SDO can provide input to IETF work through liaison statements.
o どのSDOも、連絡ステートメントを通じてIETF作業への入力を提供できます。
However, it is important to note that final responsibility for the development process and the resulting codec will remain with the IETF as governed by BCP 9 [PROCESS].
ただし、BCP 9 [PROCESS]で規定されているように、開発プロセスとその結果のコーデックに対する最終的な責任はIETFに残ることに注意することが重要です。
Finally, there is precedent for the contribution of codecs developed elsewhere to the ITU-T (e.g., Adaptive Multi-Rate Wideband (AMR-WB) was standardized originally within 3GPP). This is a model to explore as the IETF coordinates further with the ITU-T in accordance with the collaboration guidelines defined in [COLLAB].
最後に、他の場所で開発されたコーデックのITU-Tへの貢献の先例があります（たとえば、適応マルチレートワイドバンド（AMR-WB）は、もともと3GPP内で標準化されていました）。これは、IETFが[COLLAB]で定義されたコラボレーションガイドラインに従ってITU-Tとさらに調整するときに探索するモデルです。
The procedural guidelines for codec development do not have security considerations. However, the resulting codec needs to take appropriate security considerations into account, as outlined in [SECGUIDE] and in the security considerations of [CODEC-REQ]. More specifically, the resulting codec must avoid being subject to denial of service [DOS] and buffer overflows, and should take into consideration the impact of variable bitrate (VBR) [SRTP-VBR].
コーデック開発の手順ガイドラインには、セキュリティに関する考慮事項はありません。ただし、[SECGUIDE]および[CODEC-REQ]のセキュリティに関する考慮事項で概説されているように、結果のコーデックは適切なセキュリティに関する考慮事項を考慮する必要があります。より具体的には、結果のコーデックは、サービス拒否[DOS]およびバッファオーバーフローの影響を受けないようにする必要があり、可変ビットレート（VBR）[SRTP-VBR]の影響を考慮する必要があります。
We would like to thank all the other people who contributed directly or indirectly to this document, including Jason Fischl, Gregory Maxwell, Alan Duric, Jonathan Christensen, Julian Spittka, Michael Knappe, Timothy B. Terriberry, Christian Hoene, Stephan Wenger, and Henry Sinnreich. We would also like to thank Cullen Jennings and Gregory Lebovitz for their advice. Special thanks to Peter Saint-Andre, who originally co-authored this document.
Jason Fischl、Gregory Maxwell、Alan Duric、Jonathan Christensen、Julian Spittka、Michael Knappe、Timothy B. Terriberry、Christian Hoene、Stephan Wenger、Henryなど、このドキュメントに直接または間接的に貢献してくれた他のすべての人々に感謝します。シンライヒ。また、カレン・ジェニングスとグレゴリー・レボヴィッツのアドバイスにも感謝します。このドキュメントを最初に共同執筆したPeter Saint-Andreに特に感謝します。
[IPR] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[IPR] Bradner、S。、「IETFテクノロジーにおける知的財産権」、BCP 79、RFC 3979、2005年3月。
[PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[プロセス] Bradner、S。、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
[TRUST] Bradner, S. and J. Contreras, "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, November 2008.
[TRUST] Bradner、S。およびJ. Contreras、「IETFトラストに提供する権利の貢献者」、BCP 78、RFC 5378、2008年11月。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[BASE64] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[CODEC-REQ] Valin, J. and K. Vos, "Requirements for an Internet Audio Codec", RFC 6366, August 2011.
[CODEC-REQ] Valin、J。およびK. Vos、「インターネットオーディオコーデックの要件」、RFC 6366、2011年8月。
[COLLAB] Fishman, G. and S. Bradner, "Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines", RFC 3356, August 2002.
[COLLAB] Fishman、G.およびS. Bradner、「インターネット技術特別調査委員会および国際電気通信連合-電気通信標準化セクターコラボレーションガイドライン」、RFC 3356、2002年8月。
[DOS] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[DOS] Handley、M.、Rescorla、E。、およびIAB、「インターネットサービス拒否の考慮事項」、RFC 4732、2006年12月。
[ITU-R-BS.1387-1] "Method for objective measurements of perceived audio quality", ITU-R Recommendation BS.1387-1, November 2001.
[ITU-R-BS.1387-1]「知覚される音質の客観的測定方法」、ITU-R勧告BS.1387-1、2001年11月。
[ITU-R-BS.1534] "Method for the subjective assessment of intermediate quality levels of coding systems", ITU-R Recommendation BS.1534, January 2003.
[ITU-R-BS.1534]「コーディングシステムの中間品質レベルの主観的評価方法」、ITU-R勧告BS.1534、2003年1月。
[ITU-T-P.862] "Perceptual evaluation of speech quality (PESQ): An objective method for end-to-end speech quality assessment of narrow-band telephone networks and speech codecs", ITU-T Recommendation P.862, October 2007.
[ITU-TP.862]「音声品質の知覚評価（PESQ）：狭帯域電話ネットワークと音声コーデックのエンドツーエンドの音声品質評価の客観的方法」、ITU-T勧告P.862、2007年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RTP] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[SECGUIDE] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[SECGUIDE] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを作成するためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[SRTP-VBR] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012.
[SRTP-VBR]パーキンス、C.、JM。 Valin、「Secure RTPでの可変ビットレートオーディオの使用に関するガイドライン」、RFC 6562、2012年3月。
[UNCOORD] Bryant, S., Morrow, M., and IAB, "Uncoordinated Protocol Development Considered Harmful", RFC 5704, November 2009.
[UNCOORD]ブライアント、S。、モロー、M。、およびIAB、「有害な非協調的プロトコル開発」、RFC 5704、2009年11月。
Authors' Addresses
著者のアドレス
Jean-Marc Valin Mozilla 650 Castro Street Mountain View, CA 94041 USA
Jean-Marc Valin Mozilla 650 Castro Street Mountain View、CA 94041 USA
EMail: jmvalin@jmvalin.ca
Slava Borilin SPIRIT DSP
Slava Borilin SPIRIT DSP
EMail: borilin@spiritdsp.com
Koen Vos
こえん ゔぉｓ
EMail: koen.vos@skype.net
Christopher Montgomery Xiph.Org Foundation
クリストファーモンゴメリーXiph.Org Foundation
EMail: xiphmont@xiph.org
Raymond (Juin-Hwey) Chen Broadcom Corporation
らｙもんｄ （じゅいんーふぇｙ） ちぇん Ｂろあｄこｍ こｒぽらちおん
EMail: rchen@broadcom.com