Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
Real World Private 5G Cases   4 Deployment Models On-Premise Cases 5G Core Control Plane Sharing Cases

5G Core Sharing Cases

Private 5G Deployment   • Private 5G Frequency Allocation Status in Korea  South Korean government's regulations on private 5G and KT's strategy for entering the market
Cases in Korea   Private 5G Operators |   SK Networks Service (SI) Sejong Telecom (Wire-line Carrier) KT MOS (Affiliate of KT) • Newgens (SI) • NAVER Cloud more >>  
    Enterprise DIY |   Korea Hydro & Nuclear Power (Power Plant) Korea Electric Power Corporation (Energy) • Republic of Korea Navy more >>
CHANNELS     HFR Private 5G Solution (my5G)       my5G Solution Components       my5G Key Features        my5G Resources        my5G News          
YouTube's Live TV Streaming in Mobile Devices - HLS & Adaptive
October 30, 2013 | By Ricky Yang and Dr. Harrison J. Son (tech@netmanias.com)
Online viewer:
Comments (1)

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. 



Engaom 2015-04-16 05:17:44

Would you please share the wireshark filter used to analyze this data, thanks

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.

[HFR Private 5G: my5G]


Details >>







Subscribe FREE >>

Currently, 55,000+ subscribed to Netmanias.

  • You can get Netmanias Newsletter

  • You can view all netmanias' contents

  • You can download all netmanias'

    contents in pdf file







View All (858)
4.5G (1) 5G (102) AI (8) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) BSS (1) Big Data (2) Billing (1) Blockchain (3) C-RAN/Fronthaul (18) CDN (4) CPRI (4) Carrier Ethernet (3) Charging (1) China (1) China Mobile (2) Cisco (1) Cloud (5) CoMP (6) Connected Car (4) DHCP (5) EDGE (1) Edge Computing (1) Ericsson (2) FTTH (6) GSLB (1) GiGAtopia (2) Gigabit Internet (19) Google (7) Google Global Cache (3) HLS (5) HSDPA (2) HTTP Adaptive Streaming (5) Handover (1) Huawei (1) IEEE 802.1 (1) IP Routing (7) IPTV (21) IoST (3) IoT (56) KT (43) Korea (20) Korea ICT Market (1) Korea ICT Service (13) Korea ICT Vendor (1) LG U+ (18) LSC (1) LTE (78) LTE-A (16) LTE-B (1) LTE-H (2) LTE-M (3) LTE-U (4) LoRa (7) MEC (4) MPLS (2) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (21) Network Slice (1) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) Private 5G (11) QoS (3) RCS (4) Railway (1) Roaming (1) SD-WAN (17) SDN/NFV (71) SIM (1) SK Broadband (2) SK Telecom (35) Samsung (5) Security (16) Self-Driving (1) Small Cell (2) Spectrum Sharing (2) Switching (6) TAU (2) UHD (5) VR (2) Video Streaming (12) VoLTE (8) VoWiFi (2) Wi-Fi (31) YouTube (6) blockchain (1) eICIC (1) eMBMS (1) iBeacon (1) security (1) telecoin (1) uCPE (2)
Password confirmation
Please enter your registered comment password.