Direct HLS overview

Introduction

IBM Video Streaming has recently expanded the delivery methods available for both live and VOD streams by introducing Direct HLS streaming. Direct HLS gives you the option to access HLS versions of streaming content without using our player or one of our SDKs. The HLS URL points to an m3u8 playlist, which can be integrated into 3rd party playback components. Here's just a snapshot of what this means you can do with HLS streams:

• Integration of streaming into mobile or Smart TV applications which are already built and capable of playing HLS. Direct HLS allows you to pass IBM Video Streaming content into those apps.
• Source your video content from IBM Video Streaming and integrate with 3rd party streaming and VOD players that accept HLS feeds as input.
• HLS can be delivered via multicast along side implementing an SDK for UMS connection.

Feature overview

The Direct HLS feature allows you to access your IBM Video Streaming streams via a simple HTTP(S) request to a URL, and the HLS playlist is passed back as a response. To enhance the privacy needs of certain content, we've ensured that this new URL is secure through a signature, which is a hash composed with a secret token. This signature is appended automatically when we generate the URL.

The Direct HLS URL follows this pattern:

Live streams:

VODs:

Our system authenticates the viewer after the signature check is passed. This means that features like Geo Lock and Embed Restrict are verified based on the HTTP request's origin IP and Referrer attributes, while Password Lock and Hash Lock are verified based on the optional parameters appended to the URL. The lock parameter values are appended to the end of the URL.

password: value is the actual password, example:

hash: value is the HashLock parameter JSON as documented in the HashLock documentation, example:

Once a client is authenticated, the connection is counted in the viewing metrics. For live streams, we consider the client disconnected if it does not request a new playlist after a 60 second timeout, or the instance is restarted on the server side, or the client is disconnected by a lock change. For VODs, only the initial request is registered.

Note: Performance metrics, including buffering, are not currently reported in the dashboard.

Client sessions are identified for analytics tracking through one of the following methods:

• Cookies: Most modern devices support proper cookie handling. This works based on a server setting an identifier (and an expiration time) in a response header, which is stored by a client and sent back on subsequent requests.
• X-Playback-Session header: If a client does not support cookies or if cookie storing is disabled from user permissions, it may send X-Playback-Session headers in the HTTP requests which contain a unique identifier we can use for identification.
• IP address: Clients can be identified by their IP address combined with the media ID.

How to enable the feature

Currently, this URL is available for our Enterprise level users only. HLS urls can be obtained via API call as explained here .

Possible responses

Here are the possible http response codes that may be returned for an hls request, and their explanations:

Current Limitations

IBM Video Streaming plans continued improvements to this offering, and we're excited to share those with you as they become available. We will modify this list of notes to keep you up to date.

• The signature can be reset, which will invalidate the current signature for existing assets.
• The current trim tool feature does not support Direct HLS VODs, so any trims made will not be reflected in the HLS version of the VOD.
• Individual viewer tracking is not supported through M3u8 URLs.