draft-ietf-rmcat-video-traffic-model-04.txt   draft-ietf-rmcat-video-traffic-model-05.txt 
Network Working Group X. Zhu Network Working Group X. Zhu
Internet-Draft S. Mena Internet-Draft S. Mena
Intended status: Informational Cisco Systems Intended status: Informational Cisco Systems
Expires: July 22, 2018 Z. Sarker Expires: January 20, 2019 Z. Sarker
Ericsson AB Ericsson AB
January 18, 2018 July 19, 2018
Modeling Video Traffic Sources for RMCAT Evaluations Video Traffic Models for RTP Congestion Control Evaluations
draft-ietf-rmcat-video-traffic-model-04 draft-ietf-rmcat-video-traffic-model-05
Abstract Abstract
This document describes two reference video traffic source models for This document describes two reference video traffic models for
evaluating RMCAT candidate algorithms. The first model statistically evaluating RTP congestion control algorithms. The first model
characterizes the behavior of a live video encoder in response to statistically characterizes the behavior of a live video encoder in
changing requests on target video rate. The second model is trace- response to changing requests on target video rate. The second model
driven, and emulates the encoder output based on actual encoded video is trace-driven, and emulates the output of actual encoded video
frame sizes from a high-resolution test sequence. Both models are frame sizes from a high-resolution test sequence. Both models are
designed to strike a balance between simplicity, repeatability, and designed to strike a balance between simplicity, repeatability, and
authenticity in modeling the interactions between a live video authenticity in modeling the interactions between a live video
traffic source and the congestion control module. Finally, the traffic source and the congestion control module. Finally, the
document describes how both approaches can be combined into a hybrid document describes how both approaches can be combined into a hybrid
model. model.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 22, 2018. This Internet-Draft will expire on January 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
5.4. Rate range limit imposed by video content . . . . . . . . 9 5.4. Rate range limit imposed by video content . . . . . . . . 9
6. A Trace-Driven Model . . . . . . . . . . . . . . . . . . . . 9 6. A Trace-Driven Model . . . . . . . . . . . . . . . . . . . . 9
6.1. Choosing the video sequence and generating the traces . . 10 6.1. Choosing the video sequence and generating the traces . . 10
6.2. Using the traces in the synthetic codec . . . . . . . . . 11 6.2. Using the traces in the synthetic codec . . . . . . . . . 11
6.2.1. Main algorithm . . . . . . . . . . . . . . . . . . . 11 6.2.1. Main algorithm . . . . . . . . . . . . . . . . . . . 11
6.2.2. Notes to the main algorithm . . . . . . . . . . . . . 13 6.2.2. Notes to the main algorithm . . . . . . . . . . . . . 13
6.3. Varying frame rate and resolution . . . . . . . . . . . . 13 6.3. Varying frame rate and resolution . . . . . . . . . . . . 13
7. Combining The Two Models . . . . . . . . . . . . . . . . . . 14 7. Combining The Two Models . . . . . . . . . . . . . . . . . . 14
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
When evaluating candidate congestion control algorithms designed for When evaluating candidate congestion control algorithms designed for
real-time interactive media, it is important to account for the real-time interactive media, it is important to account for the
characteristics of traffic patterns generated from a live video characteristics of traffic patterns generated from a live video
encoder. Unlike synthetic traffic sources that can conform perfectly encoder. Unlike synthetic traffic sources that can conform perfectly
to the rate changing requests from the congestion control module, a to the rate changing requests from the congestion control module, a
live video encoder can be sluggish in reacting to such changes. live video encoder can be sluggish in reacting to such changes.
Output rate of a live video encoder also typically deviates from the Output rate of a live video encoder also typically deviates from the
target rate due to uncertainties in the encoder rate control process. target rate due to uncertainties in the encoder rate control process.
Consequently, end-to-end delay and loss performance of a real-time Consequently, end-to-end delay and loss performance of a real-time
media flow can be further impacted by rate variations introduced by media flow can be further impacted by rate variations introduced by
the live encoder. the live encoder.
On the other hand, evaluation results of a candidate RMCAT algorithm On the other hand, evaluation results of a candidate RTP congestion
should mostly reflect performance of the congestion control module, control algorithm should mostly reflect performance of the congestion
and somewhat decouple from peculiarities of any specific video codec. control module, and somewhat decouple from peculiarities of any
It is also desirable that evaluation tests are repeatable, and be specific video codec. It is also desirable that evaluation tests are
easily duplicated across different candidate algorithms. repeatable, and be easily duplicated across different candidate
algorithms.
One way to strike a balance between the above considerations is to One way to strike a balance between the above considerations is to
evaluate RMCAT algorithms using a synthetic video traffic source evaluate congestion control algorithms using a synthetic video
model that captures key characteristics of the behavior of a live traffic source model that captures key characteristics of the
video encoder. To this end, this draft presents two reference behavior of a live video encoder. To this end, this draft presents
models. The first is based on statistical modeling; the second is two reference models. The first is based on statistical modeling;
trace-driven. The draft also discusses the pros and cons of each the second is trace-driven. The draft also discusses the pros and
approach, as well as how both approaches can be combined into a cons of each approach, as well as how both approaches can be combined
hybrid model. into a hybrid model.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described RFC2119 [RFC2119]. "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.
3. Desired Behavior of A Synthetic Video Traffic Model 3. Desired Behavior of A Synthetic Video Traffic Model
A live video encoder employs encoder rate control to meet a target A live video encoder employs encoder rate control to meet a target
rate by varying its encoding parameters, such as quantization step rate by varying its encoding parameters, such as quantization step
size, frame rate, and picture resolution, based on its estimate of size, frame rate, and picture resolution, based on its estimate of
the video content (e.g., motion and scene complexity). In practice, the video content (e.g., motion and scene complexity). In practice,
however, several factors prevent the output video rate from perfectly however, several factors prevent the output video rate from perfectly
conforming to the input target rate. conforming to the input target rate.
skipping to change at page 4, line 27 skipping to change at page 4, line 30
common characteristics, as outlined below. common characteristics, as outlined below.
o Low computational complexity: The model should be computationally o Low computational complexity: The model should be computationally
lightweight, otherwise it defeats the whole purpose of serving as lightweight, otherwise it defeats the whole purpose of serving as
a substitute for a live video encoder. a substitute for a live video encoder.
o Temporal pattern similarity: The individual traffic trace o Temporal pattern similarity: The individual traffic trace
instances generated by the model should mimic the temporal pattern instances generated by the model should mimic the temporal pattern
of those from a real video encoder. of those from a real video encoder.
o Statistical resemblance: The synthetic traffic should match the o Statistical resemblance: The synthetic traffic source should match
outcome of the real video encoder in terms of statistical the outcome of the real video encoder in terms of statistical
characteristics, such as the mean, variance, peak, and characteristics, such as the mean, variance, peak, and
autocorrelation coefficients of the bitrate. It is also important autocorrelation coefficients of the bitrate. It is also important
that the statistical resemblance should hold across different time that the statistical resemblance should hold across different time
scales, ranging from tens of milliseconds to sub-seconds. scales, ranging from tens of milliseconds to sub-seconds.
o Wide range of coverage: The model should be easily configurable to o Wide range of coverage: The model should be easily configurable to
cover a wide range of codec behaviors (e.g., with either fast or cover a wide range of codec behaviors (e.g., with either fast or
slow reaction time in live encoder rate control) and video content slow reaction time in live encoder rate control) and video content
variations (e.g., ranging from high-motion to low-motion). variations (e.g., ranging from high-motion to low-motion).
These distinct behavior features can be characterized via simple These distinct behavior features can be characterized via simple
statistical modelling, or a trace-driven approach. Section 5 and statistical modelling, or a trace-driven approach. Section 5 and
Section 6 provide an example of each approach, respectively. Section 6 provide an example of each approach, respectively.
Section 7 discusses how both models can be combined together. Section 7 discusses how both models can be combined together.
4. Interactions Between Synthetic Video Traffic Source and Other 4. Interactions Between Synthetic Video Traffic Source and Other
Components at the Sender Components at the Sender
Figure 1 depicts the interactions of the synthetic video encoder with Figure 1 depicts the interactions of the synthetic video traffic
other components at the sender, such as the application, the source with other components at the sender, such as the application,
congestion control module, the media packet transport module, etc. the congestion control module, the media packet transport module,
Both reference models, as described later in Section 5 and Section 6, etc. Both reference models --- as described later in Section 5 and
follow the same set of interactions. Section 6 --- follow the same set of interactions.
The synthetic video encoder takes in raw video frames captured by the The synthetic video source dynamically generates a sequence of dummy
camera and then dynamically generates a sequence of encoded video video frames with varying size and interval. These dummy frames are
frames with varying size and interval. These encoded frames are
processed by other modules in order to transmit the video stream over processed by other modules in order to transmit the video stream over
the network. During the lifetime of a video transmission session, the network. During the lifetime of a video transmission session,
the synthetic video encoder will typically be required to adapt its the synthetic video source will typically be required to adapt its
encoding bitrate, and sometimes the spatial resolution and frame encoding bitrate, and sometimes the spatial resolution and frame
rate. rate.
In our model, the synthetic video encoder module has a group of In our model, the synthetic video source module has a group of
incoming and outgoing interface calls that allow for interaction with incoming and outgoing interface calls that allow for interaction with
other modules. The following are some of the possible incoming other modules. The following are some of the possible incoming
interface calls --- marked as (a) in Figure 1 --- that the synthetic interface calls --- marked as (a) in Figure 1 --- that the synthetic
video encoder may accept. The list is not exhaustive and can be video traffic source may accept. The list is not exhaustive and can
complemented by other interface calls if deemed necessary. be complemented by other interface calls if deemed necessary.
o Target rate R_v: target rate request to the encoder, typically o Target rate R_v: target rate request, typically calculated by the
from the congestion control module and updated dynamically over congestion control module and updated dynamically over time.
time. Depending on the congestion control algorithm in use, the Depending on the congestion control algorithm in use, the update
update requests can either be periodic (e.g., once per second), or requests can either be periodic (e.g., once per second), or on-
on-demand (e.g., only when a drastic bandwidth change over the demand (e.g., only when a drastic bandwidth change over the
network is observed). network is observed).
o Target frame rate FPS: the instantaneous frame rate measured in o Target frame rate FPS: the instantaneous frame rate measured in
frames-per-second at a given time. This depends on the native frames-per-second at a given time. This depends on the native
camera capture frame rate as well as the target/preferred frame camera capture frame rate as well as the target/preferred frame
rate configured by the application or user. rate configured by the application or user.
o Frame resolution XY: the 2-dimensional vector indicating the o Target frame resolution XY: the 2-dimensional vector indicating
preferred frame resolution in pixels. Several factors govern the the preferred frame resolution in pixels. Several factors govern
resolution requested to the synthetic video encoder over time. the resolution requested to the synthetic video source over time.
Examples of such factors are the capturing resolution of the Examples of such factors include the capturing resolution of the
native camera; or the current target rate R_v, since very small native camera and the display size of the destination screen. The
resolutions do not make sense with very high bitrates, and vice- target frame resolution also depends on the current target rate
versa. R_v, since very small resolutions do not make sense with very high
bitrates, and vice-versa.
o Instant frame skipping: the request to skip the encoding of one or o Instant frame skipping: the request to skip the encoding of one or
several captured video frames, for instance when a drastic several captured video frames, for instance when a drastic
decrease in available network bandwidth is detected. decrease in available network bandwidth is detected.
o On-demand generation of intra (I) frame: the request to encode o On-demand generation of intra (I) frame: the request to encode
another I frame to avoid further error propagation at the another I frame to avoid further error propagation at the
receiver, if severe packet losses are observed. This request receiver, if severe packet losses are observed. This request
typically comes from the error control module. typically comes from the error control module.
An example of outgoing interface call --- marked as (b) in Figure 1 An example of outgoing interface call --- marked as (b) in Figure 1
--- is the rate range, that is, the dynamic range of the video --- is the rate range [R_min, R_max]. Here, R_min and R_max are
encoder's output rate for the current video contents: [R_min, R_max]. meant to capture the dynamic rate range and actual live video encoder
Here, R_min and R_max are meant to capture the dynamic rate range the is capable of generating given the input video content. This
encoder is capable of outputting. This typically depends on the typically depends on the video content complexity and/or display type
video content complexity and/or display type (e.g., higher R_max for (e.g., higher R_max for video contents with higher motion complexity,
video contents with higher motion complexity, or for displays of or for displays of higher resolution). Therefore, these values will
higher resolution). Therefore, these values will not change with not change with R_v, but may change over time if the content is
R_v, but may change over time if the content is changing. changing.
+-------------+ +-------------+
raw video | | encoded video | | encoded video
frames | Synthetic | frames | Synthetic | frames
------------> | Video | --------------> | Video | -------------->
| Encoder | | Source |
| | | |
+--------+----+ +--------+----+
/|\ | /|\ |
| | | |
-------------------+ +--------------------> -------------------+ +-------------------->
interface from interface to interface from interface to
other modules (a) other modules (b) other modules (a) other modules (b)
Figure 1: Interaction between synthetic video encoder and other Figure 1: Interaction between synthetic video encoder and other
modules at the sender modules at the sender
5. A Statistical Reference Model 5. A Statistical Reference Model
This section describes one simple statistical model of the live video This section describes one simple statistical model of the live video
encoder traffic source. Figure 2 summarizes the list of tunable encoder traffic source. Figure 2 summarizes the list of tunable
parameters in this statistical model. A more comprehensive survey of parameters in this statistical model. A more comprehensive survey of
popular methods for modeling video traffic source behavior can be popular methods for modeling video traffic source behavior can be
found in [Tanwir2013]. found in [Tanwir2013].
+==============+====================================+================+ +===========+====================================+================+
| Notation | Parameter Name | Example Value | | Notation | Parameter Name | Example Value |
+==============+====================================+================+ +===========+====================================+================+
| R_v | Target rate request to encoder | 1 Mbps | | R_v | Target rate request | 1 Mbps |
+--------------+------------------------------------+----------------+ +-----------+------------------------------------+----------------+
| FPS | Target frame rate of encoder output| 30 Hz | | FPS | Target frame rate | 30 Hz |
+--------------+------------------------------------+----------------+ +-----------+------------------------------------+----------------+
| tau_v | Encoder reaction latency | 0.2 s | | tau_v | Encoder reaction latency | 0.2 s |
+--------------+------------------------------------+----------------+ +-----------+------------------------------------+----------------+
| K_d | Burst duration during transient | 8 frames | | K_d | Burst duration during transient | 8 frames |
+--------------+------------------------------------+----------------+ +-----------+------------------------------------+----------------+
| K_B | Burst frame size during transient | 13.5 KBytes* | | K_B | Burst frame size during transient | 13.5 KBytes* |
+--------------+------------------------------------+----------------+ +-----------+------------------------------------+----------------+
| t0 | Reference frame interval 1/FPS | 33 ms | | t0 | Reference frame interval 1/FPS | 33 ms |
+--------------+------------------------------------+----------------+ +-----------+------------------------------------+----------------+
| B0 | Reference frame size R_v/8/FPS | 4.17 KBytes | | B0 | Reference frame size R_v/8/FPS | 4.17 KBytes |
+--------------+------------------------------------+----------------+ +-----------+------------------------------------+----------------+
| | Scaling parameter of the zero-mean | | | | Scaling parameter of the zero-mean | |
| | Laplacian distribution describing | | | | Laplacian distribution describing | |
| SCALE_t | deviations in normalized frame | 0.15 | | SCALE_t | deviations in normalized frame | 0.15 |
| | interval (t-t0)/t0 | | | | interval (t-t0)/t0 | |
+--------------+------------------------------------+----------------+ +-----------+------------------------------------+----------------+
| | Scaling parameter of the zero-mean | | | | Scaling parameter of the zero-mean | |
| | Laplacian distribution describing | | | | Laplacian distribution describing | |
| SCALE_B | deviations in normalized frame | 0.15 | | SCALE_B | deviations in normalized frame | 0.15 |
| | size (B-B0)/B0 | | | | size (B-B0)/B0 | |
+--------------+------------------------------------+----------------+ +-----------+------------------------------------+----------------+
| R_min | minimum rate supported by video | 150 Kbps | | R_min | minimum rate supported by video | 150 Kbps |
| | encoder or content activity | | | | encoder type or content activity | |
+--------------+------------------------------------+----------------+ +-----------+------------------------------------+----------------+
| R_max | maximum rate supported by video | 1.5 Mbps | | R_max | maximum rate supported by video | 1.5 Mbps |
| | encoder or content activity | | | | encoder type or content activity | |
+==============+====================================+================+ +===========+====================================+================+
* Example value of K_B for a video stream encoded at 720p and 30 frames * Example value of K_B for a video stream encoded at 720p and
per second, using H.264/AVC encoder. 30 frames per second, using H.264/AVC encoder.
Figure 2: List of tunable parameters in a statistical video traffic Figure 2: List of tunable parameters in a statistical video traffic
source model. source model.
5.1. Time-damped response to target rate update 5.1. Time-damped response to target rate update
While the congestion control module can update its target rate While the congestion control module can update its target rate
request R_v at any time, the statistical model dictates that the request R_v at any time, the statistical model dictates that the
encoder will only react to such changes tau_v seconds after a encoder will only react to such changes tau_v seconds after a
previous rate transition. In other words, when the encoder has previous rate transition. In other words, when the encoder has
skipping to change at page 9, line 27 skipping to change at page 9, line 27
The output rate R_o is further clipped within the dynamic range The output rate R_o is further clipped within the dynamic range
[R_min, R_max], which in reality are dictated by scene and motion [R_min, R_max], which in reality are dictated by scene and motion
complexity of the captured video content. In the proposed complexity of the captured video content. In the proposed
statistical model, these parameters are specified by the application. statistical model, these parameters are specified by the application.
6. A Trace-Driven Model 6. A Trace-Driven Model
The second approach for modelling a video traffic source is trace- The second approach for modelling a video traffic source is trace-
driven. This can be achieved by running an actual live video encoder 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 on a set of chosen raw video sequences and using the encoder's output
traces for constructing a synthetic live encoder. With this traces for constructing a synthetic video source. With this
approach, the recorded video traces naturally exhibit temporal approach, the recorded video traces naturally exhibit temporal
fluctuations around a given target rate request R_v from the fluctuations around a given target rate request R_v from the
congestion control module. congestion control module.
The following list summarizes the main steps of this approach: The following list summarizes the main steps of this approach:
1. Choose one or more representative raw video sequences. 1. Choose one or more representative raw video sequences.
2. Encode the sequence(s) using an actual live video encoder. 2. Encode the sequence(s) using an actual live video encoder.
Repeat the process for a number of bitrates. Keep only the Repeat the process for a number of bitrates. Keep only the
skipping to change at page 9, line 49 skipping to change at page 9, line 49
3. Construct a data structure that contains the output of the 3. Construct a data structure that contains the output of the
previous step. The data structure should allow for easy bitrate previous step. The data structure should allow for easy bitrate
lookup. lookup.
4. Upon a target bitrate request R_v from the controller, look up 4. Upon a target bitrate request R_v from the controller, look up
the closest bitrates among those previously stored. Use the the closest bitrates among those previously stored. Use the
frame size sequences stored for those bitrates to approximate the frame size sequences stored for those bitrates to approximate the
frame sizes to output. frame sizes to output.
5. The output of the synthetic encoder contains "encoded" frames 5. The output of the synthetic video traffic source contains
with zeros as contents but with realistic sizes. "encoded" frames with dummy contents but with realistic sizes.
In the following, Section 6.1 explains the first three steps (1-3), In the following, Section 6.1 explains the first three steps (1-3),
Section 6.2 elaborates on the remaining two steps (4-5). Finally, Section 6.2 elaborates on the remaining two steps (4-5). Finally,
Section 6.3 briefly discusses the possibility to extend the trace- Section 6.3 briefly discusses the possibility to extend the trace-
driven model for supporting time-varying frame rate and/or time- driven model for supporting time-varying frame rate and/or time-
varying frame resolution. varying frame resolution.
6.1. Choosing the video sequence and generating the traces 6.1. Choosing the video sequence and generating the traces
The first step is a careful choice of a set of video sequences that The first step is a careful choice of a set of video sequences that
skipping to change at page 12, line 5 skipping to change at page 12, line 5
The main algorithm for rate adaptation in the synthetic codec The main algorithm for rate adaptation in the synthetic codec
maintains two variables: r_current and t_current. maintains two variables: r_current and t_current.
o The variable r_current points to one of the keys of map Traces. 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 Upon a change in the value of R_v, typically because the
congestion controller detects that the network conditions have congestion controller detects that the network conditions have
changed, r_current is updated to the greatest key in Traces that changed, r_current is updated to the greatest key in Traces that
is less than or equal to the new value of R_v. It is assumed that is less than or equal to the new value of R_v. It is assumed that
the value of R_v is clipped within the range [R_min, R_max]. the value of R_v is clipped within the range [R_min, R_max].
r_current = r r_current = r
such that such that
( r in keys(Traces) and (r in keys(Traces) and
r <= R_v and r <= R_v and
(not(exists) r' in keys(Traces) such that r < r' <= R_v) ) (not(exists) r' in keys(Traces) such that r <r'<= R_v))
o The variable t_current is an index to the frame size vector stored 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 in Traces[r_current]. It is updated every time a new frame is
due. It is assumed that all vectors stored Traces to have the due. It is assumed that all vectors stored Traces to have the
same size, denoted as size_traces. The following equation governs same size, denoted as size_traces. The following equation governs
the update of t_current: the update of t_current:
if t_current < SkipFrames then if t_current < SkipFrames then
t_current = t_current + 1 t_current = t_current + 1
else else
t_current = ((t_current+1-SkipFrames) % (size_traces-SkipFrames)) t_current = ( (t_current + 1 - SkipFrames)
% (size_traces-SkipFrames))
+ SkipFrames + SkipFrames
where operator % denotes modulo, and SkipFrames is a predefined where operator % denotes modulo, and SkipFrames is a predefined
constant that denotes the number of frames to be skipped at the constant that denotes the number of frames to be skipped at the
beginning of frame size vectors after t_current has wrapped around. beginning of frame size vectors after t_current has wrapped around.
The point of constant SkipFrames is avoiding the effect of The point of constant SkipFrames is avoiding the effect of
periodically sending a large I-frame followed by several smaller- periodically sending a large I-frame followed by several smaller-
than-average P-frames. A typical value of SkipFrames is 20, although 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 it could be set to 0 if one is interested in studying the effect of
sending I-frames periodically. sending I-frames periodically.
skipping to change at page 12, line 43 skipping to change at page 12, line 44
of t_current set to 0. of t_current set to 0.
When a new frame is due, its size can be calculated following one of When a new frame is due, its size can be calculated following one of
the three cases below: the three cases below:
a) R_min <= R_v < Rmax: the output frame size is calculated via a) R_min <= R_v < Rmax: the output frame size is calculated via
linear interpolation of the frame sizes appearing in linear interpolation of the frame sizes appearing in
Traces[r_current] and Traces[r_current + l]. The interpolation is Traces[r_current] and Traces[r_current + l]. The interpolation is
done as follows: done as follows:
size_lo = Traces[r_current][t_current] size_lo = Traces[r_current][t_current]
size_hi = Traces[r_current + l][t_current] size_hi = Traces[r_current + l][t_current]
distance_lo = ( R_v - r_current ) / l distance_lo = (R_v - r_current) / l
framesize = size_hi * distance_lo + size_lo * (1 - distance_lo) framesize = size_hi*distance_lo + size_lo*(1-distance_lo)
b) R_v < R_min: the output frame size is calculated via scaling with b) R_v < R_min: the output frame size is calculated via scaling with
respect to the lowest bitrate R_min, as follows: respect to the lowest bitrate R_min, as follows:
factor = R_v / R_min factor = R_v / R_min
framesize = max(1, factor * Traces[R_min][t_current]) framesize = max(1, factor * Traces[R_min][t_current])
c) R_v >= R_max: the output frame size is calculated by scaling with c) R_v >= R_max: the output frame size is calculated by scaling with
respect to the highest bitrate R_max: respect to the highest bitrate R_max:
factor = R_v / R_max factor = R_v / R_max
framesize = factor * Traces[R_max][t_current] framesize = factor * Traces[R_max][t_current]
In case b), we set the minimum output size to 1 byte, since the value In case b), we set the minimum output size to 1 byte, since the value
of factor can be arbitrarily close to 0. of factor can be arbitrarily close to 0.
6.2.2. Notes to the main algorithm 6.2.2. Notes to the main algorithm
Note that main algorithm as described above can be further extended Note that main algorithm as described above can be further extended
to mimic some additional typical behaviors of a live encoder. Two to mimic some additional typical behaviors of a live video encoder.
examples are given below: Two examples are given below:
o I-frames on demand: The synthetic codec can be extended to 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 simulate the sending of I-frames on demand, e.g., as a reaction to
losses. To implement this extension, the codec's incoming losses. To implement this extension, the codec's incoming
interface (see (a) in Figure 1) is augmented with a new function interface (see (a) in Figure 1) is augmented with a new function
to request a new I-frame. Upon calling such function, t_current to request a new I-frame. Upon calling such function, t_current
is reset to 0. is reset to 0.
o Variable step length l between R_min and R_max: In the main 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. algorithm, the step length l is fixed for ease of explanation.
skipping to change at page 16, line 9 skipping to change at page 16, line 9
been implemented as a stand-alone, platform-independent traffic been implemented as a stand-alone, platform-independent traffic
source module. This can be easily integrated into network simulation source module. This can be easily integrated into network simulation
platforms such as [ns-2] and [ns-3], as well as testbeds using a real 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 network. The stand-alone traffic source module is available as an
open source implementation at [Syncodecs]. open source implementation at [Syncodecs].
9. IANA Considerations 9. IANA Considerations
There are no IANA impacts in this memo. There are no IANA impacts in this memo.
10. References 10. Security Considerations
10.1. Normative References It is important to evaluate RTP-based congestion control schemes
using realistic traffic patterns, so as to ensure stable operations
of the network. Therefore, it is RECOMMENDED that candidate RTP-
based congestion control algorithms be tested using the video traffic
models presented in this draft before wide deployment over the
Internet.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References [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>.
11.2. Informative References
[H264] ITU-T Recommendation H.264, "Advanced video coding for [H264] ITU-T Recommendation H.264, "Advanced video coding for
generic audiovisual services", May 2003, generic audiovisual services", May 2003,
<https://www.itu.int/rec/T-REC-H.264>. <https://www.itu.int/rec/T-REC-H.264>.
[HEVC] ITU-T Recommendation H.265, "High efficiency video [HEVC] ITU-T Recommendation H.265, "High efficiency video
coding", April 2013, coding", April 2013,
<https://www.itu.int/rec/T-REC-H.265>. <https://www.itu.int/rec/T-REC-H.265>.
[Hu2010] Hu, H., Ma, Z., and Y. Wang, "Optimization of Spatial, [Hu2010] Hu, H., Ma, Z., and Y. Wang, "Optimization of Spatial,
 End of changes. 30 change blocks. 
121 lines changed or deleted 139 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/