HTTP Live Streaming issue (HLS) with 10.2 OS update

by Retired on ‎10-29-2013 04:31 PM (2,834 Views)

Symptoms

With the BlackBerry 10.2 OS update, your application's media streaming might fail altogether or run with poor resolution (for videos).

Diagnosis

This problem will affect your application if it meets the following three conditions:

Conditions

1. Your app uses the HTTP Live Streaming (HLS) protocol for streaming media; AND
2. The URL being played contains
 .m3u or .m3u8, representing the HLS playlist; AND

3. Your app uses the Cascades MediaPlayer class or invokes the MediaPlayer card app through the invocation framework.


--------------------------------------------

The problem stems from a playlist handling bug with the Cascades MediaPlayer API in the 10.2 OS update. It fails to identify the HLS stream correctly and the playback might not happen altogether or run with lower resolution. As per the HLS protocol, depending on the bandwidth availaible, the resolution of the output is supposed to increase or decrease, dynamically. However, due to this issue, if the playback does happen, the resolution switching won't be happening as expected.

 

It might be difficult to notice the absence of this resolution switching. Here are some tips to help with detecting the resolution drop:

a) Compare the playback (if possible, even side by side) of the app in 10.2 with that in 10.1
b) Display the output on a bigger screen (e.g. through HDMI output)
c) Ensure a fast enough internet connection to allow the jump in resolution for HLS

 

--------------------------------------------

Details for the different cases of HLS streams and how they might be affected:


--------------------------------------------

Case 1 - Master playlist (multi-variants):
For HLS streams with master playlist (a large percentage of the cases out there) the platform will play the first item of the master playlist. This happens to be the first BW (bandwidth) variant of HLS. Therefore, the stream will play but it will be stuck on that BW. For live presentation it will play "forever". For VOD (video on demand) it may restart the play from the beginning for the next variant as soon as the current presentation ends.

 

Case 2 - Single-variant playlist VOD:
If the playlist is a single variant, it will it will be played as a gapless stream: will have audio with A/V sync issues and with frames freezing for a while.

 

Case 3 - Single-variant playlist live:
It will be played like case 2 but only for a couple seconds (size of the live windows usually 40~60 seconds).

 

Case 4 - Single-variant playlist with encrypted media:
It will fail for either live or VOD.

 

Case 5 - Servers implementing security using either cookies or keys embedded in URL's (e.g. Akamai):
It may not work at all, even for case 1.

Solution

You may choose to use one of the two solutions here:

Solution 1

This is the easier workaroud.

If the server from which the stream is being served safely ignores dummy parameters (most servers do), append an extra parameter-value pair that contains a dot, e.g., “dummy=a.bbb”.  This exploits a weakness in the playlist parser.

 

Example:

If the original URL already contains a “?” and parameter, http://mydomain.com/myhlsmaster.m3u8?key=1abc42ed12430a98
Then your new URL would be:
http://mydomain.com/myhlsmaster.m3u8?key=1abc42ed12430a98&dummy=a.bbb

If the original URL contains no parameters then simply append something like “?dummy=a.bbb” to form your new URL.


Solution 2

Do not pass URLs that contain .m3u or .m3u8 to the Cascades MediaPlayer. You can utilize a URL shortening service to get a redirect URL (through an extra HTTP request) to eliminate the .m3u or .m3u8 from your original URL.