Netmanias Analysis

 

Report
Tech-Blog
One-Shot Gallery
 

 

Korean Operators

 

Korea ICT Statistics

 
Overview
Mobile
Broadband
IPTV

 

Korea ICT Innovation

 

Mobile
IPTV
Broadband
 

 

Korea ICT News

 

Korea ICT News

 

 

Korea ICT Vendors & Solutions

 

  Access/Aggregation    Optical Transport    SDN    Wi-Fi

  L3/L2 Switch, PON

 

  Dasan Networks
  HFR
  Tellion
  ubiQuoss

 

 

 WDM, ROADM, PTN

 

 Coweaver
 
HFR
 Telefield

 

 SDN Controller/Switch

 

 Kulcloud
 NAIMnetworks
 Piolink

 

 

 AP, Controller

 

 Davolink
 Dasan Networks
 Samsung

  Content Delivery    RAN    Small Cell    IoT

  CDN, TIC

 

  Ara Networks
  CDNetworks
  Solbox

 

 Base Station, DAS, RRH

 

 HFR
 Innowireless

 KMW
 
Samsung
 SOLiD

 

 Small Cell, Gateway

 

 Juni

 Contella

 Qucell

 

 

 

 IoT Platform, Gateway

 

 MODACOM

 

Korea Communication Review 
Magazine

     

       What happens...in Korea ?

      

 

Current Issue
Q3 2015

Want to be a sponsor for Netmanias? (see Annual sponsorship benefits)
NETMANIAS TECH-BLOG
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:
  
  
  
 

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 04/16/2015 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.
Password confirmation
Please enter your registered comment password.
Password 
Related Contents
YouTube, changing the way of delivering videos: Chunking and Adaptive Streaming are In, Progressive Download is Out!
Date: 10/04/2013, Netmanias Tech-Blog
Tags: Google, HTTP Adaptive Streaming, Progressive Download, YouTube
Topic: Content Delivery
8,686
 1
Analysis of YouTube Video Delivery (360p, 720p)
Date: 12/04/2012, Netmanias Technical Documents
Tags: Progressive Download, YouTube, Google
Topic: Content Delivery
5,008
 0
Google Global Cache (GGC) Operations for YouTube (2): LG U+ Case (with GGC)
Date: 04/18/2012, Netmanias Tech-Blog
Tags: Google, Google Global Cache, KT, LG U+, YouTube
Topic: Content Delivery, Korea ICT
12,667
 1
Google Global Cache (GGC) Operations for YouTube (1): KT Case (Without GGC)
Date: 04/16/2012, Netmanias Tech-Blog
Tags: Google, Google Global Cache, KT, LG U+, YouTube
Topic: Content Delivery, Korea ICT
12,360
 2
Download PDF file
Like This
23
Share This
Statistics
Date
10/30/2013
Pages
6
Views
15,757
Downloads
131
Comments
1
View All (309)
4K (3) 5G (10) 802.1X (1) AP (1) AP controller (1) ARP (3) Akamai (1) Antenna (1) Authentication (2) Backhaul (1) Big Data (1) Bridging (2) C-RAN (8) CDN (1) CPRI (4) CSI (1) Cache (1) Captive Portal (1) Carrier Ethernet (3) CoMP (5) Contela (1) Control Plane (4) DHCP (5) Data Plane (4) EPS Bearer (3) FTTH (6) Fronthaul (8) GTP (2) GUTI (1) GiGAtopia (2) Giga Internet (2) Gigabit Internet (2) Google (6) Google Global Cache (3) HFR (1) HLS (5) HTTP Adaptive Streaming (5) ICIC (1) IMSI (1) IP Routing (4) IPTV (5) ITV (1) Indentifier (1) Interference Coordination (1) IoT (3) KT (22) Korea (25) L3 Switch (4) LG U+ (15) LTE (25) LTE-A (14) LTE-H (2) LTE-U (4) LTE-Unlicensed (1) MEF (2) MWC 2015 (3) Netflix (1) OSPF (2) OTT (3) On-Net CDN (1) Progressive Download (1) QoS (3) RRA (1) RRH (1) Radio Bank (1) Routing (3) SDF (3) SK Broadband (2) SK Telecom (15) Security (2) Small Cell (1) Switching (2) Tracking Area (1) UHD (4) VLAN (1) Video Streaming (2) Wi-Fi (6) YouTube (6) eICIC (1) vRAN (1)
LTE Subscribers Growth in Korea