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.