This post will analyze the streaming methods used in YouTube's Live TV streaming services for mobile devices in an LTE network and a Wi-Fi network based on our actual measurements.

 

YouTube's Live TV Streaming in Mobile Devices: HLS & Adaptive 
 

First, measurements in an LTE network

 

The mobile device and network used for our measurement were Galaxy S4 and KT LTE network. First, after accessing YouTube using a YouTube APP, we captured the actual HTTP traffic while watching the SPOTV Live channel. The figure below is an illustration showing how a content was requested and delivered while we were watching the SPOTV Live channel. YouTube uses Apple's HLS (HTTP Live Streaming) to provide its Live TV streaming services. The chunk duration and codec were 5 seconds and H.264 respectively.

 

 

1. The user runs a YouTube APP on his mobile device and clicks SPOTV Live. 

 

2. The device sends a message requesting a Variant Playlist file to the YouTube server to obtain a Variant Playlist file for the SPOTV Live channel. 

 

3. The YouTube server sends the device a Variant Playlist file, which contains the video quality information (bandwidths, resolutions, etc.) for the SPOTV Live channel. The SPOTV Live channel provides six different profiles (64 Kbps (128x72) ~ 2.8 Mbps (1280x720)), and the video quality levels are identified by the itag values of each profile.   

 

4. The device selects the profile with the lowest video quality (itag=151, 64 Kbps, 128x72) in the Variant Playlist file, and then sends a message requesting a Playlist file for the selected profile to the YouTube server. 

 

5. The YouTube server sends the device the Playlist file for the selected profile, which contains the information about the chunk files required for video playback (duration, sequences, URLs of each chunk file, etc.).

 

6. The device selects the first chunk file (#74753) with the lowest video quality in the list, then it requests the YouTube server for the file (Note: It is assumed that the chunk file with the lowest video quality is not requested for playback, but for quality check between the device and YouTube server.).

 

7. The YouTube server sends the device the first chunk file (#74753) with the lowest video quality as requested.

 

 8. The device automatically selects the highest playable video quality considering its current connection condition, and sends the YouTube server a message requesting a Playlist file for the selected video quality (In our actual test, the video quality with the highest bit rate was selected).

 

9. The YouTube server sends the device the Playlist file for the selected video quality, which contains the information about the chunk files required for video playback (duration, sequences, URLs of each chunk file, etc.).

 

10.  The device requests the YouTube server for the first chunk file (#74753) for playback (In the figure, the device requested the chunk file which has the same sequence as in the chunk file that was requested for quality check between the device and YouTuber server.).

 

11. The YouTube server delivers the requested chunk file, and the device begins playing the chunk received.

 

12-17. The device requests and receives three chunks in a row (#74754, #74755, #74756). 

 

The device buffers multiple chunks at once by going through the initial buffering procedures (steps 10 ~ 17 above). 

 

18. Then, the device momentarily pauses requesting chunks for about 5~8 seconds.

 

19. The device resumes requesting a Playlist file for next chunks (if the network condition is changed and thus chunks in different quality are needed, the device requests a Playlist file for the desired video quality).

 

20. The YouTube server returns the Playlist file for the selected video quality to the device. 

 

21-22. The device requests and receives the next chunk (#74757). 

 

Now, the steps 18 ~ 22 are repeated until the user finishes watching. 

 

After the initial buffering procedures (steps 10 ~17), the device stays in Steady State, requesting only the minimum number of chunks required for uninterrupted play, unless there is a significant change in its condition. This type of chunk request will be repeated until the user stops playing the video or the entire video is played.   

 During our test in the LTE network, the entire video has been played at a steady 2.8 Mbps and no automatic switching between video quality levels was detected (unfortunately, thanks to sufficient bandwidth in the LTE network). 

 

To check whether bit rate switching is supported or not, we accessed a Wi-Fi network, which has poor bandwidth conditions compared to LTE, and performed the same test again. Immediately upon accessing the Wi-Fi network using the same device (Galaxy S4), we could finally observe bit rate switching.  

 

 

As can be seen in the figure above, at first, the device requested a chunk file with 64 Kbps bit rate (itag 151), but later on it requested the ones with different bit rates, e.g. 2.8Mbps (itag 95), 758Kbps (itag 93), 1.47Mbps (itag 94), and so on. 

 

In generic ABR (Adaptive Bit Rate) streaming, a device requests a chunk file with the lowest video quality at first, and plays the file. Afterwards, while playing the file, it requests the next chunk file with a slightly higher quality level, looking for the best suitable video quality considering the device and network conditions. However, it was different in ABR streaming provided by YouTube's Live TV. As seen in our two tests in the LTE and Wi-Fi network, once the device finds the network condition to be good, it requests a chunk file with the highest video quality from the beginning, instead of selecting the lowest level and gradually upgrading the level. 

 

It was unfortunate we couldn't detect bit rate switching in the LTE network. However, at least we could confirm bit rate switching was supported in YouTube Live TV services through our test in the Wi-Fi network.