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

Nimble Streamer, Nimble Streamer configuration, HLS VOD streaming, MPEG-DASH VOD streaming, MPEG-DASH VOD, ABR VOD for HLS via SMIL, ABR VOD for MPEG-DASH via SMIL

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 paywall, WMSPanel github page, MPEG_DASH hotlinking protection, HLS AES-128 DRM encryption

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.

Install Nimble Streamer for Windows now.

See also - Nimble Streamer for MacOS.

Related documentation

Nimble Streamer, Live streaming via Nimble Streamer, VOD streaming via Nimble Streamer, WMSPanel Paywall

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.

1.1 DRM key setup

Server administrator goes to Control top menu and selects HLS AES encryption DRM.

This opens a dialog shown below.

The DRM key field has the key used for further DRM encryption. You may re-generate the key any time. Clicking Save brings the value to the Nimble Streamer instance.

1.2 Playlist and key exchange

When the visitor wants to play the media, the player requests a stream playlist from Nimble Streamer. The playlist is returned with chunk-list (nested playlist), which content is similar to the one listed below.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-KEY:METHOD=AES-128,URI="hls.key?nimblesessionid=5"
#EXTINF:3.75,
n_0.ts?nimblesessionid=5
#EXTINF:7.5,
n_1.ts?nimblesessionid=5
#EXTINF:7.5,
n_2.ts?nimblesessionid=5

In EXT-X-KEY field you may see the URI which is used for returning the encryption key assigned at step 1.1. This URI is hosted by Nimble instance itself.
The player downloads the key and starts requesting chunks.

1.3 Chunks processing

When Nimble gets the request for a chunk from player, that chunk is being encrypted by AES-128 using the assigned encryption key. Then it's being returned to the player.

Player gets the chunk and decrypts the content with previously downloaded key.

Further workflow is based on the same steps - chunks are requested and processed with the key obtained from the URL hosted by Nimble.

2. Using encryption key from external URL

This scenario is similar to the scenario 1, the difference is that the DRM AES-128 encryption key is provided by the external handler.

This scenario is shown on the sequence diagram below.

AES DRM encryption workflow with external DRM key handler.

Here are the steps to follow.

2.1 DRM key setup

As in scenario 1, server administrator goes to Servers menu, selects Nimble Streamer instance and clicks on DRM Setup.

This opens a dialog shown below.

The DRM key field has the key used for further DRM encryption. You may re-generate the key any time.
To specify a URL for external key handler click on "I also want to use my own DRM key URL" to see additional field.

Enter the DRM URL where the key will be obtained. Clicking Save brings the value to the Nimble Streamer instance.

If the key DRM URL is specified, Nimble Streamer will not be returning the key like described in step 1.2. So you need to implement the functionality which will return the correct key, see step 2.2.

2.2 DRM key URL handler

The DRM URL specified at step 2.1 must point to the location of the handler which is responsible for returning DRM key. Typically it's a web application which makes decision whether a viewer may get the DRM key or not.

The returned key must be the same as the key specified in DRM key field at step 2.1.
The Content-Type of the returned key must be application/octet-stream. The key itself needs to have binary format according to HLS RFC mentioned in the beginning of this article.

If a WMSAuth signature is used for authenticating a user, this parameter is also passed to the handler. So you may implement pay-per-view system based on DRM encryption.

2.3 Playlist and key exchange

When the visitor wants to play the media, the player requests a stream playlist from Nimble Streamer. The playlist is returned with chunk-list (nested playlist), which content is similar to the one listed below.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-KEY:METHOD=AES-128,URI="http://example.com/drm/hls.key?nimblesessionid=7"
#EXTINF:3.75,
n_0.ts?nimblesessionid=7
#EXTINF:7.5,
n_1.ts?nimblesessionid=7
#EXTINF:7.5,
n_2.ts?nimblesessionid=7

In EXT-X-KEY field you may see the URI which you set up at step 2.1.

The player obtains the key from the handler and starts requesting chunks.

2.4 Chunks processing

Just as in step 1.3, when Nimble gets the request for a chunk from player, that chunk is being encrypted by AES-128 using the assigned encryption key. Then it's being returned to the player.

Player gets the chunk and de-crypts the content with previously downloaded key.

Further workflow is based on the same steps - chunks are requested and processed with the key obtained from the handler URL.


Also take a look at Nimble Streamer DRM feature set which covers various encryption.

Related documentation

Nimble Streamer, Nimble Streamer DRM, HLS RFC, Nimble Streamer HLS support for VOD streaming, WMSPanel Paywall framework, SSL support for HTTP streaming in Nimble Streamer, Verimatrix VCAS DRM support in Nimble

HLS, MPEG-DASH, SLDP 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, MPEG-DASH, SLDP, 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.

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.

Another useful metadata feature is the ability to append any custom metadata to Icecast stream via WMSPanel UI. If you use Nimble Live Transcoder for the streaming scenarios which involve Icecast streams, you need to use this instruction about passing through the metadata.

If you use incoming RTMP stream as a source of Icecast and that RTMP has metadata, you may use RMTP metadata for Icecast generation. If you'd like to passthrough the RTMP Icecast metadata via Live Transcoder, please follow this article.

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