[要約] 要約：RFC 7867は、ビデオアプリケーションの損失隠蔽メトリクスのためのRTCP拡張レポート（XR）ブロックに関するものです。 目的：このRFCの目的は、ビデオアプリケーションでの損失隠蔽の効果を評価するためのメトリクスを提供することです。
Internet Engineering Task Force (IETF) R. Huang
Request for Comments: 7867 Huawei
Category: Standards Track July 2016
ISSN: 2070-1721
RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications
ビデオアプリケーションの損失隠蔽メトリックのRTP制御プロトコル（RTCP）拡張レポート（XR）ブロック
Abstract
概要
This document defines a new RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of loss concealment metrics for video applications of RTP.
このドキュメントでは、RTPのビデオアプリケーションの損失隠蔽メトリックのレポートを可能にする新しいRTP制御プロトコル（RTCP）拡張レポート（XR）ブロックを定義します。
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 http://www.rfc-editor.org/info/rfc7867.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7867で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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
1.1. RTCP and RTCP XR Reports ...................................3
1.2. Performance Metrics Framework ..............................3
1.3. Applicability ..............................................3
2. Terminology .....................................................3
3. Video Loss Concealment Methods ..................................3
4. Video Loss Concealment Report Block .............................4
5. SDP Signaling ...................................................8
5.1. SDP rtcp-xr-attrib Attribute Extension .....................8
5.2. Offer/Answer Usage .........................................9
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
7.1. New RTCP XR Block Type Value ...............................9
7.2. New RTCP XR SDP Parameter ..................................9
7.3. Contact Information for Registrations .....................10
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................11
Appendix A. Metrics Represented Using the Template from RFC 6390 ..12
Acknowledgements ..................................................16
Authors' Addresses ................................................16
Multimedia applications often suffer from packet losses in IP networks. In order to get a reasonable degree of quality when there is packet loss, it is necessary to have loss concealment mechanisms at the decoder. Video loss concealment is a range of techniques to mask the effects of packet loss in video communications.
マルチメディアアプリケーションは、IPネットワークでのパケット損失に悩まされることがよくあります。パケット損失が発生したときに妥当な品質を得るためには、デコーダーに損失隠蔽メカニズムが必要です。ビデオ損失の隠蔽は、ビデオ通信におけるパケット損失の影響を隠すためのさまざまな手法です。
In some applications, reporting the information of receivers applying video loss concealment could give monitors or senders useful information on the Quality of Experience (QoE) of the application. One example is no-reference video quality evaluation. Video probes located upstream from the video endpoint or terminal may not see loss occurring between the probe and the endpoint, and also may not be fully aware of the specific loss concealment methods being dynamically applied by the video endpoint. Evaluating error concealment is important in this circumstance to estimate the subjective impact of impairments.
一部のアプリケーションでは、ビデオ損失の隠蔽を適用する受信者の情報を報告することで、モニターまたは送信者にアプリケーションのQuality of Experience（QoE）に関する有用な情報を提供できます。 1つの例は、参照なしのビデオ品質評価です。ビデオエンドポイントまたは端末の上流にあるビデオプローブは、プローブとエンドポイント間で発生する損失を認識できず、ビデオエンドポイントによって動的に適用される特定の損失隠蔽方法を完全に認識していない場合があります。この状況では、障害の主観的な影響を推定するために、エラーの隠蔽を評価することが重要です。
This document defines one new block type for video loss concealment to augment those defined in [RFC3611] and [RFC7294] for use in a range of RTP video applications. The metrics defined in this document belong to the class of transport-related terminal metrics defined in [RFC6792].
このドキュメントは、一連のRTPビデオアプリケーションで使用するために、[RFC3611]および[RFC7294]で定義されたものを補強するために、ビデオ損失隠蔽の1つの新しいブロックタイプを定義します。このドキュメントで定義されているメトリックは、[RFC6792]で定義されているトランスポート関連の端末メトリックのクラスに属しています。
The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] defines an extensible structure for reporting using an RTCP Extended Report (XR). This document defines a new Extended Report block that is used as defined in [RFC3550] and [RFC3611].
レポートのためのRTCPの使用は、[RFC3550]で定義されています。 [RFC3611]は、RTCP拡張レポート（XR）を使用してレポートするための拡張可能な構造を定義しています。このドキュメントは、[RFC3550]と[RFC3611]で定義されているように使用される新しいExtended Reportブロックを定義します。
The Performance Metrics Framework [RFC6390] provides guidance on the definition and specification of performance metrics. The RTP monitoring framework [RFC6792] provides guidelines for the reporting block format using RTCP XR. The XR block type described in this document is in accordance with the guidelines in [RFC6390] and [RFC6792].
パフォーマンスメトリックフレームワーク[RFC6390]は、パフォーマンスメトリックの定義と仕様に関するガイダンスを提供します。 RTP監視フレームワーク[RFC6792]は、RTCP XRを使用したレポートブロック形式のガイドラインを提供します。このドキュメントで説明されているXRブロックタイプは、[RFC6390]と[RFC6792]のガイドラインに準拠しています。
These metrics are applicable to video applications the video component of audio/video applications using RTP and applying packet loss concealment mechanisms that are incorporated into the receiving endpoint to mitigate the impact of network impairments on QoE. For example, in an IPTV system, set-top boxes could use this RTCP XR block to report loss and loss concealment metrics to an IPTV management system to enable the service provider to monitor the quality of the IPTV service being delivered to end users.
これらのメトリックは、RTPを使用し、QoEへのネットワーク障害の影響を緩和するために受信エンドポイントに組み込まれているパケット損失隠蔽メカニズムを適用するビデオアプリケーション、オーディオ/ビデオアプリケーションのビデオコンポーネントに適用できます。たとえば、IPTVシステムでは、セットトップボックスでこのRTCP XRブロックを使用して、IPTV管理システムに損失および損失隠蔽メトリックを報告し、サービスプロバイダーがエンドユーザーに配信されるIPTVサービスの品質を監視できるようにすることができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Video loss concealment mechanisms can be classified into 4 types as follows:
ビデオ損失の隠蔽メカニズムは、次の4つのタイプに分類できます。
a) Frame freeze
a) フレームフリーズ
The impaired video frame is not displayed; instead, the previously displayed frame is frozen for the duration of the loss event.
障害のあるビデオフレームは表示されません。代わりに、以前に表示されたフレームは、損失イベントの期間中フリーズされます。
b) Interframe extrapolation
b) フレーム間外挿
If an area of the video frame is damaged by loss, the same area from the previous frame(s) can be used to estimate what the missing pixels would have been. This can work well in a scene with no motion but can be very noticeable if there is significant movement from one frame to another. Simple decoders can simply reuse the pixels that were in the missing area, while more complex decoders can try to use several frames to do a more complex extrapolation. Another example of a sophisticated form of interframe repair is to estimate the motion of the damaged region based on the motion of surrounding regions, and use that to select what part of the previous frame to use for repair. Some important frames, such as Instantaneous Decoding Refresh (IDR) frames, may not depend on any other frames and may be involved in a scene change. Using the interframe extrapolation method to conceal the loss of these frames may not obtain a satisfactory result.
ビデオフレームの領域が損失によって損傷している場合、前のフレームと同じ領域を使用して、欠落しているピクセルが何であったかを推定できます。これは動きのないシーンでうまく機能しますが、あるフレームから別のフレームへの大きな動きがある場合は非常に目立つ場合があります。単純なデコーダーでは欠落領域にあったピクセルを再利用できますが、より複雑なデコーダーでは複数のフレームを使用してより複雑な外挿を実行できます。洗練された形式のフレーム間修復のもう1つの例は、周囲の領域の動きに基づいて損傷した領域の動きを推定し、それを使って前のフレームのどの部分を修復に使用するかを選択することです。 Instantaneous Decoding Refresh（IDR）フレームなどのいくつかの重要なフレームは、他のフレームに依存しておらず、シーンの変更に関与している場合があります。フレーム間外挿法を使用してこれらのフレームの損失を隠すと、満足のいく結果が得られない場合があります。
c) Interpolation
c) 補間
A decoder uses the undamaged pixels in the video frame to estimate what the missing block of pixels should have.
デコーダーは、ビデオフレーム内の損傷していないピクセルを使用して、欠落しているピクセルのブロックがどうあるべきかを推定します。
d) Error-resilient encoding
d) エラーに強いエンコーディング
The sender encodes the message in a redundant way so that the receiver can correct errors using the redundant information. There are usually two kinds of error-resilient encoding: One is that the redundant data useful for error resiliency performed at the decoder can be embedded into the compressed image/video bitstream. The other is encoding at the bitstream level, e.g., Forward Error Correction (FEC).
送信者は冗長な方法でメッセージをエンコードするため、受信者は冗長な情報を使用してエラーを修正できます。通常、エラー耐性のあるエンコーディングには2種類あります。1つは、デコーダーで実行されるエラー耐性に役立つ冗長データを、圧縮された画像/ビデオビットストリームに埋め込むことができることです。もう1つは、ビットストリームレベルでのエンコードです。たとえば、Forward Error Correction（FEC）です。
Usually, methods b, c, and d are deployed together to provide comprehensive loss concealment in complex decoders, while method a is relatively independent and may be applied in some simple decoders. Moreover, the frame-freeze method repairs video based on frames, while the other methods repair video based on fine-grained elements, such as macroblocks or bitstreams; this will cause the measurement metrics of frame-freeze and the other methods to be slightly different. Thus, In this document, we differentiate between frame-freeze and the other 3 loss concealment mechanisms.
通常、メソッドb、c、およびdは一緒に展開されて複雑なデコーダーに包括的な損失隠蔽を提供しますが、メソッドaは比較的独立しており、いくつかの単純なデコーダーに適用できます。さらに、フレームフリーズ方法はフレームに基づいてビデオを修復しますが、他の方法はマクロブロックやビットストリームなどの細かい要素に基づいてビデオを修復します。これにより、フレームフリーズと他の方法の測定基準がわずかに異なります。したがって、このドキュメントでは、フレームフリーズと他の3つの損失隠蔽メカニズムを区別します。
This block reports the video loss concealment metrics to complement the audio metrics defined in [RFC7294]. The report block MUST be sent in conjunction with the information from the Measurement Information Block [RFC6776]. Instances of this metric block refer by synchronization source (SSRC) to the separate auxiliary Measurement Information Block [RFC6776]. The Video Loss Concealment Report Block relies on the measurement period in the Measurement Information Block indicating the span of the report. If the measurement period is not received in the same compound RTCP packet as this metric block, this metric block MUST be discarded at the receiving side. The metrics in this report block are based on measurements that are typically made at the time that a video frame is decoded and rendered for playout.
このブロックは、[RFC7294]で定義されているオーディオメトリックを補完するために、ビデオロス隠蔽メトリックを報告します。レポートブロックは、測定情報ブロック[RFC6776]からの情報と一緒に送信する必要があります。このメトリックブロックのインスタンスは、同期ソース（SSRC）によって個別の補助測定情報ブロック[RFC6776]を参照します。ビデオ損失隠蔽レポートブロックは、レポートのスパンを示すMeasurement Information Blockの測定期間に依存します。このメトリックブロックと同じ複合RTCPパケットで測定期間が受信されない場合、このメトリックブロックは受信側で破棄する必要があります。このレポートブロックのメトリックは、ビデオフレームがデコードされて再生用にレンダリングされるときに通常行われる測定に基づいています。
The Video Loss Concealment Report Block has the following format:
ビデオ損失隠蔽レポートブロックの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=34 | I | V | RSV | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Impaired Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Concealed Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mean Frame Freeze Duration (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIFP | MCFP | FFSC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format for the Video Loss Concealment Report Block
図1：ビデオ損失隠蔽レポートブロックの形式
Block Type (BT): 8 bits
ブロックタイプ（BT）：8ビット
A Video Loss Concealment Report Block is identified by the constant 34.
ビデオ損失隠蔽レポートブロックは、定数34で識別されます。
Interval Metric Flag (I): 2 bits
間隔メトリックフラグ（I）：2ビット
This field indicates whether the reported metrics are interval, cumulative, or sampled metrics [RFC6792]:
このフィールドは、報告されたメトリックが間隔、累積、またはサンプリングされたメトリックであるかどうかを示します[RFC6792]：
I=10: Interval Duration - the reported value applies to the most recent measurement interval duration between successive metrics reports.
I = 10：インターバル期間-報告された値は、連続するメトリックレポート間の最新の測定インターバル期間に適用されます。
I=11: Cumulative Duration - the reported value applies to the accumulation period characteristic of cumulative measurements.
I = 11：累積期間-報告された値は、累積測定に特有の累積期間に適用されます。
I=01: Sampled Value - this value MUST NOT be used for this block type.
I = 01：サンプル値-この値は、このブロックタイプには使用しないでください。
I=00: Reserved.
I = 00：予約済み。
Video Loss Concealment Method Type (V): 2 bits
ビデオ損失隠蔽方法タイプ（V）：2ビット
This field is used to identify the video loss concealment method type used at the receiver. The value is defined as follows:
このフィールドは、受信側で使用されるビデオ損失隠蔽方法のタイプを識別するために使用されます。値は次のように定義されます。
V=10: Frame-freeze
V=11: Other Loss Concealment Method
V=01 and V=00: Reserved
If frame-freeze and another loss concealment method are used together for the media stream, two report blocks (one with V=10 for frame freeze and one with V=11 for the other loss concealment method) SHOULD be compounded together to report complete concealment information.
フレームフリーズと別の損失隠蔽方法がメディアストリームに一緒に使用される場合、2つのレポートブロック（1つはフレーム凍結のV = 10で、もう1つは他の損失隠蔽方法のV = 11です）を組み合わせて完全な隠蔽を報告する必要があります。情報。
RSV: 4 bits
RSV：4ビット
These bits are reserved for future use. They MUST be set to zero by senders and ignored by receivers (see Section 4.2 of [RFC6709]).
これらのビットは将来の使用のために予約されています。送信者はゼロに設定し、受信者は無視する必要があります（[RFC6709]のセクション4.2を参照）。
Block Length: 16 bits
ブロック長：16ビット
This field is in accordance with the definition in [RFC3611]. In this report block, it MUST be set to 5 when V=10 and set to 4 when V=11. The block MUST be discarded if the block length is set to a different value.
このフィールドは、[RFC3611]の定義に準拠しています。このレポートブロックでは、V = 10の場合は5に設定し、V = 11の場合は4に設定する必要があります。ブロック長が別の値に設定されている場合は、ブロックを破棄する必要があります。
SSRC of Source: 32 bits
ソースのSSRC：32ビット
As defined in Section 4.1 of [RFC3611].
[RFC3611]のセクション4.1で定義されています。
Impaired Duration: 32 bits
障害のある期間：32ビット
The total duration, expressed in units of RTP timestamp from the sending side of the reporting block, of video impaired by transmission loss before applying any loss concealment methods.
レポートブロックの送信側からのRTPタイムスタンプの単位で表される、損失の隠蔽方法を適用する前の伝送損失によって損なわれたビデオの合計時間。
Two values are reserved: A value of 0xFFFFFFFE indicates out of range (that is, a measured value exceeding 0xFFFFFFFD), and a value of 0xFFFFFFFF indicates that the measurement is unavailable.
2つの値が予約されています。値0xFFFFFFFEは範囲外（つまり、測定値が0xFFFFFFFDを超える）を示し、値0xFFFFFFFFは測定が利用できないことを示します。
Concealed Duration: 32 bits
隠蔽期間：32ビット
The total duration, expressed in units of RTP timestamp from the sending side of the reporting block, of concealed damaged video pictures on which the loss concealment method corresponding to the Video Loss Concealment Method Type is applied.
レポートブロックの送信側からのRTPタイムスタンプの単位で表される、ビデオ損失隠蔽方法タイプに対応する損失隠蔽方法が適用される隠された損傷ビデオ画像の合計持続時間。
Two values are reserved: A value of 0xFFFFFFFE indicates out of range (that is, a measured value exceeding 0xFFFFFFFD), and a value of 0xFFFFFFFF indicates that the measurement is unavailable.
2つの値が予約されています。値0xFFFFFFFEは範囲外（つまり、測定値が0xFFFFFFFDを超える）を示し、値0xFFFFFFFFは測定が利用できないことを示します。
Mean Frame-Freeze Duration: 32 bits
平均フレームフリーズ期間：32ビット
Mean Frame-Freeze Duration is the mean duration, expressed in units of RTP timestamp from the sending side of the reporting block, of the frame-freeze events. The value of Mean Frame-Freeze Duration is calculated by summing the total duration of all frame freeze events and dividing by the number of events. This metric is optional. It only exists when Video Loss Concealment Method Type=10.
平均フレームフリーズ期間は、レポートブロックの送信側からのRTPタイムスタンプの単位で表される、フレームフリーズイベントの平均期間です。平均フレームフリーズ期間の値は、すべてのフレームフリーズイベントの合計期間を合計し、イベント数で割ることによって計算されます。このメトリックはオプションです。 Video Loss Concealment Method Type = 10の場合にのみ存在します。
Mean Impaired Frame Proportion (MIFP): 8 bits
平均障害フレーム比率（MIFP）：8ビット
Mean Impaired Frame Proportion is the mean proportion of each video frame impaired by loss before applying any loss concealment method during the interval, expressed as a fixed-point number with the binary point at the left edge of the field. It is calculated by summing the impaired proportion of each video frame and dividing by the number of frames during this period. The impaired proportion of each video frame is obtained by dividing the number of missing macroblocks from this video frame by the total macroblock number of the video frame, which is equivalent to multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part.
平均障害フレーム比率は、インターバル中に損失隠蔽方法を適用する前に損失によって障害が発生した各ビデオフレームの平均比率であり、フィールドの左端に2進小数点がある固定小数点数として表されます。これは、各ビデオフレームの障害のある割合を合計し、この期間中のフレーム数で割ることによって計算されます。各ビデオフレームの障害のある割合は、このビデオフレームから失われたマクロブロックの数をビデオフレームのマクロブロックの総数で割ることで得られます。これは、除算の結果に256を掛けることに相当し、最大値を255に制限します（オーバーフローを避けるために）、整数部分を取ります。
If a video frame is totally lost, a value of 0xFF SHOULD be used for the frame when calculating the MIFP.
ビデオフレームが完全に失われた場合、MIFPを計算するときにフレームに0xFFの値を使用する必要があります（SHOULD）。
Mean Concealed Frame Proportion (MCFP): 8 bits
平均隠蔽フレーム比率（MCFP）：8ビット
Mean Concealed Frame Proportion is the mean proportion of each video frame to which loss concealment (depicted as "V" in the definition of "Video Loss Concealment Method Type") was applied during the interval, expressed as a fixed-point number with the binary point at the left edge of the field. It is calculated by summing the concealed proportion of each video frame and dividing by the number of frames during this period. The concealed proportion of each video frame is obtained by dividing the number of concealed macroblocks from this video frame by the total macroblock number of the video frame, which is equivalent to multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part.
平均隠蔽フレーム比率は、間隔中に損失隠蔽（「ビデオ損失隠蔽方法タイプ」の定義で「V」として示されている）が適用された各ビデオフレームの平均比率であり、バイナリの固定小数点数として表されますフィールドの左端をポイントします。これは、各ビデオフレームの隠された比率を合計し、この期間中のフレーム数で割ることによって計算されます。各ビデオフレームの隠された割合は、このビデオフレームから隠されたマクロブロックの数をビデオフレームの合計マクロブロック数で割ることで得られます。これは、除算の結果に256を掛けることに相当し、最大値を255に制限します（オーバーフローを避けるために）、整数部分を取ります。
When calculating the MCFP, a value of 0xFF SHOULD be used for a lost frame that is totally concealed, and a value of 0 SHOULD be used for the frame if there are no concealed macroblocks in it. For Video Loss Concealment Method Type=10, each frame covered in the period of frame freeze is considered to be totally concealed; this means a value of 0xFF MUST be assigned.
MCFPを計算するとき、完全に隠されている失われたフレームには値0xFFを使用する必要があり（SHOULD）、フレームに隠されたマクロブロックがない場合は値0を使用する必要があります。 Video Loss Concealment Method Type = 10の場合、フレームのフリーズ期間中にカバーされた各フレームは完全に隠されていると見なされます。つまり、0xFFの値を割り当てる必要があります。
Fraction of Frames Subject to Concealment (FFSC): 8 bits
隠蔽対象のフレームの割合（FFSC）：8ビット
Fraction of Frames Subject to Concealment is calculated by dividing the number of frames to which loss concealment (using Video Loss Concealment Method Type) was applied by the total number of frames and expressing this value as a fixed-point number with the binary point at the left edge of the field. It is equivalent to multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part.
隠蔽対象のフレームの割合は、損失隠蔽（ビデオ損失隠蔽方法タイプを使用）が適用されたフレームの数をフレームの総数で除算し、この値を固定小数点数として2進小数点のある2進小数点で表すことにより計算されますフィールドの左端。これは、除算の結果を256で乗算し、最大値を255に制限して（オーバーフローを回避するため）、整数部分を取得するのと同じです。
A value of 0 indicates that there were no concealed frames, and a value of 0xFF indicates that the frames in the entire measurement interval are all concealed.
値0は、隠されたフレームがないことを示し、値0xFFは、測定間隔全体のフレームがすべて隠されていることを示します。
Reserved: 8 bits
予約済み：8ビット
These bits are reserved for future use. They MUST be set to zero by senders and ignored by receivers (see Section 4.2 of [RFC6709]).
これらのビットは将来の使用のために予約されています。送信者はゼロに設定し、受信者は無視する必要があります（[RFC6709]のセクション4.2を参照）。
[RFC3611] defines the use of the Session Description Protocol (SDP) for signaling the use of RTCP XR blocks.
[RFC3611]は、RTCP XRブロックの使用を通知するためのセッション記述プロトコル（SDP）の使用を定義しています。
This session augments the SDP attribute "rtcp-xr" defined in Section 5.1 of [RFC3611] by providing an additional value of "xr-format" to signal the use of the report block defined in this document. The ABNF [RFC5234] syntax is as follows.
このセッションは、[RFC3611]のセクション5.1で定義されているSDP属性「rtcp-xr」を拡張して、このドキュメントで定義されているレポートブロックの使用を通知する「xr-format」の追加の値を提供します。 ABNF [RFC5234]の構文は次のとおりです。
xr-format =/ xr-vlc-block
xr-format = / xr-vlc-block
xr-vlc-block = "vlc"
When SDP is used in an offer/answer context, the SDP Offer/Answer usage defined in Section 5.2 of [RFC3611] for the unilateral "rtcp-xr" attribute parameters applies. For detailed usage of Offer/Answer for unilateral parameters, refer to Section 5.2 of [RFC3611].
SDPがオファー/アンサーコンテキストで使用される場合、片側の「rtcp-xr」属性パラメーターに対して[RFC3611]のセクション5.2で定義されたSDPオファー/アンサーの使用法が適用されます。片側パラメーターのオファー/アンサーの詳細な使用法については、[RFC3611]のセクション5.2を参照してください。
It is believed that this RTCP XR block introduces no new security considerations beyond those described in [RFC3611]. This block does not provide per-packet statistics, so the risk to confidentiality documented in paragraph 3 of Section 7 of [RFC3611] does not apply.
このRTCP XRブロックは、[RFC3611]で説明されているものを超える新しいセキュリティ上の考慮事項を導入しないと考えられています。このブロックはパケットごとの統計を提供しないため、[RFC3611]のセクション7の段落3に記載されている機密性へのリスクは適用されません。
An attacker is likely to put incorrect information in the Video Loss Concealment reports; this will affect the estimation of the performance of video loss concealment mechanisms and the QoE of users. Implementers SHOULD consider the guidance in [RFC7202] for using appropriate security mechanisms, i.e., where security is a concern, the implementation SHOULD apply encryption and authentication to the report block. For example, this can be achieved by using the AVPF profile together with the Secure RTP profile as defined in [RFC3711]; an appropriate combination of the two profiles (an "SAVPF") is specified in [RFC5124]. However, other mechanisms also exist (documented in [RFC7201]) and might be more suitable.
攻撃者は、Video Loss Concealmentレポートに誤った情報を入れる可能性があります。これは、ビデオ損失隠蔽メカニズムのパフォーマンスの推定とユーザーのQoEに影響します。実装者は、適切なセキュリティメカニズムを使用するための[RFC7202]のガイダンスを考慮する必要があります。つまり、セキュリティが懸念される場合、実装は暗号化と認証をレポートブロックに適用する必要があります（SHOULD）。たとえば、これはAVPFプロファイルを[RFC3711]で定義されているSecure RTPプロファイルと一緒に使用することで実現できます。 2つのプロファイルの適切な組み合わせ（「SAVPF」）は、[RFC5124]で指定されています。ただし、他のメカニズムも存在し（[RFC7201]に文書化されています）、より適切な場合があります。
New block types for RTCP XR are subject to IANA registration. For general guidelines on IANA considerations for RTCP XR, please refer to [RFC3611].
RTCP XRの新しいブロックタイプは、IANA登録の対象です。 RTCP XRに関するIANAの考慮事項に関する一般的なガイドラインについては、[RFC3611]を参照してください。
This document assigns the block type value 34 to Video Loss Concealment Metric Report Block in the IANA "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry".
このドキュメントでは、IANA「RTP Control Protocol Extended Reports（RTCP XR）Block Type Registry」のVideo Loss Concealment Metric Report Blockにブロックタイプ値34を割り当てています。
This document also registers a new parameter "video-loss-concealment" in the "RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry".
このドキュメントでは、「RTP制御プロトコル拡張レポート（RTCP XR）セッション記述プロトコル（SDP）パラメータレジストリ」に新しいパラメータ「video-loss-concealment」も登録しています。
The contact information for the registration is:
登録の連絡先情報は次のとおりです。
RAI Area Directors <rai-ads@ietf.org>
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <http://www.rfc-editor.org/info/rfc3611>.
[RFC3611]フリードマン、T。、編、カセレス、R、編、およびA.クラーク、編、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、DOI 10.17487 / RFC3611、2003年11月、 <http://www.rfc-editor.org/info/rfc3611>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「The Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、March 2004、<http://www.rfc-editor.org/info/rfc3711>。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124] Ott、J。およびE. Carrara、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<http ：//www.rfc-editor.org/info/rfc5124>。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http：//www.rfc-editor .org / info / rfc5234>。
[RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block", RFC 6776, DOI 10.17487/RFC6776, October 2012, <http://www.rfc-editor.org/info/rfc6776>.
[RFC6776]クラークA.およびQ.ウー、「ソース記述（SDES）アイテムとRTCP拡張レポート（XR）ブロックを使用した測定IDおよび情報レポート」、RFC 6776、DOI 10.17487 / RFC6776、2012年10月、<http ：//www.rfc-editor.org/info/rfc6776>。
[RFC7294] Clark, A., Zorn, G., Bi, C., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications", RFC 7294, DOI 10.17487/RFC7294, July 2014, <http://www.rfc-editor.org/info/rfc7294>.
[RFC7294] Clark、A.、Zorn、G.、Bi、C。、およびQ. Wu、「RTP Control Protocol（RTCP）Extended Report（XR）Blocks for Concealment Metrics Reporting on Audio Applications」、RFC 7294、DOI 10.17487 / RFC7294、2014年7月、<http://www.rfc-editor.org/info/rfc7294>。
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <http://www.rfc-editor.org/info/rfc6390>.
[RFC6390]クラークA.およびB.クレイズ、「新しいパフォーマンスメトリック開発を検討するためのガイドライン」、BCP 170、RFC 6390、DOI 10.17487 / RFC6390、2011年10月、<http://www.rfc-editor.org/info / rfc6390>。
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>.
[RFC6709] Carpenter、B.、Aboba、B.、Ed。、およびS. Cheshire、「プロトコル拡張の設計上の考慮事項」、RFC 6709、DOI 10.17487 / RFC6709、2012年9月、<http：//www.rfc-editor .org / info / rfc6709>。
[RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use of the RTP Monitoring Framework", RFC 6792, DOI 10.17487/RFC6792, November 2012, <http://www.rfc-editor.org/info/rfc6792>.
[RFC6792] Wu、Q.、Ed。、Hunt、G。、およびP. Arden、「RTPモニタリングフレームワークの使用に関するガイドライン」、RFC 6792、DOI 10.17487 / RFC6792、2012年11月、<http：// www。 rfc-editor.org/info/rfc6792>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<http://www.rfc-editor.org/info/rfc7201>。
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <http://www.rfc-editor.org/info/rfc7202>.
[RFC7202] Perkins、C。およびM. Westerlund、「RTPフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」、RFC 7202、DOI 10.17487 / RFC7202、2014年4月、<http：//www.rfc- editor.org/info/rfc7202>。
a. Video Impaired Duration Metric
a. ビデオ障害持続時間メトリック
* Metric Name: Video Impaired Duration Metric
* メトリック名：Video Impaired Durationメトリック
* Metric Description: The total duration of the video impaired by transmission loss before applying any loss concealment methods.
* 指標の説明：損失の隠蔽方法を適用する前の、伝送損失によって損なわれたビデオの合計時間。
* Method of Measurement or Calculation: The metric is based on measurements that are typically made at the time that a video frame is decoded and rendered for playout.
* 測定または計算の方法：メトリックは、ビデオフレームがデコードされて再生用にレンダリングされるときに通常行われる測定に基づいています。
* Units of Measurement: This metric is expressed in units of RTP timestamp.
* 測定単位：このメトリックは、RTPタイムスタンプの単位で表されます。
* Measurement Point(s) with Potential Measurement Domain: It is measured at the receiving end of the RTP stream.
* 潜在的な測定ドメインのある測定ポイント：RTPストリームの受信側で測定されます。
* Measurement Timing: See paragraph 1 of Section 4.
* 測定タイミング：セクション4のパラグラフ1を参照。
* Use and Applications: The metric is applicable to video applications of RTP and the video component of audio/video applications in which packet loss concealment mechanisms are applied to the receiving endpoint to mitigate the impact of network impairments on QoE.
* 用途とアプリケーション：このメトリックは、RTPのビデオアプリケーションとオーディオ/ビデオアプリケーションのビデオコンポーネントに適用され、QoEへのネットワーク障害の影響を緩和するために、パケット損失隠蔽メカニズムが受信エンドポイントに適用されます。
b. Video Concealed Duration Metric
b. ビデオ秘匿期間メトリック
* Metric Name: Video Concealed Duration Metric
* メトリック名：ビデオ秘匿期間メトリック
* Metric Description: The total duration of concealed damaged video pictures on which loss concealment method corresponding to Video Loss Concealment Method Type is applied.
* メトリックの説明：ビデオ損失隠蔽方法タイプに対応する損失隠蔽方法が適用される、隠された損傷したビデオ画像の合計時間。
* Method of Measurement or Calculation: The metric is based on measurements that are typically made at the time that a video frame is decoded and rendered for playout.
* 測定または計算の方法：メトリックは、ビデオフレームがデコードされて再生用にレンダリングされるときに通常行われる測定に基づいています。
* Units of Measurement: This metric is expressed in units of RTP timestamp.
* 測定単位：このメトリックは、RTPタイムスタンプの単位で表されます。
* Measurement Point(s) with Potential Measurement Domain: It is measured at the receiving end of the RTP stream.
* 潜在的な測定ドメインのある測定ポイント：RTPストリームの受信側で測定されます。
* Measurement Timing: See paragraph 1 of Section 4.
* 測定タイミング：セクション4のパラグラフ1を参照。
* Use and Applications: These metrics are applicable to video applications of RTP and the video component of audio/video applications in which packet loss concealment mechanisms are incorporated into the receiving endpoint to mitigate the impact of network impairments on QoE.
* 使用とアプリケーション：これらのメトリックは、RTPのビデオアプリケーションおよびオーディオ/ビデオアプリケーションのビデオコンポーネントに適用できます。パケット損失隠蔽メカニズムが受信エンドポイントに組み込まれ、QoEに対するネットワーク障害の影響を軽減します。
c. Mean Video Frame-Freeze Duration Metric
c. 平均ビデオフレームフリーズ期間メトリック
* Metric Name: Mean Video Frame-Freeze Duration Metric
* メトリック名：Mean Video Frame-Freeze Duration Metric
* Metric Description: The mean duration of the frame-freeze events.
* 指標の説明：フレームフリーズイベントの平均継続時間。
* Method of Measurement or Calculation: The metric is based on measurements that are typically made at the time that a video frame is decoded and rendered for playout. The metric is calculated by summing the total duration of all frame-freeze events and dividing by the number of events.
* 測定または計算の方法：メトリックは、ビデオフレームがデコードされて再生用にレンダリングされるときに通常行われる測定に基づいています。メトリックは、すべてのフレームフリーズイベントの合計時間を合計し、イベントの数で割ることによって計算されます。
* Units of Measurement: This metric is expressed in units of RTP timestamp.
* 測定単位：このメトリックは、RTPタイムスタンプの単位で表されます。
* Measurement Point(s) with Potential Measurement Domain: It is measured at the receiving end of the RTP stream.
* 潜在的な測定ドメインのある測定ポイント：RTPストリームの受信側で測定されます。
* Measurement Timing: See paragraph 1 of Section 4.
* 測定タイミング：セクション4のパラグラフ1を参照。
* Use and Applications: These metrics are applicable to video applications of RTP and the video component of audio/video applications in which packet loss concealment mechanisms are incorporated into the receiving endpoint to mitigate the impact of network impairments on QoE.
* 使用とアプリケーション：これらのメトリックは、RTPのビデオアプリケーションおよびオーディオ/ビデオアプリケーションのビデオコンポーネントに適用できます。パケット損失隠蔽メカニズムが受信エンドポイントに組み込まれ、QoEに対するネットワーク障害の影響を軽減します。
d. Mean Impaired Video Frame Proportion Metric
d. 平均障害のあるビデオフレーム比率メトリック
* Metric Name: Mean Impaired Video Frame Proportion Metric
* メトリック名：平均障害のあるビデオフレーム比率メトリック
* Metric Description: Mean proportion of each video frame impaired by loss before applying any loss concealment method during the interval.
* 指標の説明：間隔中に損失隠蔽方法を適用する前の、損失によって損なわれた各ビデオフレームの平均比率。
* Method of Measurement or Calculation: The metric is based on measurements that are typically made at the time that a video frame is decoded and rendered for playout. It is calculated by summing the impaired proportion of each video frame and dividing by the number of frames during this period. The impaired proportion of each video frame is obtained by dividing the number of missing macroblocks from this video frame by the total macroblock number of the video frame, which is equivalent to multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part.
*測定または計算の方法：メトリックは、ビデオフレームがデコードされて再生用にレンダリングされるときに通常行われる測定に基づいています。これは、各ビデオフレームの障害のある割合を合計し、この期間中のフレーム数で割ることによって計算されます。各ビデオフレームの障害のある割合は、このビデオフレームから失われたマクロブロックの数をビデオフレームのマクロブロックの総数で割ることで得られます。これは、除算の結果に256を掛けることに相当し、最大値を255に制限します（オーバーフローを避けるために）、整数部分を取ります。
* Units of Measurement: This metric is expressed as a fixed-point number with the binary point at the left edge of the field.
* 測定単位：このメトリックは、フィールドの左端に2進小数点がある固定小数点数として表されます。
* Measurement Point(s) with Potential Measurement Domain: It is measured at the receiving end of the RTP stream.
* 潜在的な測定ドメインのある測定ポイント：RTPストリームの受信側で測定されます。
* Measurement Timing: See paragraph 1 of Section 4.
* 測定タイミング：セクション4のパラグラフ1を参照。
* Use and Applications: These metrics are applicable to video applications of RTP and the video component of audio/video applications in which packet loss concealment mechanisms are incorporated into the receiving endpoint to mitigate the impact of network impairments on QoE.
* 使用とアプリケーション：これらのメトリックは、RTPのビデオアプリケーションおよびオーディオ/ビデオアプリケーションのビデオコンポーネントに適用できます。パケット損失隠蔽メカニズムが受信エンドポイントに組み込まれ、QoEに対するネットワーク障害の影響を軽減します。
e. Mean Concealed Video Frame Proportion Metric
e. 平均隠蔽ビデオフレーム比率メトリック
* Metric Name: Mean Concealed Video Frame Proportion Metric
* メトリック名：平均隠蔽ビデオフレーム比率メトリック
* Metric Description: Mean proportion of each video frame to which loss concealment (using Video Loss Concealment Method Type) was applied during the interval.
* メトリックの説明：間隔中に損失隠蔽（ビデオ損失隠蔽方法タイプを使用）が適用された各ビデオフレームの平均比率。
* Method of Measurement or Calculation: The metric is based on measurements that are typically made at the time that a video frame is decoded and rendered for playout. It is calculated by summing the concealed proportion of each video frame and dividing by the number of frames during this period. The concealed proportion of each video frame is obtained by dividing the number of concealed macroblocks from this video frame by the total macroblock number of the video frame, which is equivalent to multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part.
* 測定または計算の方法：メトリックは、ビデオフレームがデコードされて再生用にレンダリングされるときに通常行われる測定に基づいています。これは、各ビデオフレームの隠された比率を合計し、この期間中のフレーム数で割ることによって計算されます。各ビデオフレームの隠された割合は、このビデオフレームから隠されたマクロブロックの数をビデオフレームの合計マクロブロック数で割ることで得られます。これは、除算の結果に256を掛けることに相当し、最大値を255に制限します（オーバーフローを避けるために）、整数部分を取ります。
* Units of Measurement: This metric is expressed as a fixed-point number with the binary point at the left edge of the field.
* 測定単位：このメトリックは、フィールドの左端に2進小数点がある固定小数点数として表されます。
* Measurement Point(s) with Potential Measurement Domain: It is measured at the receiving end of the RTP stream.
* 潜在的な測定ドメインのある測定ポイント：RTPストリームの受信側で測定されます。
* Measurement Timing: See paragraph 1 of Section 4.
* 測定タイミング：セクション4のパラグラフ1を参照。
* Use and Applications: These metrics are applicable to video applications of RTP and the video component of audio/video applications in which packet loss concealment mechanisms are incorporated into the receiving endpoint to mitigate the impact of network impairments on QoE.
* 使用とアプリケーション：これらのメトリックは、RTPのビデオアプリケーションおよびオーディオ/ビデオアプリケーションのビデオコンポーネントに適用できます。パケット損失隠蔽メカニズムが受信エンドポイントに組み込まれ、QoEに対するネットワーク障害の影響を軽減します。
f. Fraction of Video Frames Subject to Concealment Metric
f. 隠蔽メトリックの対象となるビデオフレームの割合
* Metric Name: Fraction of Video Frames Subject to Concealment Metric
* メトリック名：隠蔽メトリックの対象となるビデオフレームの割合
* Metric Description: Proportion of concealed video frames to which loss concealment (using the Video Loss Concealment Method Type) was applied compared to the total number of frames during the interval.
* メトリックの説明：間隔中のフレームの総数と比較して、（ビデオ損失隠蔽方法タイプを使用して）損失隠蔽が適用された隠蔽されたビデオフレームの比率。
* Method of Measurement or Calculation: The metric is based on measurements that are typically made at the time that a video frame is decoded and rendered for playout. This metric is calculated by dividing the number of frames to which loss concealment (using Video Loss Concealment Method Type) was applied by the total number of frames. It is equivalent to multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part.
* 測定または計算の方法：メトリックは、ビデオフレームがデコードされて再生用にレンダリングされるときに通常行われる測定に基づいています。このメトリックは、（ビデオ損失隠蔽方法タイプを使用して）損失隠蔽が適用されたフレームの数をフレームの総数で割ることによって計算されます。これは、除算の結果を256で乗算し、最大値を255に制限して（オーバーフローを回避するため）、整数部分を取得するのと同じです。
* Units of Measurement: This metric is expressed as a fixed-point number with the binary point at the left edge of the field.
* 測定単位：このメトリックは、フィールドの左端に2進小数点がある固定小数点数として表されます。
* Measurement Point(s) with Potential Measurement Domain: It is measured at the receiving end of the RTP stream.
* 潜在的な測定ドメインのある測定ポイント：RTPストリームの受信側で測定されます。
* Measurement Timing: See paragraph 1 of Section 4.
* 測定タイミング：セクション4のパラグラフ1を参照。
* Use and Applications: These metrics are applicable to video applications of RTP and the video component of audio/video applications in which packet loss concealment mechanisms are incorporated into the receiving endpoint to mitigate the impact of network impairments on QoE.
* 使用とアプリケーション：これらのメトリックは、RTPのビデオアプリケーションおよびオーディオ/ビデオアプリケーションのビデオコンポーネントに適用できます。パケット損失隠蔽メカニズムが受信エンドポイントに組み込まれ、QoEに対するネットワーク障害の影響を軽減します。
Acknowledgements
謝辞
The author would like to thank Colin Perkins and Roni Even for their valuable comments.
著者は、Colin PerkinsとRoni Evenの貴重なコメントに感謝します。
Authors' Addresses
著者のアドレス
Rachel Huang Huawei 101 Software Avenue, Yuhua District Nanjing 210012 China
Rachel Huang hu Aは101ソフトウェアアベニュー、Y Uは地区NaNjing 210012中国を描画
Email: rachel.huang@huawei.com