February 26, 2015

Comparing streams performance via In-depth statistics

In-depth statistics being part of WMSPanel reporting framework or Deep stats, is very popular as it gives full overview of a customer's content performance. Each VOD file or live stream has full set of daily statistics.

In addition to browsing selected streams' and groups' data, you may also compare their performance, i.e. compare metrics for streams and groups for the same period of time.

You may go to Deep stats report and start a search with any regular expression you need. Getting the result, you will see list of items which you may select by clicking on check boxes. 

Searching for VOD files stats.

In-depth statistics grouping of files and streams

WMSPanel reporting framework has several features which cover basically everything an average streamer needs to know more about his audience and streaming infrastructure performance.

In-depth statistics, or Deep stats, became very popular from the moment of introduction. This report gives full overview of a customer's content performance. Each VOD file or live stream has full set of daily statistics for each day within stats storage time. WMSPanel also provides the API for accessing available data for further interpretation within third-party analysis tools.

As a lot of content is available via adaptive bitrate - e.g. SMIL file for VOD or ABR streams for live HLS - there needs to be a way of combining stats for similar streams to make further analysis. This is why we introduce Deep stats groups.

Making groups of results allows:

  • save popular searches for further re-use;
  • browse combined statistics of each group as if it would be a single entity;
  • using in comparisons.

When a user runs a search in Deep stats for some criterion, the system gives a list of results. Each result may be selected and to create a group. Just select items and click on "Make group".

Searching for files and streams by regexp.

MP4 tracks support for HLS and MPEG-DASH VOD

Nimble Streamer has a rich HLS VOD and MPEG-DASH VOD feature sets which allows streaming HLS and DASH from media files of various formats. When streaming VOD from MP4, you may need to specify an exact video and/or audio track to use for playback. This is very useful for several cases, e.g. when a user wants to get content for his or her native language.

So Nimble Streamer now supports tracks selection for HLS and DASH VOD playback. The default parameters name for accessing tracks are "nimble_video_index" and "nimble_audio_index".
E.g. you may call different tracks like that:

http://127.0.0.1:8081/vod/multilang_sample.mp4/playlist.m3u8?nimble_audio_index=2
http://127.0.0.1:8081/vod/multilang_sample.mp4/manifest.mpd?nimble_video_index=1


If you need to use other parameters' name, please you may change them via Nimble configuration file. These parameters are set like this:
nimble_video_index = <name for video>
nimble_audio_index = <name for audio>
E.g.
nimble_audio_index = audioIndex
In case of changes, your URL will look like this:

  • http://127.0.0.1:8081/vod/multilang_sample.mp4/playlist.m3u8?audioIndex=2
  • http://127.0.0.1:8081/vod/multilang_sample.mp4/manifest.mpd?audioIndex=2

Please read Nimble Streamer configuration file description to see how you can make changes and what other config parameters may be useful for you. The VOD caching parameters might be extremely helpful for any VOD streamer.

If you use SMIL files for creating ABR HLS VOD streams, please read this article to learn about using tracks indices there. To see tracks selection example for MPEG-DASH VOD ABR, read this article.

Also check audio-only and video-only transmuxing via SMIL.

If you have further questions about this or any other feature, just let us know.

Related documentation



February 25, 2015

Using WMSAuth paywall with CloudFlare and other proxies

WMSPanel provides wide paywall feature set which provides hotlink protection, pay-per-view framework and geo-location block. Hotlink protection is an extremely popular feature set for both Wowza and Nimble Streamer.

Hotlink protection is based on combination of viewer's IP address and a password defined via WMSPanel. So when our customer is using any proxy between the streaming server and a viewer, this may cause the block of connections because the IP of a user is not matching the actual IP. A popular example of such inconsistency is when our customer is using CloudFlare, a cloud-based protection solution against DDoS attacks.

To make it work properly, you may use the real address of a viewer which is passed among other headers to a web server. E.g. in PHP these headers may be accessed via $_SERVER system variable.

CloudFlare is passing HTTP_CF_CONNECTING_IP variable. If some other proxy is used, then a HTTP_X_FORWARDED_FOR may be used. X-Forwarded-For header may also be used by CloudFlare so check your $_SERVER variable output to see if this code may be simplified in your case.

However even those headers may be incorrect. That's why HTTP_X_REAL_IP and HTTP_CLIENT_IP headers may be used in addition.

Generally, the example below shows how this can be used:


$ip = $_SERVER['REMOTE_ADDR'];
if (!empty($_SERVER["HTTP_CF_CONNECTING_IP"])) {
$ip = $_SERVER['HTTP_CF_CONNECTING_IP'];
} elseif (!empty($_SERVER['HTTP_X_REAL_IP'])) {
$ip = $_SERVER['HTTP_X_REAL_IP'];
} elseif (!empty($_SERVER['HTTP_CLIENT_IP'])) {
$ip = $_SERVER['HTTP_CLIENT_IP'];
} elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) {
$ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$commapos = strrpos($ip, ',');
$ip = trim( substr($ip, $commapos ? $commapos + 1 : 0) );
}

Complete hotlink protection signature source code with JWPlayer used for playback, can be found in our github page.

If your Nimble Streamer instance is also located behind the proxy or reverse proxy, you should also use cdn_origin configuration parameter to make Nimble work fine with it. Check this article for details.

You may also find useful the detailed information about our paywall solutions. And if you need help debugging WMSPanel-based paywall, please check our FAQ.

Also please check HLS AES-128 DRM encryption implemented in Nimble Streamer.

Related documentation


WMSPanel paywallWMSPanel github page, MPEG_DASH hotlinking protectionHLS AES-128 DRM encryption

February 15, 2015

Nimble Streamer for Windows is here

Nimble Streamer was initially designed as a high-efficient server software. As Linux is the most used platform for web, we initially started our development with Linux releases, having other platforms in mind.

Today we've done the next step forward. We're introducing Windows release of Nimble Streamer. It's the same excellent Nimble software which is already used for Linux servers worldwide, but now you may also try it on your Windows desktop as well on Windows server.

Try this release now via easy-to-use installer: https://wmspanel.com/nimble/install#os_windows

Basic steps include WMSPanel registration (if you haven't yet done it), installation via setup wizard and server registration. Having Nimble Streamer installed you may setup all the streaming scenarios which we have a lot in our features package.

Feel free to share your Windows usage experience of Nimble, we're opened for any feedback.

Related documentation


February 12, 2015

HLS AES encryption support for DRM in Nimble Streamer

Nimble Streamer supports variety of features for HLS, including big feature set for live streaming. In order for HLS to support secure streaming, the initial HLS RFC has a description of protection mechanism based on AES-128 encryption. This allows covering Digital Right Management (DRM) use cases.

Nimble Streamer has now encryption support. It allows encrypting chunks using DRM key specified by server admin. It supports the following key scenarios

  1. Nimble hosts the key URL and uses it for giving out the key.
  2. External key URL is used for the cases when a customer needs additional authentication for a key.

Let's review each scenario separately. We assume that your system administrator has already installed and set up Nimble Streamer and it has streams ready to be protected by DRM.

Note, that Nimble Streamer encrypts only self-produced HLS streams, those can be VOD streams or transmuxed Live streams. Therefore, HLS encryption can't be applied to re-streaming scenarios.

1. Using encryption key hosted by Nimble


In this scenario the DRM AES-128 encryption key is provided by Nimble itself. Let's go step by step to see how it is set up and used.

The whole scenario is shown on the following sequence diagram.
AES DRM encryption workflow with Nimble Streamer hosting the DRM key.

February 10, 2015

HLS, DASH and Icecast streaming load balancing

Nimble Streamer is used for reliable delivery of media streams. It is robust and has low resources usage so even a single server instance may handle several gigabits per second without any problems.

However, there are cases when you need several servers working as a single network:

  • Preventing hardware and network failures - if one server becomes inaccessible, other instances must take its load.
  • Handling amount of connections which is too big for single instance.
  • Handling significant bandwidth which is higher than single server throughput.
  • Geographical balancing to deliver content from the location nearest to the viewer.

For HTTP-based protocols like HLS, DASH, Icecast, Smooth etc. there are several balancing techniques, like HTTP 302 status redirection or DNS failover, but none of them are reliable. There are several reasons. Several HLS players do not handle redirection headers correctly. The same applies to DNS failover where an average player cannot guarantee that some chunks won't be obtained from different edges, breaking the sessions information. This is crucial for getting the audience metrics hence unacceptable for streaming systems. Production-grade networks cannot rely on such inconsistencies.

At the moment the only reliable way of balancing the connections is to manually give a link to the exact edge server at the location where a player takes the URL of the stream. This needs additional business logic on a server side but it gives a proper flexibility which is not achievable by other techniques.

Let's see how you can make a balancing for a network of Nimble Streamer instances. The following picture shows possible general workflow.


February 4, 2015

Icecast metadata passthrough support

Nimble Streamer has a decent set of audio streaming features. Most popular ones are transmuxing from various protocols to HLS, including audio-only HLS, streaming Icecast from RTMP and other protocols and Icecast re-streaming.

Icecast re-streaming is a popular scenario as Nimble allows handling multiple simultaneous connections to get the most from server throughput along with calculating various statistics.


To be fully compliant with all Icecast capabilities and allow users to see full information on the music being performed, Nimble supports Icecast metadata tags. If the original stream has meta information, then Nimble will add it into its stream.

Showing Icecast metadata in VLC.
Common tags include artist, title, channel name etc. so now your favorite player can show that info.

You can also append any metadata to outgoing stream. Read this article for details.

Besides Icecast re-streaming, you may use the Icecast/SHOUTcast streams as an input for Live Transcoder which allows changing the bitrate, sample rate, volume and much more. Check this and this video as example of control UI.

Let us know if you have any suggestions or questions regarding audio streaming, we're opened for discussions.

Related documentation


Nimble Streamer, Transmuxing MP3 to audio-only HLS, Live Streaming features in Nimble, Audio streaming features