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
 
CHANNELS     HFR    |  Mobile Fronthaul Solution  |  Carrier Ethernet Solution  | Resources        
CHANNELS     ZARAM    |  TWDM-PON SFP+ ONU  |  XGSPON 10G SFP+ ONT  |  Use cases  | Evolution of FTTH Access Network    

 

Analysis on Streaming Technology of LG U+ Mobile HDTV (LG U+ HDTV Service based on LTE-A)
August 19, 2013 | By Ricky Yang and Dr. Harrison J. Son (tech@netmanias.com)
Online viewer:
Comments (0)
17

On June 10, 2013, LG U+ launched U+ HDTV multi-channel service (U+ tv G 4 Channel Service) that enables users to watch 4 channels at the same time through home STB. Later in July, it introduced the same multi-channel service in a mobile version based on LTE-A. In this post, we will analyze the U+ HDTV streaming on mobile devices that support LTE-A. 

 

U+ HDTV service offers two viewing experiences: 4-channel multiview and full view modes as seen below. In the multiview mode, users can instantly choose 4 different channels and watch them all at the same time (What a personalization!). In both modes, the video quality and viewing experiences were quite satisfying.  

 

During our actual measurement, we checked and analyzed the video streaming in the two modes (test environment: LG U+ LTE-A service, LG U+ HDTV service and Galaxy S4 LTE-A).  

  

                          4-channel multiview (split screen)                                     Full view

 

In both modes, HTTP Live Streaming (HLS), Apple’s Adaptive Bit Rate (ABR) streaming protocol, was used. Chunk duration was six seconds long and Codec was H.264.

 

Analysis of the Playlist File

 

In the downloaded playlist (manifest) file, we found each channel had 3 video quality levels (profiles). The profile with BANDWIDTH=1,500,000 had the highest quality, and the one with BANDWIDTH=500,000 had the lowest quality. According to our actual measurement, the profile with BANDWIDTH=1,500,000 had an encoding rate of about 2.5 Mbps, not 1.5 Mbps, and the one with BANDWIDTH=500,000 had an encoding rate of about 560 Kbps.

 

As seen in the figure below, the duration of each chunk in the 3 profiles (only 2 profiles are displayed in the figure, though) was set as 6 seconds.

 

In the full view mode, 1-channel streaming (consisting of chunks) with 1,500,000 profile (50101H.M3U8), which has the highest quality, was requested and downloaded. And in 4-channel split view mode, 4-channel streaming with 500,000 profile (50103H.M3U8) was received and played back. 

 

 

 Analysis of the Patterns of Chunk Request and Download 

 

The figure below illustrates how chunks are requested and downloaded as captured by Wireshark in case of a full view mode. 

  • Initial Buffering State:  The device made a back-to-back request for the first 3 chunks (3 requests in a row) and filled the receiving buffer with the downloaded chunks immediately. 
  • Steady State:  Thereafter, it made a request for a chunk every 6 seconds and had the chunk downloaded. 

This back-to-back request (for the first 3~4 chunks) is the same method as the typical Internet video delivery method used by OTTs who do not have their own network and therefore QoS supports from the network layer are not available.  

 

One thing interesting was that, even LG U+, apparently with its own network, did not seem to apply network layer QoS to its own contents delivered. In that no DiffServ marking was found in the IP packets received from the device, we can infer that the packets were treated as BE in the LTE layer. It seems LG U+ concluded since LTE -A bandwidth was broad enough, 2.5 Mbps can be easily handled as BE with no buffering. And probably it was LG U+'s policies to proactively prevent possible quality degradation through switching to adaptive streaming - which automatically downgrades the quality of the video into one with lower encoding rates - when a user moves to a shadowing area and thus LTE-A throughput performance is deteriorated (As to be mentioned below, no actual adaptive streaming has been observed during our several measurements. However, from the fact that there are 3 profiles defined in the playlist file, we can infer adaptive streaming has been adopted).

  

As may be seen from the figure below, the video chunk size was about 1.6+ MB ( = the number of bytes in the chunk captured - the number of bytes in the overhead (e.g. IP, TCP), i.e. the number of bytes in the video file), and the video encoding rate was around 2.3~2.5 Mbps (~2.5+ Mbps, the average packet download rate captured - the overhead as mentioned above).  

 

Patterns of chunk request and download in the full view mode (Galaxy S4, LTE-A and LG U+)

 

In the split view mode, each channel has the same patterns of chunk request and download as in the full view mode.

  

Analysis of the Chunk File

 

The figure below shows the actual chunk files downloaded in a full view mode, as analyzed by MediaInfo. 

 

Video and audio data were delivered as one file (50101.ts). The chunk size was about 1.6+ MB and chunk duration was 6 seconds (to be exact, 5.983 seconds). The encoding rate, codec and resolution applied in the chunk were 2.233 Mbps, H.264 and 720x404, respectively.

 

 

Adaptive Streaming (Automatic Bit Rate Switching)

 

In the playlist (manifest) file, 3 profiles are defined. Among them, the one with highest quality was used in the full view mode, and the one with the lowest quality was used in the split view mode. One with the intermediate quality has not been detected during our actual measurement.

 

We believed a profile with intermediate quality was intended for adaptive streaming to be applied when the network gets congested while a user was watching in a full view mode. So, we tried several more locations to detect this profile, but failed, probably because the LTE-A throughput has to be below 1 Mbps for this profile to be used. Conducting measurements over a wider area will increase the chances of detecting bit rate switching. 

 

 

 

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (823)
4.5G (1) 5G (89) AI (6) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) Big Data (2) Blockchain (3) C-RAN/Fronthaul (17) CDN (4) CPRI (4) Carrier Ethernet (3) 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 (55) KT (43) Korea (19) 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 (3) MPLS (2) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (21) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) QoS (3) RCS (4) 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.
Password