32:T413,md` These two properties reveal that chunk size is relative across the different representations. Therefore we can classify the fragments across time into groups based off of chunk size. We can separate them into 4 groups (Q1, Q2, Q3, Q4). Q1 being the smallest and Q4 being the largest chunk size. #### Scene Complexity and Encoding Quality VBR encoding allocates less bits for simple scenes and more bits for complex scenes. However, quality of fragments is not consistent across a representation. While chunk sizes increases from group Q1 to group Q4, the quality decreases. Also there is a large quality gap from Q3 to Q4 despite Q4 having the most bits. The reason for this is that it is difficult to encode complex scenes to have the same quality as simple scenes. Two important characteristics from this: 1. Relative size of chunks (relative to chunks in the same bit rate profile) tell us the scenes complexity 2. Despite complex scenes being encoded with more bits, they have a lower quality compared to other simpler scenes --- `33:T4ad,html`

$K_p$ = the proportional control weight
$K_i$ = the integral control weight
$x_t$ = the current buffer level (second) assuming $t$ is current time in playback
$x_r(t)$ = the buffer level at time $t$ ($r$ is the current bitrate profile)
$d_{\\tau}$ = is the delta of time bewtween each change in buffer levels
$1(x_t - \\Delta)$ = This is an indicator function. If $xt - Δ > 0$ then the expression evaluates to $(xt − Δ)$ else it evaluates to 0

The first term

$K_p(x_r(t) - x_t)$

is calculating the proportional component of the PID control. $(x_r(t) - x_t)$ is the difference of the target buffer level and the current target level. Then, applying the proportional control weight ($K_p$).

The second term

$K_i \\int_0^t(x_r(t) - x_{\\tau})d_{\\tau}$

is the integral component of the PID control. $(x_r(t) - x_{\\tau})$ is the difference of the target buffer level and every buffer level from the start ($t=0$). This is calculating the error and summing each one for their respective duration ($d_{\\tau}$).

`34:T97a,html`

$$Q(l_t) = \\sum_{k=t}^{t+N-1}(u_k\\bar{R_t}(l_t) - \\alpha_t\\hat{C_k})^2 + \\eta_t(r(l_t) - r(l_{t-1}))^2$$

$N$ = Window size
$u_k$ = is the buffer filling rate at some index between $t$ (the current chunk) -> $t + N-1$
$\\bar{R_t}(l_t)$ = is the average bandwidth of the current bitrate profile. We use average bandwdith of the curent window rather than the bitrate of the the chunk at $t$ becuase it'll consider what the near future of fragments will look like in size
$(u_k\\bar{R_t}(l_t))$ = is the required bandwidth
$\\hat{C_k}$ = is the estimated bandwidth
$\\alpha_t$ = is a weight used to inflate or deflate the estimated bandwidth (differential treatment)

$\\alpha_t$ > 1 to inflate bandwidth for complex scenes (1.1 - 1.5)
$\\alpha_t$ < 1 to deflate bandwidth for simple scenes (0.6 - 0.9)
Set $\\alpha_t$ to 1.1 for Q4 chunks and αt to .8 for non-Q4 chunks

The first term

$(u_k\\bar{R_t}(l_t) - \\alpha_t\\hat{C_k})^2$

This term is a penalty on how deviated the required bandwidth is to the estimated bandwidth. Minimizing this penalty term will aim to select the largest bitrate profile.

The second term

$\\eta_t(r(l_t) - r(l_{t-1}))^2$

is a penalty on bitrate profile change. $r(l_t)$ is the average bitrate of bitrate profile $l$. We don't use $R_t(l_t)$ because it represents the bitrate per chunk level. \\eta_t is the weight of the second term. The value can be either 1 or 0.The value is set to 0 when the chunk(segment) at bitrate profile at $t$ ($l_t$) and the previous chunk(segment) at $t-1$ are different in category of chunk size (Q1-Q3 vs Q4). For example, if a chunk at time $t$ is considered to be a Q4 chunk, the largest category of chunk sizes, and the previous chunk at time $t-1$ is considered to be a Q2 category chunk size, even though the bitrate may have changed from 720 at $t-1$ to 1080 at $t$, we don't penalize that because there was a change from a low quadrant chunk size (Q1-Q3) to the largest quadrant (Q4) so that whole term will be set to 0. However if the size difference went from Q2 at t-1 to Q3 at time t and the bitrate changed from 720 to 1080, then we do apply the penalty by setting the weight to 1.

`35:[] 30:{"title":"CAVA explained","cells":[{"id":0,"value":"md`\n# CAVA explained\n---\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":60,"value":"html `\n\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":12,"value":"MathJax = {\n const MathJax = await require('mathjax@2.7.5/MathJax.js?config=TeX-AMS_CHTML')\n .catch(() => window.MathJax)\n \n // configure MathJax\n MathJax.Hub.Config({\n tex2jax: {inlineMath: [['$','$'], ['\\\$','\\\$']]},\n displayMath: [ ['$$','$$'], [\"\\\\[\",\"\\\\]\"] ],\n processEscapes: true\n })\n MathJax.Hub.Typeset()\n return MathJax\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":53,"value":"md`\n### Background
\nThis is an explanation on the properties of VBR(Variable Bitrate) and how the CAVA algorthim design principles addresses those properties for streaming. VBR encodes each segment at a different bitrate, depending on how complex a scene is. Complex scenes are scenes that contain a lot of movement and action which requires more bits to create a similar quality to a simple scene. **Diagram 1** shows an example of an encoded asset at different bitrate profiles. The spiking levels at high bitrates are the complex scenes while the lower bitrate levels are more simple scenes.\n___\n### VBR Video Characteristics\n
\n#### Properties of VBR encoded fragments\n1. Size of chunk(fragment) is relative to scene complexity\n2. Scene complexity at a given point in playback is consistent among different representations(bitrate profiles)\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":79,"value":"html`\n

Diagram 1

\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":94,"value":"$32","pinned":false,"hidden":false,"mode":"ojs"},{"id":118,"value":"md\n`\n### CAVA Design Principles\n
\n#### Be Non-Myopic\n>Considering the bitrate of multiple chunks in the future.\n\n#### Offer Differential Treatmeant\n>This principle favors more complex scenes. Saves resources from simple scenes for complex scenes. Need to achieve a balance of improving the quality of complex scenes while not degrading too much the quality of simple scenes.\n\t\n#### Be Proactive\n>\tConsiders future chunks just like **Non-Myopic** however the difference is that **Non-Myopic** only considers short term future while the **Proactive** principle considers long term chunks. Such as adjusting the dynamic buffer size if its trying to handle future complex chunks.\n\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":132,"value":"md`\n### CAVA Design\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":139,"value":"html`\n

Diagram 2

\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":146,"value":"md\n`\n- Basic feedback control framework\n- Inner Controller reacts to short timescale. It incorporates the **non-myopic** and **differential treatment**\n- Outer Controller reacts over a longer timescale and incorporates the **proactive** principle\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":150,"value":"md\n`\n### Breakdown of the Components\n
\n#### Outer Controller\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":159,"value":"html\n`\n

\n$$x_r(t)=x_r+max({\\\\frac{\\\\sum_{k=t}^{t+W\\'}R_k(\\\\widetilde{l})\\\\Delta-r(\\\\widetilde{l})W\\'\\\\Delta}{r(\\\\widetilde{l})}}, 0)$$\n

\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":188,"value":"html`\n

\n$x_r(t)$ = Target level at time $t$
\n$x_r$ = Base target level
\n$\\\\widetilde{l}$ = reference track (median bitrate profile)
\n$W\\'$ = Outer controller's window size (How many segments to look ahead)
\n$\\\\Delta$ = Chunk duration (segment duration ins seconds)
\n$r(\\\\widetilde{l})$ = the average bitrate of the reference track
\n$R_k(\\\\widetilde{l})$ = the bitrate at time $k$ of the reference track
\n

\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":203,"value":"html`\n

\nThe first term\n

\n$\\\\sum_{k=t}^{t+W\\'}R_k(\\\\widetilde{l})\\\\Delta$\n

\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":207,"value":"html`\n

\nmeans the summation of all the segment's sizes (in bits) in the window size ($W'$). We start the summation at the segment at time $t$ and stop summing at $t + W'$. To get the number of bits of each segment, we take the bitrate of the fragment from the reference track ($\\\\widetilde{l}$) and multiply it by its duration (bits / sec * sec = bits). So the first term should be in unit of size (bits)\n

\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":219,"value":"html`\n

\nThe second term\n

\n
\n

\n$r(\\\\widetilde{l})W\\'\\\\Delta$\n

\n
\n

\nmeans the total estimated size (in bits) of the next number of segments ($W'$) coming up. We take the average bitrate of the reference track ($r(\\\\widetilde{l})$) and then multiply it by our window size ($W'$) and multiply it by the duration of a segment. The second term should be in units of size (bits)\n

\n
\n

\nThe denominator is the average bitrate which of the reference track ($r(\\\\widetilde{l})$)\n

\n
\n

\nIf the returned value of the evaluated equation gives us a time less than 0, we just want to add 0 to the base buffer level. However if it's greater than 0, we want to increase the buffer level meaning that we foresee larger than average segments coming up. Therefore, we will append an additional duration of time to the base buffer level to accommodate for the larger segments coming up\n

\n
\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":232,"value":"md`\n#### PID Feedback Control Block\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":246,"value":"html`\n

\nFirst thing to understand is the relationship\n

\n$$u_t = \\\\frac{C_t}{R_t(l_t)}$$\n

\n$C_t$ = the estimated bandwidth at time $t$
\n$R_t(l_t)$ = the bitrate of the chunk(segment) from the chosen bitrate profile at time $t$
\n$u_t$ = the relative buffer filling rate (unitless)\n

\n
\n

\nThis relationship explains that there is a ratio between the estimated bandwidth($C_t$) and the bitrate of a bitrate profile at a spefcific time, this is called the buffer filling rate. This means that we can estimate what the required bandwidth is at any given time with this relationship ($R_t(l_t) * u_t = C_t$)\n

\n
\n

\nTo figure out what the buffer filling rate is at time $t$, we use this equation\n

\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":236,"value":"html`\n

\n$$u_t = K_p(x_r(t) - x_t) + K_i \\\\int_0^t(x_r(t) - x_{\\\\tau})d_{\\\\tau} + 1(x_t - \\\\Delta)$$\n

\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":259,"value":"$33","pinned":false,"hidden":false,"mode":"ojs"},{"id":274,"value":"md`\n#### Optimizer\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":283,"value":"$34","pinned":false,"hidden":false,"mode":"ojs"},{"id":279,"value":"html`\n\nCAVA\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":319,"value":"md`\n### References\nYanyuan Qin, Shuai Hao, K.R. Pattipati, Feng Qian, Subhabrata Sen, Bing\nWang, and Chaoqun Yue. 2018. ABR Streaming of VBR-encoded Videos:\nCharacterization, Challenges, and Solutions. In The 14th International Conference on emerging Networking EXperiments and Technologies (CoNEXT ’18),\nDecember 4–7, 2018, Heraklion, Greece. ACM, New York, NY, USA, 13 pages.\nhttps://doi.org/10.1145/3281411.3281439\n`","pinned":false,"hidden":false,"mode":"ojs"}],"files":"$W35","stdlib":"1","titling":"auto"}