# Keyframe Insertion: Enabling Low-Latency Random Access and Packet Loss Repair
## 4 Results
### Impact on Frame Size  
Table 1 shows the factor of frame size increase, i.e., the factor with which the size of the inserted keyframe is larger than the inter-frame of NS\({}_{\text{Src}}\) that it replaces. The results in the table are averaged over all sequences, for both KI\({}_{\text{Src}}\) and KI\({}_{\text{NS}}\), for all QP\({}_{\text{NS}}\), and for all QP\({}_{\text{CS}}\). When QP\({}_{\text{NS}}\
eq\) QP\({}_{\text{CS}}\), the results are shown in gray rather than black, as these may be less relevant in our application. Furthermore, note that the frame size increase depends on the used encoder configurations.  
In absolute value, it can be observed that the inserted keyframes are between 2.0 and 149.4 times larger than the inter-frames that they replace. At equal QPs (QP\({}_{\text{NS}}=QP_{\text{CS}}\)), the keyframes are between 7.4 and 29.2 times larger than their predicted counterparts. This gives a good indication about the bitrate burst that can be expected when such a companion stream keyframe is additionally requested over a network.  
When comparing the frame size increases from KI\({}_{\text{Src}}\) and KI\({}_{\text{NS}}\), one can observe that KI\({}_{\text{NS}}\) has a smaller size increase. That is because KI\({}_{\text{NS}}\) uses NS\({}_{\text{Src}}\) as input, which has already been encoded and which thus contains less high-frequency noise. In other words, previously encoded content takes less bitrate to compress at equal QP settings.  
Furthermore, a higher QP\({}_{\text{NS}}\) value (with an equal QP\({}_{\text{CS}}\) value) generally results in a larger size increase. This is because the ratio between intra- and inter-frames is larger in those cases, i.e., the overhead from intra-frames is larger for encodes with lower qualities. Last, when using a constant QP\({}_{\text{NS}}\) value, a higher QP\({}_{\text{CS}}\) value results in a lower bitrate increase, which is expected behavior.  
When looking at the frame size increase, note that keyframe insertion typically occurs infrequently. That is, a single (relatively large) keyframe is inserted only when packet loss  
\begin{table}
\begin{tabular}{l r r r r r r r r} \hline  & & & \multicolumn{6}{c}{**Average Factor of Frame Size Increase**} \\ \multicolumn{1}{c}{\(\mathbf{QP_{CS}}\)} & \multicolumn{6}{c}{**KI\({}_{\text{src}}\)**} & \multicolumn{6}{c}{**KI\({}_{\text{NS}}\)**} \\ \hline  & \(\mathbf{QP_{NS}}\) = & **22** & **27** & **32** & **37** & **22** & **27** & **32** & **37** \\ \hline
22 & & 8.6 & 27.4 & 68.2 & 149.4 & **7.4** & 19.6 & 40.8 & 75.6 \\
27 & & 5.3 & **16.1** & 39.8 & 86.4 & 4.9 & **13.9** & 28.9 & 51.3 \\
32 & & 3.3 & 9.7 & **23.6** & 50.7 & 3.2 & 8.9 & **20.2** & 35.9 \\
37 & & 2.0 & 5.8 & 13.8 & **29.2** & 2.0 & 5.5 & 12.2 & **24.1** \\ \hline \end{tabular}
\end{table}
Table 1: Average factor with which size of inserted keyframe increases compared to the inter-frame that it replaces.  
or channel switching occurs. In all other cases, no bitrate overhead occurs. Furthermore, note that alternative solutions either have a high latency or a higher bitrate overhead. First, one can wait for the next keyframe to resume playback, which may be a very long time (e.g., up to 600 frames). Not only does this have a high latency, it also wastes bandwidth potential during the waiting period. Second, an alternative solution for fast channel switching is to request the keyframe from the current segment at the new channel (from the normal stream), as well as all inter-frames up until the current frame. Then, these are all decoded and optionally displayed on-screen with a fast playback speed. This results in a high latency and requires more bandwidth than the proposed keyframe insertion (which requests only a single keyframe to start playback of the current frame at the new channel).