[要約] RFC 8593は、RTP輻輳制御評価のためのビデオトラフィックモデルに関するものです。このRFCの目的は、RTP輻輳制御アルゴリズムの評価に使用されるビデオトラフィックのモデルを提供することです。
Internet Engineering Task Force (IETF) X. Zhu
Request for Comments: 8593 S. Mena
Category: Informational Cisco Systems
ISSN: 2070-1721 Z. Sarker
Ericsson AB
May 2019
Video Traffic Models for RTP Congestion Control Evaluations
RTP輻輳制御評価のためのビデオトラフィックモデル
Abstract
概要
This document describes two reference video traffic models for evaluating RTP congestion control algorithms. The first model statistically characterizes the behavior of a live video encoder in response to changing requests on the target video rate. The second model is trace-driven and emulates the output of actual encoded video frame sizes from a high-resolution test sequence. Both models are designed to strike a balance between simplicity, repeatability, and authenticity in modeling the interactions between a live video traffic source and the congestion control module. Finally, the document describes how both approaches can be combined into a hybrid model.
このドキュメントでは、RTP輻輳制御アルゴリズムを評価するための2つの参照ビデオトラフィックモデルについて説明します。最初のモデルは、ターゲットビデオレートに対する要求の変更に応じて、ライブビデオエンコーダーの動作を統計的に特徴付けます。 2番目のモデルはトレース駆動型で、高解像度テストシーケンスからの実際のエンコードされたビデオフレームサイズの出力をエミュレートします。どちらのモデルも、ライブビデオトラフィックソースと輻輳制御モジュールの間の相互作用のモデリングにおいて、単純性、再現性、信頼性のバランスをとるように設計されています。最後に、このドキュメントでは、両方のアプローチをハイブリッドモデルに組み合わせる方法について説明しています。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc8593.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8593で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Desired Behavior of a Synthetic Video Traffic Model . . . . . 4
4. Interactions between Synthetic Video Traffic Source and
Other Components at the Sender . . . . . . . . . . . . . . . 5
5. A Statistical Reference Model . . . . . . . . . . . . . . . . 7
5.1. Time-Damped Response to Target-Rate Update . . . . . . . 9
5.2. Temporary Burst and Oscillation during the Transient
Period . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Output-Rate Fluctuation at Steady State . . . . . . . . . 9
5.4. Rate Range Limit Imposed by Video Content . . . . . . . . 10
6. A Trace-Driven Model . . . . . . . . . . . . . . . . . . . . 10
6.1. Choosing the Video Sequence and Generating the Traces . . 11
6.2. Using the Traces in the Synthetic Codec . . . . . . . . . 13
6.2.1. Main Algorithm . . . . . . . . . . . . . . . . . . . 13
6.2.2. Notes to the Main Algorithm . . . . . . . . . . . . . 14
6.3. Varying Frame Rate and Resolution . . . . . . . . . . . . 15
7. Combining the Two Models . . . . . . . . . . . . . . . . . . 16
8. Reference Implementation . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
When evaluating candidate congestion control algorithms designed for real-time interactive media, it is important to account for the characteristics of traffic patterns generated from a live video encoder. Unlike synthetic traffic sources that can conform perfectly to the rate-changing requests from the congestion control module, a live video encoder can be sluggish in reacting to such changes. The output rate of a live video encoder also typically deviates from the target rate due to uncertainties in the encoder rate-control process. Consequently, end-to-end delay and loss performance of a real-time media flow can be further impacted by rate variations introduced by the live encoder.
リアルタイムのインタラクティブメディア用に設計された候補の輻輳制御アルゴリズムを評価する場合、ライブビデオエンコーダーから生成されるトラフィックパターンの特性を考慮することが重要です。輻輳制御モジュールからのレート変更要求に完全に適合することができる合成トラフィックソースとは異なり、ライブビデオエンコーダーは、そのような変化への反応が遅い場合があります。ライブビデオエンコーダーの出力レートも、エンコーダーレート制御プロセスの不確実性のために、通常はターゲットレートから逸脱します。その結果、リアルタイムのメディアフローのエンドツーエンドの遅延と損失パフォーマンスは、ライブエンコーダーによって導入されたレートの変動によってさらに影響を受ける可能性があります。
On the other hand, evaluation results of a candidate RTP congestion control algorithm should mostly reflect the performance of the congestion control module and somewhat decouple from peculiarities of any specific video codec. It is also desirable that evaluation tests are repeatable and easily duplicated across different candidate algorithms.
一方、候補RTP輻輳制御アルゴリズムの評価結果は、主に輻輳制御モジュールのパフォーマンスを反映し、特定のビデオコーデックの特性からある程度切り離すべきです。また、評価テストは再現可能であり、異なる候補アルゴリズム間で簡単に複製できることが望ましい。
One way to strike a balance between the above considerations is to evaluate congestion control algorithms using a synthetic video traffic source model that captures key characteristics of the behavior of a live video encoder. The synthetic traffic model should also contain tunable parameters so that it can be flexibly adjusted to reflect the wide variations in real-world live video encoder behaviors. To this end, this document presents two reference models. The first is based on statistical modeling. The second is driven by frame size and interval traces recorded from a real-world encoder. This document also discusses the pros and cons of each approach, as well as how both approaches can be combined into a hybrid model.
上記の考慮事項のバランスをとる1つの方法は、ライブビデオエンコーダーの動作の主要な特性をキャプチャする合成ビデオトラフィックソースモデルを使用して、輻輳制御アルゴリズムを評価することです。合成トラフィックモデルには調整可能なパラメータも含まれている必要があります。これにより、実際のライブビデオエンコーダの動作の幅広い変動を反映するように柔軟に調整できます。この目的のために、このドキュメントでは2つの参照モデルを示します。 1つ目は、統計モデリングに基づいています。 2番目は、現実のエンコーダーから記録されたフレームサイズと間隔のトレースによって駆動されます。このドキュメントでは、各アプローチの長所と短所、および両方のアプローチをハイブリッドモデルに組み合わせる方法についても説明します。
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]で説明されているように解釈されます。
A live video encoder employs encoder rate control to meet a target rate by varying its encoding parameters, such as quantization step size, frame rate, and picture resolution, based on its estimate of the video content (e.g., motion and scene complexity). In practice, however, several factors prevent the output video rate from perfectly conforming to the input target rate.
ライブビデオエンコーダーは、エンコーダーレート制御を使用して、ビデオコンテンツ（モーションやシーンの複雑さなど）の推定に基づいて、量子化ステップサイズ、フレームレート、画像解像度などのエンコードパラメーターを変更することにより、ターゲットレートを満たします。ただし、実際には、いくつかの要因により、出力ビデオレートが入力ターゲットレートに完全に適合しません。
Due to uncertainties in the captured video scene, the output rate typically deviates from the specified target. In the presence of a significant change in target rate, the encoder's output frame sizes sometimes fluctuate for a short, transient period of time before the output rate converges to the new target. Finally, while most of the frames in a live session are encoded in predictive mode (i.e., P-frames in [H264]), the encoder can occasionally generate a large intra-coded frame (i.e., I-frame as defined in [H264]) or a frame partially containing intra-coded blocks in an attempt to recover from losses, to re-sync with the receiver, or during the transient period of responding to target rate or spatial resolution changes.
キャプチャされたビデオシーンの不確実性のため、出力レートは通常、指定されたターゲットから逸脱します。ターゲットレートに大きな変化がある場合、エンコーダの出力フレームサイズは、出力レートが新しいターゲットに収束する前に、短い一時的な期間変動することがあります。最後に、ライブセッションのほとんどのフレームは予測モードでエンコードされますが（つまり、[H264]のPフレーム）、エンコーダーは時々大きなイントラコードフレーム（つまり、[H264 ]）または、損失からの回復、受信機との再同期、またはターゲットレートまたは空間解像度の変化への応答の一時的な期間中に、イントラコード化されたブロックを部分的に含むフレーム。
Hence, a synthetic video source should have the following capabilities:
したがって、合成ビデオソースには次の機能が必要です。
o To change bitrate. This includes the ability to change frame rate and/or spatial resolution or to skip frames upon request.
o ビットレートを変更する。これには、フレームレートや空間解像度を変更したり、リクエストに応じてフレームをスキップしたりする機能が含まれます。
o To fluctuate around the target bitrate specified by the congestion control module.
o 輻輳制御モジュールで指定された目標ビットレートを中心に変動する。
o To show a delay in convergence to the target bitrate.
o 目標ビットレートへの収束の遅延を示すため。
o To generate intra-coded or repair frames on demand.
o オンデマンドでフレーム内コード化または修復フレームを生成します。
While there exist many different approaches in developing a synthetic video traffic model, it is desirable that the outcome follows a few common characteristics, as outlined below.
合成ビデオトラフィックモデルの開発にはさまざまなアプローチが存在しますが、以下に概説するように、結果はいくつかの一般的な特性に従うことが望ましいです。
o Low computational complexity: The model should be computationally lightweight, otherwise, it defeats the whole purpose of serving as a substitute for a live video encoder.
o 計算量が少ない：モデルは計算量が少ない必要があります。それ以外の場合は、ライブビデオエンコーダーの代用として機能するという全体的な目的に反します。
o Temporal pattern similarity: The individual traffic trace instances generated by the model should mimic the temporal pattern of those from a real video encoder.
o 時間的パターンの類似性：モデルによって生成された個々のトラフィックトレースインスタンスは、実際のビデオエンコーダーからの時間的パターンを模倣する必要があります。
o Statistical resemblance: The synthetic traffic source should match the outcome of the real video encoder in terms of statistical characteristics, such as the mean, variance, peak, and autocorrelation coefficients of the bitrate. It is also important that the statistical resemblance should hold across different time scales ranging from tens of milliseconds to sub-seconds.
o 統計的類似性：合成トラフィックソースは、ビットレートの平均、分散、ピーク、自己相関係数などの統計的特性に関して、実際のビデオエンコーダーの結果と一致する必要があります。統計的類似性が、数十ミリ秒からサブ秒までのさまざまな時間スケールにわたって保持されることも重要です。
o A wide range of coverage: The model should be easily configurable to cover a wide range of codec behaviors (e.g., with either fast or slow reaction time in live encoder rate control) and video content variations (e.g., ranging from high to low motion).
o 広範囲のカバレッジ：モデルは、幅広いコーデック動作（たとえば、ライブエンコーダーレート制御での反応時間が速いまたは遅い）とビデオコンテンツの変動（たとえば、高いモーションから低いモーションまで）をカバーするように簡単に構成できる必要があります。 。
These distinct behavior features can be characterized via simple statistical modeling or a trace-driven approach. Sections 5 and 6 provide an example of each approach, respectively. Section 7 discusses how both models can be combined together.
これらの異なる動作機能は、単純な統計モデリングまたはトレースドリブンアプローチによって特徴付けることができます。セクション5と6では、それぞれのアプローチの例を示します。セクション7では、両方のモデルを組み合わせる方法について説明します。
4. Interactions between Synthetic Video Traffic Source and Other Components at the Sender
4. 送信者での合成ビデオトラフィックソースと他のコンポーネント間の相互作用
Figure 1 depicts the interactions of the synthetic video traffic source with other components at the sender, such as the application, the congestion control module, the media packet transport module, etc. Both reference models, as described later in Sections 5 and 6, follow the same set of interactions.
図1は、アプリケーション、輻輳制御モジュール、メディアパケットトランスポートモジュールなど、合成ビデオトラフィックソースと送信側の他のコンポーネントとの相互作用を示しています。セクション5と6で後述する両方の参照モデルは、次のとおりです。同じ相互作用のセット。
The synthetic video source dynamically generates a sequence of dummy video frames with varying size and interval. These dummy frames are processed by other modules in order to transmit the video stream over the network. During the lifetime of a video transmission session, the synthetic video source will typically be required to adapt its encoding bitrate and sometimes the spatial resolution and frame rate.
合成ビデオソースは、サイズと間隔が変化する一連のダミービデオフレームを動的に生成します。これらのダミーフレームは、ネットワーク経由でビデオストリームを送信するために、他のモジュールによって処理されます。ビデオ送信セッションの存続期間中、合成ビデオソースは通常、そのエンコードビットレートと、場合によっては空間解像度とフレームレートを調整する必要があります。
In this model, the synthetic video source module has a group of incoming and outgoing interface calls that allow for interaction with other modules. The following are some of the possible incoming interface calls, marked as (a) in Figure 1, that the synthetic video traffic source may accept. The list is not exhaustive and can be complemented by other interface calls if necessary.
このモデルでは、合成ビデオソースモジュールには、他のモジュールとの相互作用を可能にする着信および発信インターフェイスコールのグループがあります。以下は、図1で（a）とマークされている可能性のある着信インターフェース呼び出しの一部であり、合成ビデオトラフィックソースが受け入れる場合があります。このリストは完全なものではなく、必要に応じて他のインターフェース呼び出しで補足できます。
o Target bitrate R_v: Target bitrate request measured in bits per second (bps). Typically, the congestion control module calculates the target bitrate and updates it dynamically over time. Depending on the congestion control algorithm in use, the update requests can either be periodic (e.g., once per second), or on-demand (e.g., only when a drastic bandwidth change over the network is observed).
o ターゲットビットレートR_v：ビット/秒（bps）で測定されたターゲットビットレート要求。通常、輻輳制御モジュールは目標ビットレートを計算し、時間の経過とともに動的に更新します。使用中の輻輳制御アルゴリズムに応じて、更新要求は定期的（たとえば、1秒に1回）またはオンデマンド（たとえば、ネットワーク全体で大幅な帯域幅の変化が観察された場合のみ）のいずれかになります。
o Target frame rate FPS: The instantaneous frame rate measured in frames per second at a given time. This depends on the native camera-capture frame rate as well as the target/preferred frame rate configured by the application or user.
o ターゲットフレームレートFPS：所定の時間に1秒あたりのフレーム数で測定される瞬間フレームレート。これは、ネイティブのカメラキャプチャフレームレートと、アプリケーションまたはユーザーによって構成されたターゲット/優先フレームレートによって異なります。
o Target frame resolution XY: The 2-dimensional vector indicating the preferred frame resolution in pixels. Several factors govern the resolution requested to the synthetic video source over time. Examples of such factors include the capturing resolution of the native camera and the display size of the destination screen. The target frame resolution also depends on the current target bitrate R_v, since it does not make sense to pair very low spatial resolutions with very high bitrates, and vice-versa.
o ターゲットフレーム解像度XY：推奨されるフレーム解像度をピクセル単位で示す2次元ベクトル。時間の経過とともに合成ビデオソースに要求される解像度は、いくつかの要因によって決まります。このような要因の例には、ネイティブカメラのキャプチャ解像度と宛先画面の表示サイズが含まれます。ターゲットフレームの解像度は、現在のターゲットビットレートR_vにも依存します。これは、非常に低い空間解像度と非常に高いビットレートをペアにすることは意味がなく、その逆も同様です。
o Instant frame skipping: The request to skip the encoding of one or several captured video frames, for instance, when a drastic decrease in available network bandwidth is detected.
o インスタントフレームスキップ：たとえば、利用可能なネットワーク帯域幅の大幅な減少が検出されたときに、1つまたは複数のキャプチャされたビデオフレームのエンコードをスキップする要求。
o On-demand generation of intra (I) frame: The request to encode another I-frame to avoid further error propagation at the receiver when severe packet losses are observed. This request typically comes from the error control module. It can be initiated either by the sender or by the receiver via Full Intra Request (FIR) messages as defined in [RFC5104].
o イントラ（I）フレームのオンデマンド生成：深刻なパケット損失が観察されたときに、レシーバーでのさらなるエラー伝搬を回避するために別のIフレームをエンコードする要求。この要求は通常、エラー制御モジュールから送信されます。 [RFC5104]で定義されているように、送信者または受信者のいずれかがFull Intra Request（FIR）メッセージを介して開始できます。
An example of an outgoing interface call, marked as (b) in Figure 1, is the rate range [R_min, R_max]. Here, R_min and R_max are meant to capture the dynamic rate range the actual live video encoder is capable of generating given the input video content. This typically depends on the video content complexity and/or display type (e.g., higher R_max for video content with higher motion complexity or for displays of higher resolution). Therefore, these values will not change with R_v but may change over time if the content is changing.
図1で（b）とマークされている発信インターフェイスコールの例は、レート範囲[R_min、R_max]です。ここで、R_minおよびR_maxは、実際のライブビデオエンコーダーが入力ビデオコンテンツを指定して生成できるダイナミックレート範囲をキャプチャするためのものです。これは通常、ビデオコンテンツの複雑さや表示の種類に依存します（たとえば、モーションの複雑度が高いビデオコンテンツや解像度の高いディスプレイの場合は、R_maxが高くなります）。したがって、これらの値はR_vで変化しませんが、コンテンツが変化している場合は時間とともに変化する可能性があります。
+-------------+
| | dummy encoded
| Synthetic | video frames
| Video | -------------->
| Source |
| |
+--------+----+
/|\ |
| |
-------------------+ +-------------------->
interface from interface to
other modules (a) other modules (b)
Figure 1: Interaction between Synthetic Video Encoder and Other Modules at the Sender
図1：送信側での合成ビデオエンコーダーと他のモジュール間の相互作用
This section describes one simple statistical model of the live video traffic source. Figure 2 summarizes the list of tunable parameters in this statistical model. A more comprehensive survey of popular methods for modeling the behavior of video traffic sources can be found in [Tanwir2013].
このセクションでは、ライブビデオトラフィックソースの1つの単純な統計モデルについて説明します。図2は、この統計モデルの調整可能なパラメーターの一覧をまとめたものです。ビデオトラフィックソースの動作をモデル化する一般的な方法のより包括的な調査は、[Tanwir2013]にあります。
+===========+====================================+================+
| Notation | Parameter Name | Example Value |
+===========+====================================+================+
| R_v | Target bitrate request | 1 Mbps |
+-----------+------------------------------------+----------------+
| FPS | Target frame rate | 30 Hz |
+-----------+------------------------------------+----------------+
| tau_v | Encoder reaction latency | 0.2 s |
+-----------+------------------------------------+----------------+
| K_d | Burst duration of the transient | 8 frames |
| | period | |
+-----------+------------------------------------+----------------+
| K_B | Burst frame size during the | 13.5 KB* |
| | transient period | |
+-----------+------------------------------------+----------------+
| t0 | Reference frame interval 1/FPS | 33 ms |
+-----------+------------------------------------+----------------+
| B0 | Reference frame size R_v/8/FPS | 4.17 KB |
+-----------+------------------------------------+----------------+
| | Scaling parameter of the zero-mean | |
| | Laplacian distribution describing | |
| SCALE_t | deviations in normalized frame | 0.15 |
| | interval (t-t0)/t0 | |
+-----------+------------------------------------+----------------+
| | Scaling parameter of the zero-mean | |
| | Laplacian distribution describing | |
| SCALE_B | deviations in normalized frame | 0.15 |
| | size (B-B0)/B0 | |
+-----------+------------------------------------+----------------+
| R_min | Minimum rate supported by video | 150 kbps |
| | encoder type or content activity | |
+-----------+------------------------------------+----------------+
| R_max | Maximum rate supported by video | 1.5 Mbps |
| | encoder type or content activity | |
+===========+====================================+================+
* Example value of K_B for a video stream encoded at 720p and 30 frames per second using H.264/AVC encoder
* H.264 / AVCエンコーダーを使用して720pおよび30フレーム/秒でエンコードされたビデオストリームのK_Bの値の例
Figure 2: List of Tunable Parameters in a Statistical Video Traffic Source Model
図2：統計的ビデオトラフィックソースモデルの調整可能なパラメーターのリスト
While the congestion control module can update its target bitrate request R_v at any time, the statistical model dictates that the encoder will only react to such changes tau_v seconds after a previous rate transition. In other words, when the encoder has reacted to a rate-change request at time t, it will simply ignore all subsequent rate-change requests until time t+tau_v.
輻輳制御モジュールはいつでもそのターゲットビットレート要求R_vを更新できますが、統計モデルでは、エンコーダーは、前のレート遷移後のtau_v秒の変化にのみ反応することを指示します。言い換えると、エンコーダが時間tでレート変更要求に反応した場合、時間t + tau_vまで、後続のすべてのレート変更要求を単に無視します。
The output bitrate R_o during the period [t, t+tau_v] is considered to be in a transient state when reacting to abrupt changes in target rate. Based on observations from video encoder output, the encoder reaction to a new target bitrate request can be characterized by high variations in output frame sizes. It is assumed in the model that the overall average output bitrate R_o during this transient period matches the target bitrate R_v. Consequently, the occasional burst of large frames is followed by smaller-than-average encoded frames.
期間[t、t + tau_v]の間の出力ビットレートR_oは、ターゲットレートの急激な変化に反応するとき、過渡状態であると見なされます。ビデオエンコーダー出力からの観察に基づいて、新しいターゲットビットレート要求に対するエンコーダーの反応は、出力フレームサイズの大きな変動によって特徴付けることができます。モデルでは、この一時的な期間中の全体的な平均出力ビットレートR_oが目標ビットレートR_vに一致すると想定されています。その結果、大きなフレームの不定期のバーストの後に、平均よりも小さいエンコードされたフレームが続きます。
This temporary burst is characterized by two parameters:
この一時的なバーストは、次の2つのパラメータによって特徴付けられます。
o burst duration K_d: Number of frames in the burst event, and
o バースト継続時間K_d：バーストイベントのフレーム数
o burst frame size K_B: Size of the initial burst frame, which is typically significantly larger than the average frame size at steady state.
o バーストフレームサイズK_B：初期バーストフレームのサイズ。通常、定常状態の平均フレームサイズよりも大幅に大きくなります。
It can be noted that these burst parameters can also be used to mimic the insertion of a large on-demand I-frame in the presence of severe packet losses. The values of K_d and K_B typically depend on the type of video codec, spatial and temporal resolution of the encoded stream, as well as the activity level in the video content.
これらのバーストパラメータは、深刻なパケット損失がある場合に、大きなオンデマンドIフレームの挿入を模倣するためにも使用できることに注意してください。 K_dおよびK_Bの値は通常、ビデオコーデックのタイプ、エンコードされたストリームの空間的および時間的解像度、およびビデオコンテンツのアクティビティレベルに依存します。
The output bitrate R_o during steady state is modeled as randomly
fluctuating around the target bitrate R_v. The output traffic can be
characterized as the combination of two random processes that denote
the frame interval t and output frame size B over time, which are the
two major sources of variations in the encoder output. For
simplicity, the deviations of t and B from their respective reference
levels are modeled as independent and identically distributed (i.i.d)
random variables following the Laplacian distribution [Papoulis].
More specifically:
o Fluctuations in frame interval: The intervals between adjacent
frames have been observed to fluctuate around the reference
interval of t0 = 1/FPS. Deviations in normalized frame interval
DELTA_t = (t-t0)/t0 can be modeled by a zero-mean Laplacian
distribution with scaling parameter SCALE_t. The value of SCALE_t
dictates the "width" of the Laplacian distribution and therefore
the amount of fluctuation in actual frame intervals (t) with
respect to the reference frame interval t0.
o Fluctuations in frame size: The output-encoded frame sizes also tend to fluctuate around the reference frame size B0=R_v/8/FPS. Likewise, deviations in the normalized frame size DELTA_B = (B-B0)/B0 can be modeled by a zero-mean Laplacian distribution with scaling parameter SCALE_B. The value of SCALE_B dictates the "width" of this second Laplacian distribution and correspondingly the amount of fluctuations in output frame sizes (B) with respect to the reference target B0.
o フレームサイズの変動：出力エンコードフレームサイズも、参照フレームサイズB0 = R_v / 8 / FPSの前後で変動する傾向があります。同様に、正規化されたフレームサイズの偏差DELTA_B =（B-B0）/ B0は、スケーリングパラメーターSCALE_Bのゼロ平均ラプラシアン分布によってモデル化できます。 SCALE_Bの値は、この2番目のラプラシアン分布の「幅」と、それに対応して参照ターゲットB0に対する出力フレームサイズ（B）の変動量を決定します。
Both values of SCALE_t and SCALE_B can be obtained via parameter fitting from empirical data captured for a given video encoder. Example values are listed in Figure 2 based on empirical data presented in [IETF-Interim].
SCALE_tとSCALE_Bの両方の値は、特定のビデオエンコーダーでキャプチャされた経験的データからパラメーターフィッティングを介して取得できます。 [IETF-Interim]で提示された経験的データに基づいて、値の例を図2に示します。
The output bitrate R_o is further clipped within the dynamic range [R_min, R_max], which in reality are dictated by scene and motion complexity of the captured video content. In the proposed statistical model, these parameters are specified by the application.
出力ビットレートR_oは、ダイナミックレンジ[R_min、R_max]内でさらにクリップされます。これは、実際には、キャプチャされたビデオコンテンツのシーンとモーションの複雑さによって決まります。提案された統計モデルでは、これらのパラメーターはアプリケーションによって指定されます。
The second approach for modeling a video traffic source is trace-driven. This can be achieved by running an actual live video encoder on a set of chosen raw video sequences and using the encoder's output traces for constructing a synthetic video source. With this approach, the recorded video traces naturally exhibit temporal fluctuations around a given target bitrate request R_v from the congestion control module.
ビデオトラフィックソースをモデル化するための2番目のアプローチは、トレースドリブンです。これは、選択した生のビデオシーケンスのセットで実際のライブビデオエンコーダーを実行し、エンコーダーの出力トレースを使用して合成ビデオソースを構築することで実現できます。このアプローチでは、記録されたビデオトレースは、輻輳制御モジュールからの指定されたターゲットビットレート要求R_vの周囲で時間的な変動を自然に示します。
The following list summarizes the main steps of this approach:
次のリストは、このアプローチの主な手順をまとめたものです。
1. Choose one or more representative raw video sequences.
1. 1つまたは複数の代表的な生のビデオシーケンスを選択します。
2. Encode the sequence(s) using an actual live video encoder. Repeat the process for a number of bitrates. Keep only the sequence of frame sizes for each bitrate.
2. 実際のライブビデオエンコーダーを使用してシーケンスをエンコードします。いくつかのビットレートに対してこのプロセスを繰り返します。各ビットレートのフレームサイズのシーケンスのみを保持します。
3. Construct a data structure that contains the output of the previous step. The data structure should allow for easy bitrate lookup.
3. 前のステップの出力を含むデータ構造を作成します。データ構造は、ビットレート検索を容易にする必要があります。
4. Upon a target bitrate request R_v from the controller, look up the closest bitrates among those previously stored. Use the frame-size sequences stored for those bitrates to approximate the frame sizes to output.
4. コントローラーからのターゲットビットレート要求R_vに応じて、以前に保存されたビットレートの中で最も近いビットレートを検索します。これらのビットレート用に保存されているフレームサイズシーケンスを使用して、出力するフレームサイズを概算します。
5. The output of the synthetic video traffic source contains "encoded" frames with dummy contents but with realistic sizes.
5. 合成ビデオトラフィックソースの出力には、ダミーのコンテンツがあり、現実的なサイズの「エンコードされた」フレームが含まれています。
Section 6.1 explains the first three steps (1-3), and Section 6.2 elaborates on the remaining two steps (4-5). Finally, Section 6.3 briefly discusses the possibility to extend the trace-driven model for supporting time-varying frame rate and/or time-varying frame resolution.
セクション6.1では、最初の3つのステップ（1〜3）について説明し、セクション6.2では、残りの2つのステップ（4〜5）について詳しく説明します。最後に、セクション6.3では、時変フレームレートや時変フレーム解像度をサポートするためのトレース駆動モデルを拡張する可能性について簡単に説明します。
The first step is a careful choice of a set of video sequences that are representative of the target use cases for the video traffic model. For the example use case of interactive video conferencing, it is recommended to choose a sequence with content that resembles a "talking head", e.g., from a news broadcast or recording of an actual video conferencing call.
最初のステップは、ビデオトラフィックモデルのターゲットユースケースを表す一連のビデオシーケンスを慎重に選択することです。インタラクティブビデオ会議の使用例の場合、ニュースブロードキャストや実際のビデオ会議通話の録音など、「トーキングヘッド」に似たコンテンツのシーケンスを選択することをお勧めします。
The length of the chosen video sequence is a tradeoff. If it is too long, it will be difficult to manage the data structures containing the traces. If it is too short, there will be an obvious periodic pattern in the output frame sizes, leading to biased results when evaluating congestion control performance. It has been empirically determined that a sequence 2 to 4 minutes in length sufficiently avoids the periodic pattern.
選択したビデオシーケンスの長さはトレードオフです。長すぎると、トレースを含むデータ構造の管理が難しくなります。短すぎると、出力フレームサイズに明らかに周期的なパターンが発生し、輻輳制御のパフォーマンスを評価するときに偏った結果になります。 ２〜４分の長さのシーケンスが周期的パターンを十分に回避することが経験的に決定されている。
Given the chosen raw video sequence, denoted "S", one can use a live encoder, e.g., some implementation of [H264] or [H265], to produce a set of encoded sequences. As discussed in Section 3, the output bitrate of the live encoder can be achieved by tuning three input parameters: quantization step size, frame rate, and picture resolution. In order to simplify the choice of these parameters for a given target rate, one can typically assume a fixed frame rate (e.g., 30 fps) and a fixed resolution (e.g., 720p) when configuring the live encoder. See Section 6.3 for a discussion on how to relax these assumptions.
「S」で示される選択された生のビデオシーケンスが与えられると、ライブエンコーダー、たとえば[H264]または[H265]の実装を使用して、エンコードされたシーケンスのセットを生成できます。セクション3で説明したように、ライブエンコーダーの出力ビットレートは、量子化ステップサイズ、フレームレート、画像解像度という3つの入力パラメーターを調整することで実現できます。特定のターゲットレートに対するこれらのパラメーターの選択を簡略化するために、ライブエンコーダーを構成するときに、通常、固定フレームレート（たとえば、30 fps）と固定解像度（たとえば、720p）を想定できます。これらの仮定を緩和する方法については、6.3項を参照してください。
Following these simplifications, the chosen encoder can be configured to start at a constant target bitrate, then vary the quantization step size (internally via the video encoder rate controller) to meet various externally specified target rates. It can be further assumed the first frame is encoded as an I-frame and the rest are P-frames (see, e.g., [H264] for definitions of I-frames and P-frames). For live encoding, the encoder rate-control algorithm typically does not use knowledge of frames in the future when encoding a given frame.
これらの簡素化に従って、選択したエンコーダーは一定のターゲットビットレートで開始し、量子化ステップサイズを（ビデオエンコーダーレートコントローラーを介して内部で）変更して、外部から指定されたさまざまなターゲットレートを満たすように構成できます。さらに、最初のフレームはIフレームとしてエンコードされ、残りはPフレームであると想定できます（IフレームとPフレームの定義については、[H264]を参照してください）。ライブエンコーディングの場合、通常、エンコーダのレート制御アルゴリズムは、特定のフレームをエンコードするときに将来のフレームの知識を使用しません。
Given the minimum and maximum bitrates at which the synthetic codec
is to operate (denoted as "R_min" and "R_max", see Section 4), the
entire range of target bitrates can be divided into n_s steps. This
leads to an encoding bitrate ladder of (n_s + 1) choices equally
spaced apart by the step length l = (R_max - R_min)/n_s. The
following simple algorithm is used to encode the raw video sequence.
r = R_min
while r <= R_max do
Traces[r] = encode_sequence(S, r, e)
r = r + l
The function encode_sequence takes as input parameters, respectively, a raw video sequence (S), a constant target rate (r), and an encoder rate-control algorithm (e); it returns a vector with the sizes of frames in the order they were encoded. The output vector is stored in a map structure called "Traces", whose keys are bitrates and whose values are vectors of frame sizes.
関数encode_sequenceは、それぞれ、生のビデオシーケンス（S）、一定のターゲットレート（r）、およびエンコーダレート制御アルゴリズム（e）を入力パラメーターとして受け取ります。エンコードされた順序でフレームのサイズを持つベクトルを返します。出力ベクトルは「トレース」と呼ばれるマップ構造に格納されます。そのキーはビットレートで、値はフレームサイズのベクトルです。
The choice of a value for the number of bitrate steps n_s is important, since it determines the number of vectors of frame sizes stored in the map Traces. The minimum value one can choose for n_s is 1; the maximum value depends on the amount of memory available for holding the map Traces. A reasonable value for n_s is one that results in steps of length l = 200 kbps. Section 6.2.2 will discuss further the choice of step length l.
ビットトレースステップ数n_sの値の選択は重要です。これは、マップトレースに格納されるフレームサイズのベクトルの数を決定するためです。 n_sに選択できる最小値は1です。最大値は、マップトレースを保持するために使用できるメモリの量によって異なります。 n_sの妥当な値は、長さl = 200 kbpsのステップとなる値です。セクション6.2.2では、ステップ長lの選択についてさらに説明します。
Finally, note that, as mentioned in previous sections, R_min and R_max may be modified after the initial sequences are encoded. Henceforth, for notational clarity, we refer to the bitrate range of the trace file as [Rf_min, Rf_max]. The algorithm described in Section 6.2.1 also covers the cases when the current target bitrate is less than Rf_min or greater than Rf_max.
最後に、前のセクションで述べたように、R_minとR_maxは初期シーケンスがエンコードされた後に変更される可能性があることに注意してください。以降では、表記を明確にするために、トレースファイルのビットレート範囲を[Rf_min、Rf_max]と呼びます。セクション6.2.1で説明するアルゴリズムは、現在のターゲットビットレートがRf_min未満またはRf_maxより大きい場合もカバーしています。
The main idea behind the trace-driven synthetic codec is that it mimics the rate-adaptation behavior of a real live codec upon dynamic updates of the target bitrate request R_v by the congestion control module. It does so by switching to a different frame-size vector stored in the map Traces when needed.
トレース駆動型合成コーデックの主な目的は、輻輳制御モジュールによるターゲットビットレート要求R_vの動的更新時に、実際のライブコーデックのレート適応動作を模倣することです。これは、必要に応じて、マップトレースに格納されている別のフレームサイズのベクトルに切り替えることによって行われます。
The main algorithm for rate adaptation in the synthetic codec maintains two variables: r_current and t_current.
合成コーデックのレート適応のメインアルゴリズムは、r_currentとt_currentの2つの変数を維持します。
o The variable r_current points to one of the keys of map Traces. Upon a change in the value of R_v, typically because the congestion controller detects that the network conditions have changed, r_current is updated based on R_v as follows:
o 変数r_currentは、マップトレースのキーの1つを指します。 R_vの値が変更されると、通常は輻輳コントローラーがネットワーク状態の変更を検出したため、r_currentはR_vに基づいて次のように更新されます。
R_ref = min (Rf_max, max(Rf_min, R_v))
R_ref = min（Rf_max、max（Rf_min、R_v））
r_current = r
such that
(r in keys(Traces) and
r <= R_ref and
(not(exists) r' in keys(Traces) such that r <r'<= R_ref))
o The variable t_current is an index to the frame-size vector stored in Traces[r_current]. It is updated every time a new frame is due. It is assumed that all vectors stored in Traces have the same size, denoted as "size_traces". The following equation governs the update of t_current:
o 変数t_currentは、Traces [r_current]に格納されているフレームサイズベクトルのインデックスです。新しいフレームが期限になるたびに更新されます。 Tracesに格納されているすべてのベクトルは、「size_traces」として示される同じサイズであると想定されています。次の方程式は、t_currentの更新を制御します。
if t_current < SkipFrames then
t_current = t_current + 1
else
t_current = ((t_current + 1 - SkipFrames)
% (size_traces-SkipFrames)) + SkipFrames
where operator "%" denotes modulo, and SkipFrames is a predefined constant that denotes the number of frames to be skipped at the beginning of frame-size vectors after t_current has wrapped around. The point of constant SkipFrames is avoiding the effect of periodically sending a large I-frame followed by several smaller-than-average P-frames. A typical value of SkipFrames is 20, although it could be set to 0 if one is interested in studying the effect of sending I-frames periodically.
ここで、演算子 "％"はモジュロを示し、SkipFramesは事前定義された定数で、t_currentがラップした後、フレームサイズベクトルの先頭でスキップされるフレームの数を示します。一定のSkipFramesのポイントは、定期的に大きなIフレームを送信し、その後に平均よりも小さいいくつかのPフレームを送信する影響を回避することです。 SkipFramesの一般的な値は20ですが、Iフレームを定期的に送信する効果を調べたい場合は0に設定できます。
The initial value of r_current is set to R_min, and the initial value of t_current is set to 0.
r_currentの初期値はR_minに設定され、t_currentの初期値は0に設定されます。
When a new frame is due, its size can be calculated following one of the three cases below:
新しいフレームが期限になると、そのサイズは以下の3つのケースのいずれかに従って計算できます。
a) Rf_min <= R_v < Rf_max: The output frame size is calculated via linear interpolation of the frame sizes appearing in Traces[r_current] and Traces[r_current + l]. The interpolation is done as follows:
a) Rf_min <= R_v <Rf_max：出力フレームサイズは、Traces [r_current]およびTraces [r_current + l]に表示されるフレームサイズの線形補間によって計算されます。補間は次のように行われます。
size_lo = Traces[r_current][t_current]
size_hi = Traces[r_current + l][t_current]
distance_lo = (R_v - r_current) / l
framesize = size_hi*distance_lo + size_lo*(1-distance_lo)
b) R_v < Rf_min: The output frame size is calculated via scaling with respect to the lowest bitrate Rf_min in the trace file, as follows:
b) R_v <Rf_min：出力フレームサイズは、以下のように、トレースファイル内の最低ビットレートRf_minを基準としたスケーリングによって計算されます。
w = R_v / Rf_min
framesize = max(fs_min, factor * Traces[Rf_min][t_current])
c) R_v >= Rf_max: The output frame size is calculated by scaling with respect to the highest bitrate Rf_max in the trace file, as follows:
c) R_v> = Rf_max：出力フレームサイズは、以下のように、トレースファイル内の最高ビットレートRf_maxを基準にスケーリングすることによって計算されます。
w = R_v / Rf_max
framesize = min(fs_max, w * Traces[Rf_max][t_current])
In cases b) and c), floating-point arithmetic is used for computing the scaling factor "w". The resulting value of the instantaneous frame size (framesize) is further clipped within a reasonable range between fs_min (e.g., 10 bytes) and fs_max (e.g., 1 MB).
ケースb）およびc）では、スケーリング係数 "w"の計算に浮動小数点演算が使用されます。結果の瞬間フレームサイズ（framesize）の値は、fs_min（たとえば、10バイト）とfs_max（たとえば、1 MB）の間の妥当な範囲内でさらにクリップされます。
Note that the main algorithm as described above can be further extended to mimic some additional typical behaviors of a live video encoder. Two examples are given below:
上記のメインアルゴリズムをさらに拡張して、ライブビデオエンコーダーのいくつかの追加の典型的な動作を模倣できることに注意してください。以下に2つの例を示します。
o I-frames on demand: The synthetic codec can be extended to simulate the sending of I-frames on demand, e.g., as a reaction to losses. To implement this extension, the codec's incoming interface (see (a) in Figure 1) is augmented with a new function to request a new I-frame. Upon calling such function, t_current is reset to 0.
o オンデマンドのIフレーム：合成コーデックを拡張して、オンデマンドでのIフレームの送信をシミュレートすることができます（たとえば、損失への反応として）。この拡張機能を実装するには、コーデックの着信インターフェイス（図1の（a）を参照）に、新しいIフレームを要求する新しい関数を追加します。このような関数を呼び出すと、t_currentは0にリセットされます。
o Variable step length l between R_min and R_max: In the main algorithm, the step length l is fixed for ease of explanation. However, if the range [R_min, R_max] is very wide, it is also possible to define a set of intermediate encoding rates with variable step length. The rationale behind this modification is that the difference between 400 and 600 kbps as target bitrate is much more significant than the difference between 4400 kbps and 4600 kbps. For example, one could define steps of length 200 kbps under 1 Mbps, then steps of length 300 kbps between 1 Mbps and 2 Mbps, then 400 kbps between 2 Mbps and 3 Mbps, and so on.
o R_minとR_maxの間の可変ステップ長l：メインアルゴリズムでは、説明を簡単にするために、ステップ長lは固定されています。ただし、[R_min、R_max]の範囲が非常に広い場合は、可変ステップ長の中間エンコードレートのセットを定義することもできます。この変更の根拠は、ターゲットビットレートとしての400 kbpsと600 kbpsの違いが、4400 kbpsと4600 kbpsの違いよりもはるかに大きいことです。たとえば、1 Mbpsで200 kbpsの長さのステップを定義し、次に1 Mbpsと2 Mbpsの間で300 kbpsの長さのステップを定義し、次に2 Mbpsと3 Mbpsの間で400 kbpsのように定義します。
The trace-driven synthetic codec model explained in this section is relatively simple due to the choice of fixed frame rate and frame resolution. The model can be extended further to accommodate variable frame rate and/or variable spatial resolution.
このセクションで説明するトレース駆動型合成コーデックモデルは、固定フレームレートとフレーム解像度を選択できるため、比較的単純です。モデルをさらに拡張して、可変フレームレートや可変空間解像度に対応できます。
When the encoded picture quality at a given bitrate is low, one can potentially decrease either the frame rate (if the video sequence is currently in low motion) or the spatial resolution in order to improve quality of experience (QoE) in the overall encoded video. On the other hand, if target bitrate increases to a point where there is no longer a perceptible improvement in the picture quality of individual frames, then one might afford to increase the spatial resolution or the frame rate (useful if the video is currently in high motion).
特定のビットレートでエンコードされた画質が低い場合、フレームレート（ビデオシーケンスが現在動きが遅い場合）または空間解像度のいずれかを減らして、エンコードされたビデオ全体のエクスペリエンス品質（QoE）を向上させることができます。 。一方、ターゲットビットレートが増加して、個々のフレームの画質に知覚できるほどの改善が見られなくなった場合、空間解像度またはフレームレートを増加させることができます（ビデオが現在高い場合に役立ちます）。モーション）。
Many techniques have been proposed to choose over time the best combination of encoder-quantization step size, frame rate, and spatial resolution in order to maximize the quality of live video codecs [Ozer2011] [Hu2012]. Future work may consider extending the trace-driven codec to accommodate variable frame rate and/or resolution.
ライブビデオコーデックの品質を最大化するために、エンコーダー量子化のステップサイズ、フレームレート、空間解像度の最適な組み合わせを時間をかけて選択する多くの手法が提案されています[Ozer2011] [Hu2012]。将来の作業では、トレース駆動型コーデックを拡張して、可変フレームレートや解像度に対応することを検討する可能性があります。
From the perspective of congestion control, varying the spatial resolution typically requires a new intra-coded frame to be generated, thereby incurring a temporary burst in the output traffic pattern. The impact of frame-rate change tends to be more subtle: reducing frame rate from high to low leads to sparsely spaced larger encoded packets instead of many densely spaced smaller packets. Such difference in traffic profiles may still affect the performance of congestion control, especially when outgoing packets are not paced by the media transport module. Investigation of varying frame rate and resolution are left for future work.
輻輳制御の観点から、空間解像度を変更するには、通常、新しいイントラ符号化フレームを生成する必要があるため、出力トラフィックパターンに一時的なバーストが発生します。フレームレート変更の影響はより微妙になる傾向があります。フレームレートを高から低に減らすと、多くの密集した小さなパケットではなく、まばらな間隔の大きなエンコードされたパケットになります。トラフィックプロファイルのこのような違いは、特に送信パケットがメディアトランスポートモジュールによってペーシングされない場合は、依然として輻輳制御のパフォーマンスに影響を与える可能性があります。さまざまなフレームレートと解像度の調査は、今後の作業に残します。
It is worthwhile noting that the statistical and trace-driven models each have their own advantages and drawbacks. Both models are fairly simple to implement. It takes significantly greater effort to fit the parameters of a statistical model to actual encoder output data. In contrast, it is straightforward for a trace-driven model to obtain encoded frame-size data. Once validated, the statistical model is more flexible in mimicking a wide range of encoder/content behaviors by simply varying the corresponding parameters in the model. In this regard, a trace-driven model relies, by definition, on additional data-collection efforts for accommodating new codecs or video contents.
統計モデルとトレースドリブンモデルには、それぞれ独自の利点と欠点があることに注意してください。どちらのモデルも、実装がかなり簡単です。統計モデルのパラメーターを実際のエンコーダーの出力データに合わせるには、かなり大きな労力が必要です。対照的に、トレースドリブンモデルでは、エンコードされたフレームサイズのデータを取得するのは簡単です。いったん検証されると、統計モデルは、モデル内の対応するパラメーターを変更するだけで、エンコーダー/コンテンツのさまざまな動作をより柔軟に模倣できます。この点で、トレースドリブンモデルは、定義により、新しいコーデックまたはビデオコンテンツに対応するための追加のデータ収集作業に依存しています。
In general, the trace-driven model is more realistic for mimicking the ongoing steady-state behavior of a video traffic source with fluctuations around a constant target rate. In contrast, the statistical model is more versatile for simulating the behavior of a video stream in transient, such as when encountering sudden rate changes. It is also possible to combine both methods into a hybrid model. In this case, the steady-state behavior is driven by traces during steady state and the transient-state behavior is driven by the statistical model.
一般に、トレースドリブンモデルは、一定のターゲットレートを中心に変動するビデオトラフィックソースの継続的な定常状態の動作を模倣する場合に、より現実的です。対照的に、統計モデルは、レートの突然の変化に遭遇したときなど、一時的なビデオストリームの動作をシミュレートするためにより汎用性があります。両方の方法を組み合わせてハイブリッドモデルにすることもできます。この場合、定常状態の動作は定常状態中のトレースによって駆動され、過渡状態の動作は統計モデルによって駆動されます。
transient +---------------+
state | Generate next |
+------>| K_d transient |
+-----------------+ / | frames |
R_v | Compare against | / +---------------+
------>| previous |/
| target bitrate |\
+-----------------+ \ +---------------+
\ | Generate next |
+------>| frame from |
steady | trace |
state +---------------+
Figure 3: A Hybrid Video Traffic Model
図3：ハイブリッドビデオトラフィックモデル
As shown in Figure 3, the video traffic model operates in a transient state if the requested target rate R_v is substantially different from the previous target; otherwise, it operates in a steady state. During the transient state, a total of K_d frames are generated by the statistical model, resulting in one (1) big burst frame with size K_B followed by K_d-1 smaller frames. When operating at steady state, the video traffic model simply generates a frame according to the trace-driven model given the target rate while modulating the frame interval according to the distribution specified by the statistical model. One example criterion for determining whether the traffic model should operate in a transient state is whether the rate change exceeds 10% of the previous target rate. Finally, as this model follows transient-state behavior dictated by the statistical model, upon a substantial rate change, the model will follow the time-damping mechanism as defined in Section 5.1, which is governed by parameter tau_v.
図3に示すように、要求された目標レートR_vが前の目標と大幅に異なる場合、ビデオトラフィックモデルは一時的な状態で動作します。それ以外の場合は、定常状態で動作します。過渡状態の間、合計K_dフレームが統計モデルによって生成され、サイズK_Bの1つの大きなバーストフレームと、それに続くK_d-1個の小さいフレームが生成されます。定常状態で動作している場合、ビデオトラフィックモデルは、ターゲットモデルに指定されたトレースドリブンモデルに従ってフレームを生成すると同時に、統計モデルによって指定された分布に従ってフレーム間隔を変調します。トラフィックモデルが一時的な状態で動作する必要があるかどうかを判断するための1つの基準の例は、速度変化が以前の目標速度の10％を超えているかどうかです。最後に、このモデルは統計モデルによって指示された過渡状態の動作に従うので、大幅なレート変更時に、モデルはセクション5.1で定義されている時間減衰メカニズムに従います。
The statistical, trace-driven, and hybrid models as described in this document have been implemented as a stand-alone, platform-independent synthetic traffic source module. It can be easily integrated into network simulation platforms such as [ns-2] and [ns-3], as well as testbeds using a real network. The stand-alone traffic source module is available as an open-source implementation at [Syncodecs].
このドキュメントで説明されている統計、トレースドリブン、およびハイブリッドモデルは、スタンドアロンのプラットフォームに依存しない合成トラフィックソースモジュールとして実装されています。 [ns-2]や[ns-3]などのネットワークシミュレーションプラットフォームや、実際のネットワークを使用するテストベッドに簡単に統合できます。スタンドアロントラフィックソースモジュールは、[Syncodecs]でオープンソース実装として利用できます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
The synthetic video traffic models as described in this document do not impose any security threats. They are designed to mimic realistic traffic patterns for evaluating candidate RTP-based congestion control algorithms so as to ensure stable operations of the network. It is RECOMMENDED that candidate algorithms be tested using the video traffic models presented in this document before wide deployment over the Internet. If the generated synthetic traffic flows are sent over the Internet, they also need to be congestion controlled.
このドキュメントで説明する合成ビデオトラフィックモデルは、セキュリティ上の脅威を課しません。これらは、ネットワークの安定した動作を保証するために、RTPベースの候補輻輳制御アルゴリズムを評価するための現実的なトラフィックパターンを模倣するように設計されています。候補アルゴリズムは、インターネット上で広く展開する前に、このドキュメントに記載されているビデオトラフィックモデルを使用してテストすることをお勧めします。生成された合成トラフィックフローがインターネットを介して送信される場合は、輻輳も制御する必要があります。
[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>。
[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>。
[H264] ITU-T, "Advanced video coding for generic audiovisual services", Recommendation H.264, April 2017, <https://www.itu.int/rec/T-REC-H.264>.
[H264] ITU-T、「汎用オーディオビジュアルサービス用の高度なビデオコーディング」、H.264勧告、2017年4月、<https://www.itu.int/rec/T-REC-H.264>。
[H265] ITU-T, "High efficiency video coding", Recommendation H.265, February 2018, <https://www.itu.int/rec/T-REC-H.265>.
[H265] ITU-T、「高効率ビデオコーディング」、勧告H.265、2018年2月、<https://www.itu.int/rec/T-REC-H.265>。
[Hu2012] Hu, H., Ma, Z., and Y. Wang, "Optimization of Spatial, Temporal and Amplitude Resolution for Rate-Constrained Video Coding and Scalable Video Adaptation", Proc. 19th IEEE International Conference on Image Processing (ICIP), DOI 10.1109/ICIP.2012.6466960, September 2012.
[Hu2012] Hu、H.、Ma、Z。、およびY. Wang、「レート制限されたビデオコーディングおよびスケーラブルなビデオ適応のための空間、時間、および振幅解像度の最適化」、Proc。第19回画像処理に関するIEEE国際会議（ICIP）、DOI 10.1109 / ICIP.2012.6466960、2012年9月。
[IETF-Interim] Zhu, X., Mena, S., and Z. Sarker, "Update on RMCAT Video Traffic Model: Trace Analysis and Model Update", IETF RMCAT Virtual Interim, April 2017, <https://www.ietf.org/proceedings/interim-2017-rmcat-01/slides/slides-interim-2017-rmcat-01-sessa-update-on-video-traffic-model-draft-00.pdf>.
[IETF暫定] Zhu、X.、Mena、S.、Z。Sarker、「RMCATビデオトラフィックモデルの更新：トレース分析とモデルの更新」、IETF RMCAT仮想暫定、2017年4月、<https：// www。 ietf.org/proceedings/interim-2017-rmcat-01/slides/slides-interim-2017-rmcat-01-sessa-update-on-video-traffic-model-draft-00.pdf>。
[ns-2] "The Network Simulator - ns-2", December 2015, <https://nsnam.sourceforge.net/wiki/index.php/ User_Information>.
[ns-2]「ネットワークシミュレータ-ns-2」、2015年12月、<https://nsnam.sourceforge.net/wiki/index.php/ User_Information>。
[ns-3] "NS-3 Network Simulator", <https://www.nsnam.org/>.
[ns-3]「NS-3ネットワークシミュレータ」、<https://www.nsnam.org/>。
[Ozer2011] Ozer, J., "Video Compression for Flash, Apple Devices and HTML5", Galax: Doceo Publishing, ISBN-13: 978-0976259503, 2011.
[Ozer2011] Ozer、J。、「Flash、AppleデバイスおよびHTML5のビデオ圧縮」、Galax：Doceo Publishing、ISBN-13：978-0976259503、2011。
[Papoulis] Papoulis, A. and S. Pillai, "Probability, Random Variables and Stochastic Processes", London: McGraw-Hill Europe, ISBN-13: 978-0071226615, 2002.
[Papoulis] Papoulis、A。およびS. Pillai、「確率、ランダム変数および確率過程」、ロンドン：McGraw-Hill Europe、ISBN-13：978-0071226615、2002。
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC5104] Wenger、S.、Chandra、U.、Westerlund、M。、およびB. Burman、「フィードバック付きのRTPオーディオビジュアルプロファイルのコーデック制御メッセージ（AVPF）」、RFC 5104、DOI 10.17487 / RFC5104、2月2008、<https://www.rfc-editor.org/info/rfc5104>。
[Syncodecs] "Syncodecs: Synthetic codecs for evaluation of RMCAT work", commit a92d6c8, May 2018, <https://github.com/cisco/syncodecs>.
[Syncodecs]「Syncodecs：RMCAT作業を評価するための合成コーデック」、a92d6c8をコミット、2018年5月、<https://github.com/cisco/syncodecs>。
[Tanwir2013] Tanwir, S. and H. Perros, "A Survey of VBR Video Traffic Models", IEEE Communications Surveys and Tutorials, Volume 15, Issue 4, p. 1778-1802, DOI 10.1109/SURV.2013.010413.00071, January 2013.
[Tanwir2013] Tanwir、S.およびH. Perros、「A Survey of VBR Video Traffic Models」、IEEE Communications Surveys and Tutorials、Volume 15、Issue 4、p。 1778-1802、DOI 10.1109 / SURV.2013.010413.00071、2013年1月。
Authors' Addresses
著者のアドレス
Xiaoqing Zhu Cisco Systems 12515 Research Blvd., Building 4 Austin, TX 78759 United States of America
Xiaoqing Zhu Cisco Systems 12515 Research Blvd.、Building 4 Austin、TX 78759 United States of America
Email: xiaoqzhu@cisco.com
Sergio Mena Cisco Systems EPFL, Quartier de l'Innovation, Batiment E Ecublens, Vaud 1015 Switzerland
Sergio Mena Cisco Systems EPFL、Quartier de l'Innovation、Batiment E Ecublens、ヴォー1015スイス
Email: semena@cisco.com
Zaheduzzaman Sarker Ericsson AB Torshamnsgatan 23 Stockholm, SE 164 83 Sweden
Jaheduzzaman SAARCのTorshamansatanのエリクソン23 Stockholm、彼184 63スウェーデン
Phone: +46 10 717 37 43
Email: zaheduzzaman.sarker@ericsson.com