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