idnits 2.17.1 draft-ietf-rmcat-video-traffic-model-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 37 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (January 18, 2018) is 2291 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Zhu 3 Internet-Draft S. Mena 4 Intended status: Informational Cisco Systems 5 Expires: July 22, 2018 Z. Sarker 6 Ericsson AB 7 January 18, 2018 9 Modeling Video Traffic Sources for RMCAT Evaluations 10 draft-ietf-rmcat-video-traffic-model-04 12 Abstract 14 This document describes two reference video traffic source models for 15 evaluating RMCAT candidate algorithms. The first model statistically 16 characterizes the behavior of a live video encoder in response to 17 changing requests on target video rate. The second model is trace- 18 driven, and emulates the encoder output based on actual encoded video 19 frame sizes from a high-resolution test sequence. Both models are 20 designed to strike a balance between simplicity, repeatability, and 21 authenticity in modeling the interactions between a live video 22 traffic source and the congestion control module. Finally, the 23 document describes how both approaches can be combined into a hybrid 24 model. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 22, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Desired Behavior of A Synthetic Video Traffic Model . . . . . 3 63 4. Interactions Between Synthetic Video Traffic Source and 64 Other Components at the Sender . . . . . . . . . . . . . . . 4 65 5. A Statistical Reference Model . . . . . . . . . . . . . . . . 6 66 5.1. Time-damped response to target rate update . . . . . . . 7 67 5.2. Temporary burst and oscillation during transient . . . . 8 68 5.3. Output rate fluctuation at steady state . . . . . . . . . 8 69 5.4. Rate range limit imposed by video content . . . . . . . . 9 70 6. A Trace-Driven Model . . . . . . . . . . . . . . . . . . . . 9 71 6.1. Choosing the video sequence and generating the traces . . 10 72 6.2. Using the traces in the synthetic codec . . . . . . . . . 11 73 6.2.1. Main algorithm . . . . . . . . . . . . . . . . . . . 11 74 6.2.2. Notes to the main algorithm . . . . . . . . . . . . . 13 75 6.3. Varying frame rate and resolution . . . . . . . . . . . . 13 76 7. Combining The Two Models . . . . . . . . . . . . . . . . . . 14 77 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 10.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 When evaluating candidate congestion control algorithms designed for 87 real-time interactive media, it is important to account for the 88 characteristics of traffic patterns generated from a live video 89 encoder. Unlike synthetic traffic sources that can conform perfectly 90 to the rate changing requests from the congestion control module, a 91 live video encoder can be sluggish in reacting to such changes. 92 Output rate of a live video encoder also typically deviates from the 93 target rate due to uncertainties in the encoder rate control process. 94 Consequently, end-to-end delay and loss performance of a real-time 95 media flow can be further impacted by rate variations introduced by 96 the live encoder. 98 On the other hand, evaluation results of a candidate RMCAT algorithm 99 should mostly reflect performance of the congestion control module, 100 and somewhat decouple from peculiarities of any specific video codec. 101 It is also desirable that evaluation tests are repeatable, and be 102 easily duplicated across different candidate algorithms. 104 One way to strike a balance between the above considerations is to 105 evaluate RMCAT algorithms using a synthetic video traffic source 106 model that captures key characteristics of the behavior of a live 107 video encoder. To this end, this draft presents two reference 108 models. The first is based on statistical modeling; the second is 109 trace-driven. The draft also discusses the pros and cons of each 110 approach, as well as how both approaches can be combined into a 111 hybrid model. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described RFC2119 [RFC2119]. 119 3. Desired Behavior of A Synthetic Video Traffic Model 121 A live video encoder employs encoder rate control to meet a target 122 rate by varying its encoding parameters, such as quantization step 123 size, frame rate, and picture resolution, based on its estimate of 124 the video content (e.g., motion and scene complexity). In practice, 125 however, several factors prevent the output video rate from perfectly 126 conforming to the input target rate. 128 Due to uncertainties in the captured video scene, the output rate 129 typically deviates from the specified target. In the presence of a 130 significant change in target rate, it sometimes takes several frames 131 before the encoder output rate converges to the new target. Finally, 132 while most of the frames in a live session are encoded in predictive 133 mode, the encoder can occasionally generate a large intra-coded frame 134 (or a frame partially containing intra-coded blocks) in an attempt to 135 recover from losses, to re-sync with the receiver, or during the 136 transient period of responding to target rate or spatial resolution 137 changes. 139 Hence, a synthetic video source should have the following 140 capabilities: 142 o To change bitrate. This includes ability to change framerate and/ 143 or spatial resolution, or to skip frames when required. 145 o To fluctuate around the target bitrate specified by the congestion 146 control module. 148 o To show a delay in convergence to the target bitrate. 150 o To generate intra-coded or repair frames on demand. 152 While there exist many different approaches in developing a synthetic 153 video traffic model, it is desirable that the outcome follows a few 154 common characteristics, as outlined below. 156 o Low computational complexity: The model should be computationally 157 lightweight, otherwise it defeats the whole purpose of serving as 158 a substitute for a live video encoder. 160 o Temporal pattern similarity: The individual traffic trace 161 instances generated by the model should mimic the temporal pattern 162 of those from a real video encoder. 164 o Statistical resemblance: The synthetic traffic should match the 165 outcome of the real video encoder in terms of statistical 166 characteristics, such as the mean, variance, peak, and 167 autocorrelation coefficients of the bitrate. It is also important 168 that the statistical resemblance should hold across different time 169 scales, ranging from tens of milliseconds to sub-seconds. 171 o Wide range of coverage: The model should be easily configurable to 172 cover a wide range of codec behaviors (e.g., with either fast or 173 slow reaction time in live encoder rate control) and video content 174 variations (e.g., ranging from high-motion to low-motion). 176 These distinct behavior features can be characterized via simple 177 statistical modelling, or a trace-driven approach. Section 5 and 178 Section 6 provide an example of each approach, respectively. 179 Section 7 discusses how both models can be combined together. 181 4. Interactions Between Synthetic Video Traffic Source and Other 182 Components at the Sender 184 Figure 1 depicts the interactions of the synthetic video encoder with 185 other components at the sender, such as the application, the 186 congestion control module, the media packet transport module, etc. 187 Both reference models, as described later in Section 5 and Section 6, 188 follow the same set of interactions. 190 The synthetic video encoder takes in raw video frames captured by the 191 camera and then dynamically generates a sequence of encoded video 192 frames with varying size and interval. These encoded frames are 193 processed by other modules in order to transmit the video stream over 194 the network. During the lifetime of a video transmission session, 195 the synthetic video encoder will typically be required to adapt its 196 encoding bitrate, and sometimes the spatial resolution and frame 197 rate. 199 In our model, the synthetic video encoder module has a group of 200 incoming and outgoing interface calls that allow for interaction with 201 other modules. The following are some of the possible incoming 202 interface calls --- marked as (a) in Figure 1 --- that the synthetic 203 video encoder may accept. The list is not exhaustive and can be 204 complemented by other interface calls if deemed necessary. 206 o Target rate R_v: target rate request to the encoder, typically 207 from the congestion control module and updated dynamically over 208 time. Depending on the congestion control algorithm in use, the 209 update requests can either be periodic (e.g., once per second), or 210 on-demand (e.g., only when a drastic bandwidth change over the 211 network is observed). 213 o Target frame rate FPS: the instantaneous frame rate measured in 214 frames-per-second at a given time. This depends on the native 215 camera capture frame rate as well as the target/preferred frame 216 rate configured by the application or user. 218 o Frame resolution XY: the 2-dimensional vector indicating the 219 preferred frame resolution in pixels. Several factors govern the 220 resolution requested to the synthetic video encoder over time. 221 Examples of such factors are the capturing resolution of the 222 native camera; or the current target rate R_v, since very small 223 resolutions do not make sense with very high bitrates, and vice- 224 versa. 226 o Instant frame skipping: the request to skip the encoding of one or 227 several captured video frames, for instance when a drastic 228 decrease in available network bandwidth is detected. 230 o On-demand generation of intra (I) frame: the request to encode 231 another I frame to avoid further error propagation at the 232 receiver, if severe packet losses are observed. This request 233 typically comes from the error control module. 235 An example of outgoing interface call --- marked as (b) in Figure 1 236 --- is the rate range, that is, the dynamic range of the video 237 encoder's output rate for the current video contents: [R_min, R_max]. 238 Here, R_min and R_max are meant to capture the dynamic rate range the 239 encoder is capable of outputting. This typically depends on the 240 video content complexity and/or display type (e.g., higher R_max for 241 video contents with higher motion complexity, or for displays of 242 higher resolution). Therefore, these values will not change with 243 R_v, but may change over time if the content is changing. 245 +-------------+ 246 raw video | | encoded video 247 frames | Synthetic | frames 248 ------------> | Video | --------------> 249 | Encoder | 250 | | 251 +--------+----+ 252 /|\ | 253 | | 254 -------------------+ +--------------------> 255 interface from interface to 256 other modules (a) other modules (b) 258 Figure 1: Interaction between synthetic video encoder and other 259 modules at the sender 261 5. A Statistical Reference Model 263 This section describes one simple statistical model of the live video 264 encoder traffic source. Figure 2 summarizes the list of tunable 265 parameters in this statistical model. A more comprehensive survey of 266 popular methods for modeling video traffic source behavior can be 267 found in [Tanwir2013]. 269 +==============+====================================+================+ 270 | Notation | Parameter Name | Example Value | 271 +==============+====================================+================+ 272 | R_v | Target rate request to encoder | 1 Mbps | 273 +--------------+------------------------------------+----------------+ 274 | FPS | Target frame rate of encoder output| 30 Hz | 275 +--------------+------------------------------------+----------------+ 276 | tau_v | Encoder reaction latency | 0.2 s | 277 +--------------+------------------------------------+----------------+ 278 | K_d | Burst duration during transient | 8 frames | 279 +--------------+------------------------------------+----------------+ 280 | K_B | Burst frame size during transient | 13.5 KBytes* | 281 +--------------+------------------------------------+----------------+ 282 | t0 | Reference frame interval 1/FPS | 33 ms | 283 +--------------+------------------------------------+----------------+ 284 | B0 | Reference frame size R_v/8/FPS | 4.17 KBytes | 285 +--------------+------------------------------------+----------------+ 286 | | Scaling parameter of the zero-mean | | 287 | | Laplacian distribution describing | | 288 | SCALE_t | deviations in normalized frame | 0.15 | 289 | | interval (t-t0)/t0 | | 290 +--------------+------------------------------------+----------------+ 291 | | Scaling parameter of the zero-mean | | 292 | | Laplacian distribution describing | | 293 | SCALE_B | deviations in normalized frame | 0.15 | 294 | | size (B-B0)/B0 | | 295 +--------------+------------------------------------+----------------+ 296 | R_min | minimum rate supported by video | 150 Kbps | 297 | | encoder or content activity | | 298 +--------------+------------------------------------+----------------+ 299 | R_max | maximum rate supported by video | 1.5 Mbps | 300 | | encoder or content activity | | 301 +==============+====================================+================+ 303 * Example value of K_B for a video stream encoded at 720p and 30 frames 304 per second, using H.264/AVC encoder. 306 Figure 2: List of tunable parameters in a statistical video traffic 307 source model. 309 5.1. Time-damped response to target rate update 311 While the congestion control module can update its target rate 312 request R_v at any time, the statistical model dictates that the 313 encoder will only react to such changes tau_v seconds after a 314 previous rate transition. In other words, when the encoder has 315 reacted to a rate change request at time t, it will simply ignore all 316 subsequent rate change requests until time t+tau_v. 318 5.2. Temporary burst and oscillation during transient 320 The output rate R_o during the period [t, t+tau_v] is considered to 321 be in transient. Based on observations from video encoder output 322 data, the transient behavior of an encoder upon reacting to a new 323 target rate request is modelled in the form of high variation in 324 output frame sizes. It is assumed that the overall average output 325 rate R_o during this period matches the target rate R_v. 326 Consequently, the occasional burst of large frames are followed by 327 smaller-than-average encoded frames. 329 This temporary burst is characterized by two parameters: 331 o burst duration K_d: number of frames in the burst event; and 333 o burst frame size K_B: size of the initial burst frame which is 334 typically significantly larger than average frame size at steady 335 state. 337 It can be noted that these burst parameters can also be used to mimic 338 the insertion of a large on-demand I frame in the presence of severe 339 packet losses. The values of K_d and K_B typically depend on the 340 type of video codec, spatial and temporal resolution of the encoded 341 stream, as well as the video content activity level. 343 5.3. Output rate fluctuation at steady state 345 The output rate R_o during steady state is modelled as randomly 346 fluctuating around the target rate R_v. The output traffic can be 347 characterized as the combination of two random processes denoting the 348 frame interval t and output frame size B over time. These two random 349 processes capture two sources of variations in the encoder output: 351 o Fluctuations in frame interval: the intervals between adjacent 352 frames have been observed to fluctuate around the reference 353 interval of t0 = 1/FPS. Deviations in normalized frame interval 354 DELTA_t = (t-t0)/t0 can be modelled by a zero-mean Laplacian 355 distribution with scaling parameter SCALE_t. The value of SCALE_t 356 dictates the "width" of the Laplacian distribution and therefore 357 the amount of fluctuations in actual frame intervals (t) with 358 respect to the reference frame interval t0. 360 o Fluctuations in frame size: size of the output encoded frames also 361 tend to fluctuate around the reference frame size B0=R_v/8/FPS. 362 Likewise, deviations in the normalized frame size DELTA_B = 363 (B-B0)/B0 can be modelled by a zero-mean Laplacian distribution 364 with scaling parameter SCALE_B. The value of SCALE_B dictates the 365 "width" of this second Laplacian distribution and correspondingly 366 the amount of fluctuations in output frame sizes (B) with respect 367 to the reference target B0. 369 Both values of SCALE_t and SCALE_B can be obtained via parameter 370 fitting from empirical data captured for a given video encoder. 371 Example values are listed in Figure 2 based on empirical data 372 presented in [IETF-Interim]. 374 5.4. Rate range limit imposed by video content 376 The output rate R_o is further clipped within the dynamic range 377 [R_min, R_max], which in reality are dictated by scene and motion 378 complexity of the captured video content. In the proposed 379 statistical model, these parameters are specified by the application. 381 6. A Trace-Driven Model 383 The second approach for modelling a video traffic source is trace- 384 driven. This can be achieved by running an actual live video encoder 385 on a set of chosen raw video sequences and using the encoder's output 386 traces for constructing a synthetic live encoder. With this 387 approach, the recorded video traces naturally exhibit temporal 388 fluctuations around a given target rate request R_v from the 389 congestion control module. 391 The following list summarizes the main steps of this approach: 393 1. Choose one or more representative raw video sequences. 395 2. Encode the sequence(s) using an actual live video encoder. 396 Repeat the process for a number of bitrates. Keep only the 397 sequence of frame sizes for each bitrate. 399 3. Construct a data structure that contains the output of the 400 previous step. The data structure should allow for easy bitrate 401 lookup. 403 4. Upon a target bitrate request R_v from the controller, look up 404 the closest bitrates among those previously stored. Use the 405 frame size sequences stored for those bitrates to approximate the 406 frame sizes to output. 408 5. The output of the synthetic encoder contains "encoded" frames 409 with zeros as contents but with realistic sizes. 411 In the following, Section 6.1 explains the first three steps (1-3), 412 Section 6.2 elaborates on the remaining two steps (4-5). Finally, 413 Section 6.3 briefly discusses the possibility to extend the trace- 414 driven model for supporting time-varying frame rate and/or time- 415 varying frame resolution. 417 6.1. Choosing the video sequence and generating the traces 419 The first step is a careful choice of a set of video sequences that 420 are representative of the target use cases for the video traffic 421 model. For the example use case of interactive video conferencing, 422 it is recommended to choose a low-motion sequence that resembles a 423 "talking head", e.g. from a news broadcast or recording of an actual 424 video conferencing call. 426 The length of the chosen video sequence is a tradeoff. If it is too 427 long, it will be difficult to manage the data structures containing 428 the traces. If it is too short, there will be an obvious periodic 429 pattern in the output frame sizes, leading to biased results when 430 evaluating congestion control performance. In our experience, a 431 sequence with a length between 2 and 4 minutes is a fair tradeoff. 433 Given the chosen raw video sequence, denoted S, one can use a live 434 encoder, e.g. some implementation of [H264] or [HEVC], to produce a 435 set of encoded sequences. As discussed in Section 3, the output 436 bitrate of the live encoder can be achieved by tuning three input 437 parameters: quantization step size, frame rate, and picture 438 resolution. In order to simplify the choice of these parameters for 439 a given target rate, one can typically assume a fixed frame rate 440 (e.g. 30 fps) and a fixed resolution (e.g., 720p) when configuring 441 the live encoder. See Section 6.3 for a discussion on how to relax 442 these assumptions. 444 Following these simplifications, the chosen encoder can be configured 445 to start at a constant target bitrate, then vary the quantization 446 step size (internally via the video encoder rate controller) to meet 447 various externally specified target rates. It can be further assumed 448 the first frame is encoded as an I-frame and the rest are P-frames. 449 For live encoding, the encoder rate control algorithm typically does 450 not use knowledge of frames in the future when encoding a given 451 frame. 453 Given the minimum and maximum bitrates at which the synthetic codec 454 is to operate (denoted as R_min and R_max, see Section 4), the entire 455 range of target bitrates can be divided into n_s + 1 bitrate steps of 456 length l = (R_max - R_min) / n_s. The following simple algorithm is 457 used to encode the raw video sequence. 459 r = R_min 460 while r <= R_max do 461 Traces[r] = encode_sequence(S, r, e) 462 r = r + l 464 The function encode_sequence takes as input parameters, respectively, 465 a raw video sequence (S), a constant target rate (r), and an encoder 466 rate control algorithm (e); it returns a vector with the sizes of 467 frames in the order they were encoded. The output vector is stored 468 in a map structure called Traces, whose keys are bitrates and whose 469 values are vectors of frame sizes. 471 The choice of a value for n_s is important, as it determines the 472 number of vectors of frame sizes stored in the map Traces. The 473 minimum value one can choose for n_s is 1, and the maximum value 474 depends on the amount of memory available for holding the map Traces. 475 A reasonable value for n_s is one that results in steps of length l = 476 200 kbps. The next section will discuss further the choice of the 477 step length l. 479 Finally, note that, as mentioned in previous sections, R_min and 480 R_max may be modified after the initial sequences are encoded. 481 Hence, the algorithm described in the next section also covers the 482 cases when the current target bitrate is less than R_min, or greater 483 than R_max. 485 6.2. Using the traces in the synthetic codec 487 The main idea behind the trace-driven synthetic codec is that it 488 mimics the rate adaptation behavior of a real live codec upon dynamic 489 updates of the target rate R_v by the congestion control module. It 490 does so by switching to a different frame size vector stored in the 491 map Traces when needed. 493 6.2.1. Main algorithm 495 The main algorithm for rate adaptation in the synthetic codec 496 maintains two variables: r_current and t_current. 498 o The variable r_current points to one of the keys of map Traces. 499 Upon a change in the value of R_v, typically because the 500 congestion controller detects that the network conditions have 501 changed, r_current is updated to the greatest key in Traces that 502 is less than or equal to the new value of R_v. It is assumed that 503 the value of R_v is clipped within the range [R_min, R_max]. 505 r_current = r 506 such that 507 ( r in keys(Traces) and 508 r <= R_v and 509 (not(exists) r' in keys(Traces) such that r < r' <= R_v) ) 511 o The variable t_current is an index to the frame size vector stored 512 in Traces[r_current]. It is updated every time a new frame is 513 due. It is assumed that all vectors stored Traces to have the 514 same size, denoted as size_traces. The following equation governs 515 the update of t_current: 517 if t_current < SkipFrames then 518 t_current = t_current + 1 519 else 520 t_current = ((t_current+1-SkipFrames) % (size_traces-SkipFrames)) 521 + SkipFrames 523 where operator % denotes modulo, and SkipFrames is a predefined 524 constant that denotes the number of frames to be skipped at the 525 beginning of frame size vectors after t_current has wrapped around. 526 The point of constant SkipFrames is avoiding the effect of 527 periodically sending a large I-frame followed by several smaller- 528 than-average P-frames. A typical value of SkipFrames is 20, although 529 it could be set to 0 if one is interested in studying the effect of 530 sending I-frames periodically. 532 The initial value of r_current is set to R_min, and the initial value 533 of t_current set to 0. 535 When a new frame is due, its size can be calculated following one of 536 the three cases below: 538 a) R_min <= R_v < Rmax: the output frame size is calculated via 539 linear interpolation of the frame sizes appearing in 540 Traces[r_current] and Traces[r_current + l]. The interpolation is 541 done as follows: 543 size_lo = Traces[r_current][t_current] 544 size_hi = Traces[r_current + l][t_current] 545 distance_lo = ( R_v - r_current ) / l 546 framesize = size_hi * distance_lo + size_lo * (1 - distance_lo) 548 b) R_v < R_min: the output frame size is calculated via scaling with 549 respect to the lowest bitrate R_min, as follows: 551 factor = R_v / R_min 552 framesize = max(1, factor * Traces[R_min][t_current]) 554 c) R_v >= R_max: the output frame size is calculated by scaling with 555 respect to the highest bitrate R_max: 557 factor = R_v / R_max 558 framesize = factor * Traces[R_max][t_current] 560 In case b), we set the minimum output size to 1 byte, since the value 561 of factor can be arbitrarily close to 0. 563 6.2.2. Notes to the main algorithm 565 Note that main algorithm as described above can be further extended 566 to mimic some additional typical behaviors of a live encoder. Two 567 examples are given below: 569 o I-frames on demand: The synthetic codec can be extended to 570 simulate the sending of I-frames on demand, e.g., as a reaction to 571 losses. To implement this extension, the codec's incoming 572 interface (see (a) in Figure 1) is augmented with a new function 573 to request a new I-frame. Upon calling such function, t_current 574 is reset to 0. 576 o Variable step length l between R_min and R_max: In the main 577 algorithm, the step length l is fixed for ease of explanation. 578 However, if the range [R_min, R_max] is very wide, it is also 579 possible to define a set of intermediate encoding rates with 580 variable step length. The rationale behind this modification is 581 that the difference between 400 kbps and 600 kbps as target 582 bitrate is much more significant than the difference between 4400 583 kbps and 4600 kbps. For example, one could define steps of length 584 200 Kbps under 1 Mbps, then steps of length 300 Kbps between 1 585 Mbps and 2 Mbps; 400 Kbps between 2 Mbps and 3 Mbps, and so on. 587 6.3. Varying frame rate and resolution 589 The trace-driven synthetic codec model explained in this section is 590 relatively simple due to fixed frame rate and frame resolution. The 591 model can extended further to accommodate variable frame rate and/or 592 variable spatial resolution. 594 When the encoded picture quality at a given bitrate is low, one can 595 potentially decrease either the frame rate (if the video sequence is 596 currently in low motion) or the spatial resolution in order to 597 improve quality-of-experince (QoE) in the overall encoded video. On 598 the other hand, if target bitrate increases to a point where there is 599 no longer a perceptible improvement in the picture quality of 600 individual frames, then one might afford to increase the spatial 601 resolution or the frame rate (useful if the video is currently in 602 high motion). 604 Many techniques have been proposed to choose over time the best 605 combination of encoder quatization step size, frame rate, and spatial 606 resolution in order to maximize the quality of live video codecs 607 [Ozer2011][Hu2010]. Future work may consider extending the trace- 608 driven codec to accommodate variable frame rate and/or resolution. 610 From the perspective of congestion control, varying the spatial 611 resolution typically requires a new intra-coded frame to be 612 generated, thereby incurring a temporary burst in the output traffic 613 pattern. The impact of frame rate change tends to be more subtle: 614 reducing frame rate from high to low leads to sparsely spaced larger 615 encoded packets instead of many densely spaced smaller packets. Such 616 difference in traffic profiles may still affect the performance of 617 congestion control, especially when outgoing packets are not paced by 618 the media transport module. Investigation of varying frame rate and 619 resolution are left for future work. 621 7. Combining The Two Models 623 It is worthwhile noting that the statistical and trace-driven models 624 each has its own advantages and drawbacks. Both models are fairly 625 simple to implement. It takes significantly greater effort to fit 626 the parameters of a statistical model to actual encoder output data 627 whereas it is straightforward for a trace-driven model to obtain 628 encoded frame size data. On the other hand, once validated, the 629 statistical model is more flexible in mimicking a wide range of 630 encoder/content behaviors by simply varying the correponding 631 parameters in the model. In this regard, a trace-driven model relies 632 -- by definition -- on additional data collection efforts for 633 accommodating new codecs or video contents. 635 In general, the trace-driven model is more realistic for mimicking 636 ongoing, steady-state behavior of a video traffic source whereas the 637 statistical model is more versatile for simulating transient events 638 (e.g., when target rate changes from A to B with temporary bursts 639 during the transition). It is also possible to combine both models 640 into a hybrid approach, using traces during steady-state and 641 statistical model during transients. 643 +---------------+ 644 transient | Generate next | 645 +------>| K_d transient | 646 +-------------+ / | frames | 647 R_v | Compare | / +---------------+ 648 ------->| against |/ 649 | previous | 650 | target rate |\ 651 +-------------+ \ +---------------+ 652 \ | Generate next | 653 +------>| frame from | 654 steady-state | trace | 655 +---------------+ 657 Figure 3: Hybrid approach for modeling video traffic 659 As shown in Figure 3, the video traffic model operates in transient 660 state if the requested target rate R_v is substantially higher than 661 the previous target, or else it operates in steady state. During 662 transient state, a total of K_d frames are generated by the 663 statistical model, resulting in one (1) big burst frame with size K_B 664 followed by K_d-1 smaller frames. When operating at steady-state, 665 the video traffic model simply generates a frame according to the 666 trace-driven model given the target rate, while modulating the frame 667 interval according to the distribution specified by the statistical 668 model. One example criterion for determining whether the traffic 669 model should operate in transient state is whether the rate increase 670 exceeds 10% of previous target rate. Finally, as this model follows 671 transient state behavior dictated by the statistical model, upon a 672 substantial rate change, the model will follow the time-damping 673 mechanism defined in Section 5.1, which is governed by parameter 674 tau_v. 676 8. Implementation Status 678 The statistical model has been implemented as a traffic generator 679 module within the [ns-2] network simulation platform. 681 More recently, the statistical, trace-driven, and hybrid models have 682 been implemented as a stand-alone, platform-independent traffic 683 source module. This can be easily integrated into network simulation 684 platforms such as [ns-2] and [ns-3], as well as testbeds using a real 685 network. The stand-alone traffic source module is available as an 686 open source implementation at [Syncodecs]. 688 9. IANA Considerations 690 There are no IANA impacts in this memo. 692 10. References 694 10.1. Normative References 696 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 697 Requirement Levels", BCP 14, RFC 2119, 698 DOI 10.17487/RFC2119, March 1997, 699 . 701 10.2. Informative References 703 [H264] ITU-T Recommendation H.264, "Advanced video coding for 704 generic audiovisual services", May 2003, 705 . 707 [HEVC] ITU-T Recommendation H.265, "High efficiency video 708 coding", April 2013, 709 . 711 [Hu2010] Hu, H., Ma, Z., and Y. Wang, "Optimization of Spatial, 712 Temporal and Amplitude Resolution for Rate-Constrained 713 Video Coding and Scalable Video Adaptation", in Proc. 19th 714 IEEE International Conference on Image 715 Processing, (ICIP'12), September 2012. 717 [IETF-Interim] 718 Zhu, X., Mena, S., and Z. Sarker, "Update on RMCAT Video 719 Traffic Model: Trace Analysis and Model Update", April 720 2017, . 724 [ns-2] "The Network Simulator - ns-2", 725 . 727 [ns-3] "The Network Simulator - ns-3", . 729 [Ozer2011] 730 Ozer, J., "Video Compression for Flash, Apple Devices and 731 HTML5", ISBN 13:978-0976259503, 2011. 733 [Syncodecs] 734 Mena, S., D'Aronco, S., and X. Zhu, "Syncodecs: Synthetic 735 codecs for evaluation of RMCAT work", 736 . 738 [Tanwir2013] 739 Tanwir, S. and H. Perros, "A Survey of VBR Video Traffic 740 Models", IEEE Communications Surveys and Tutorials, vol. 741 15, no. 5, pp. 1778-1802., October 2013. 743 Authors' Addresses 745 Xiaoqing Zhu 746 Cisco Systems 747 12515 Research Blvd., Building 4 748 Austin, TX 78759 749 USA 751 Email: xiaoqzhu@cisco.com 753 Sergio Mena de la Cruz 754 Cisco Systems 755 EPFL, Quartier de l'Innovation, Batiment E 756 Ecublens, Vaud 1015 757 Switzerland 759 Email: semena@cisco.com 761 Zaheduzzaman Sarker 762 Ericsson AB 763 Luleae, SE 977 53 764 Sweden 766 Phone: +46 10 717 37 43 767 Email: zaheduzzaman.sarker@ericsson.com