December 31, 2014

The State of Streaming Protocols - December 2014

WMSPanel team continues analyzing the state of streaming protocols. December showed a lot of views which means more of interesting content to look at.

We expectantly see the increase of HLS share (it's 70% now). The share of RTMP (22%) has been decreasing along with RTSP (2.5%) while progressive download showed good growth (~5%).

All these metrics calculations are based on 3 billion views.

The State of Streaming Protocols December, 2014

You can compare that with November stats below.

December 29, 2014

Cross-domain policy and access control in Nimble Streamer

Protecting web clients against vulnerabilities is one of the core features for safe web browsing. This is why popular platforms use various mechanisms to improve the security. This also includes video playback scenarios. Typically it's covered cross-origin resource sharing (CORS) mechanisms. Nimble Streamer needs to handle those cases.

Cross-domain policy file


For instance, many web media players use the "crossdomain.xml" file. It's a cross-domain policy file which gives the player permission to talk to servers other than the one it's hosted on.

As per Adobe, a cross-domain policy file is an XML document that grants a web client permission to handle data across multiple domains. When a client hosts content from a particular source domain and that content makes requests directed towards a domain other than its own, the remote domain would need to host a cross-domain policy file that grants access to the source domain, allowing the client to continue with the transaction.

Nimble Streamer allows specifying this file content. It is done via configuration file located at /etc/nimble/nimble.conf . Please refer to Nimble config file format for more details.

Use the following parameter to specify the domain within the XML file:
crossdomain_xml_allow_access_from_domain = <your.domain>
E.g. crossdomain_xml_allow_access_from_domain = wmspanel.com

If you'd like to define complete file content, you can create crossdomain.xml with XML based on Adobe's spec examples, like this:
<?xml version="1.0"?><cross-domain-policy><allow-access-from domain="*" secure="false"/></cross-domain-policy>
Once it's ready, save it to local directory and point Nimble to it via crossdomain_xml parameter:
crossdomain_xml = /etc/nimble/crossdomain.xml
The file content will be returned to a client as soon as it's requested.

Cross-origin resource sharing


Another technique is cross-origin resource sharing. Players may require Access-Control-Allow* headers in server responses. You can use the following parameters for that:
access_control_allow_origin = <some value>
access_control_allow_credentials = <some value>
access_control_expose_headers = <content-length>
access_control_allow_headers = <some value>
Some of possible values are
access_control_allow_origin = *
access_control_allow_credentials = true
access_control_expose_headers = 2459768
access_control_allow_headers = Range
or
access_control_allow_origin = http://your.domain.com
You may refer to W3C to get more details.


Important
: to apply config changes, please re-start Nimble instance by running:
sudo service nimble restart

Please read more about config file format here.

P2P streaming


You can also see example of CORS headers usage in the StreamRoot P2P streaming article featuring Nimble Streamer.


Related documentation


Nimble StreamerNimble Streamer APINimble Streamer configurationNimble Streamer performance tuning, SSL support for HLS, DASH, Icecast and MPEG-TS streaming,

Geo-location statistics for states and regions

WMSPanel reporting for media servers of various types has several types of metrics. Geo-location reporting is one of the most popular ones. It's part of daily statistics for particular data slice and it shows total number of connections established within selected dates range.

Today we introduce a highly anticipated improvement - geo-location stats how have extra information about regions within countries. Best example is a state within countries the United States of America or Brazil.

You can go to Reporting -> Geo stats menu to see a reporting page. This page contains a map representing views share and a list of countries, each having total number of connections and percents of share. You may select dates range to report and also export your data via CSV file.

List of countries in geo-location reporting.

Clicking on country name shows list of regions (e.g. states) list, each having total connections number and percentage.

List of states for USA in geo-location reporting.

Clicking on a region shows the list of cities in it, each having its own stats.

List of cities of a country in geo-location report.

With the additional regions metrics you will have full picture of your audience in any given country.

Read more about WMSPanel streaming reporting. Contact us if you have any questions about it.


Related documentation


End user reporting for WowzaDaily statisticsISP networks reportData slices for statisticsDevices and Players report for WowzaStreamed slices for WowzaScreencast for daily statisticsStatistics import APIGeo and IP range restriction for WowzaNimble Streamer geo-location restriction

This product includes GeoLite data created by MaxMind(c), available from http://www.maxmind.com

December 25, 2014

SSL support for HLS, MPEG-DASH, Icecast and MPEG-TS

Secure streaming is required in several scenarios in our customers' environments. This is why we are working on implementing security feature set. One of the high-demand features is SSL streaming for HLS, MPEG-DASH, MPEG-TS, Icecast and progressive download via Nimble Streamer. In this case streams are available via HTTPS protocols stack.

Nimble Streamer team has implemented this feature.

To set up HTTPS streaming, you need to generate SSL certificate first. This is done separately and you can read articles here to see an example of such activity. Usually SSL certificates are purchased by some provider like GoDaddy and these companies provide plenty of information about this process.

In this article we assume:
  • you already have a certificate for further setup,
  • your certificate and its key are located at your server and 
  • they are ready for further usage.
You will need to make changes to Nimble Streamer settings to make it work for your media streaming. These settings are stored in /etc/nimble/nimble.conf file.

Add the following parameters:

  • ssl_port - this is port number for SSL connections;
  • ssl_certificate - full path to certificate located at your server;
  • ssl_certificate_key - full path to certificate key located at your server;
  • ssl_certificate_key_pass - if you use encryption for your certificate key, you need to specify a password here. This is optional parameter, so if you don't use encryption, just don't add it into the config;
  • ssl_protocols - specifies what SSL protocols are used.
ssl_protocols requires list of protocols separated by spaces, e.g.
ssl_protocols = TLSv1 TLSv1.1 TLSv1.2
Full list is: SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2, default protocols are TLSv1, TLSv1.1 and TLSv1.2.

By default, Nimble Streamer handles connections via the port specified in config at "port" parameter. Usually it's port 8081. If you need Nimble Streamer to handle connections via SSL only, please set this parameter to 0, like this:
port = 0

If it has some other value, Nimble still handles streaming connections through 2 ports via both HTTP and HTTPS. If you remove "port" parameter, Nimble will use default value "8081"

Here's an example of SSL config parameters:
ssl_port = 443
ssl_certificate = /etc/nimble/yourdomain.com/yourdomain.com.crt
ssl_certificate_key = /etc/nimble/yourdomain.com/yourdomain.com.key


To apply config changes please re-start Nimble by running:
sudo service nimble restart

You can read more about Nimble Streamer parameters in this reference article.

With these settings you can stream MPEG-DASH, HLS, Icecast, MPEG-TS and progressive download via HTTPS.

If you need more sophisticated protection for HLS, please consider using HLS AES-128 DRM encryption supported by Nimble.

Troubleshooting


Some browsers or client software may fail to recognize your certificate even though it's valid. In this case you may need to get SSL certificate chain (root and intermediate certificates) combined into a single .crt file and use that file with Nimble Streamer. If you use Linux, you can do that by concatenating both files using this command:
cat your_site_certificate.crt root_certificate.crt > your_site_chained_certificate.crt



Please feel free to install Nimble Streamer to try this and other security-related features in action. Contact us in case of any questions.

Related documentation


WMSPanelNimble StreamerHotlink protection for Nimble StreamerPaywall for Nimble Streamer, Live streaming, VOD streaming,

December 24, 2014

MPEG-DASH hotlink protection and paywall

Nimble Streamer team keeps working on MPEG-DASH feature set. In addition to MPEG-DASH VOD streaming and RTMP to DASH live transmuxing, we've continued implementing features already existing for HLS.

One of the most popular feature sets of Nimble Streamer and WMSPanel is content protection. It allows creating easy-to-use paywalls and embedding them into existing websites. Major available features are hotlinking protection and pay-per-view framework.

Hotlinking protection


Hotlinking protection allows preventing "links hi-jacking". When you publish some media behind the paywall, anyone can take the direct URL to content and pass it to anyone else. Nimble Streamer allows preventing that. This is how it works.

  1. You modify a webpage which shows a media link to include a "signature" - the URL parameter which is based on a secret password and viewer's IP address
  2. You also set up protection rules in WMSPanel where you describe which streams are affected and what password will be used.
  3. When a viewer requests the media from the media server, Nimble Streamer checks the signature against the viewer's IP and encrypted password. If they match, the connection is established, if they don't then it will be forbidden.

This scenario works already for HLS and progressive download already. Now it works perfectly for MPEG-DASH.

Hotlinking protection for MPEG-DASH workflow diagram.

December 16, 2014

Making MPEG-DASH from RTMP: ABR streaming via Nimble Streamer

Nimble Streamer team keeps exploring MPEG-DASH capabilities. In addition to MPEG-DASH VOD streaming introduced, we've continued moving towards live streaming support. Today we release RTMP to MPEG-DASH transmuxing. Nimble Streamer may take published RTMP as well as pull stream from RTMP source and transmux it into DASH in live mode.

To use this capability you need to install Nimble Streamer and then define RTMP settings - either specify RTMP publish settings or RTMP pulled streams. Once it's done, you'll be able to get live MPEG-DASH streams for single bitrates as well as make ABR streams from them. Notice that H.264 content is supported at the moment.

Let's go step by step and see how it works.

December 3, 2014

MPEG-DASH support for VOD playback in Nimble Streamer

Through past several years, MPEG-DASH has gone a long path from a basic concept to industry standard. Thanks to contributions from a lot of companies and stakeholders, this technology can now be used in a variety of scenarios, including video on demand.

Nimble Streamer team is up for HTTP streaming technologies like HLS or Icecast. So moving towards DASH is a great step forward to better user experience for our customers who would like to try advantages of this HTTP-based protocol.

Today we introduce VOD playback for MPEG-DASH in Nimble Streamer. Is allows transmuxing MP4 files to DASH stream on-the-fly with very low resources consumption.


You can follow these easy steps to set up DASH VOD streaming.

1. Install Nimble Streamer


Use this installation instruction. Or just ask us to install it for you, we can do it free of charge.

2. Prepare content


Upload your MP4 file encoded with H.264/AAC or H.265 to a designated location on the server. The user called "nimble" must have read access to this directory and its contents. Let's say it would be /home/user/video directory

3. Set up VOD streaming


Click on Nimble Streamer -> Edit Nimble Routes menu to open streaming routes setup page.


Clicking on Set up VOD streaming button you will see the following dialog.

Adding VOD transmuxing route for DASH, HLS and progressive download.
In section 1 "Where incoming requests are coming" you may see the following fields.

  • Path field contains the URL name part which will then be used for accessing streams. You need to enter some value here, it shouldn't be blank because it's used for stats calculation purposes. It's /vod/ in this example. 
  • You may also set up Domain if you'd like this route to process only specific domains. You may leave it blank if you don't plan putting any limitations.

In section 2 you need to fill in Path field with full path to your content in your file system.

Then you need to select which Nimble Streamer instances will get these settings. So you may apply them to any number of instances at once in just a few clicks.

Once the route is set up, you may request any of the uploaded files via any protocol you need:

  • http://server_IP:8081/vod/sample_file.mp4/manifest.mpd - DASH
  • http://server_IP:8081/vod/sample_file.mp4/playlist.m3u8 - HLS
  • http://server_IP:8081/vod/sample_file.mp4 - progressive download

You may also change default port 8081 to any other port by changing server config.

If you'd like to have better viewing experience you may also consider using adaptive bitrate for VOD MPEG-DASH by using SMIL files.

4. Stream the content


With streaming URLs ready for further use, you may now add them to your player. MPEG-DASH streaming of Nimble Streamer was tested with DASH reference player as well as with Bitmovin's bitdash™ player. If you find any other players more suitable for you - please share your experience with us.

Using Nimble Streamer in your streaming infrastructure, you can get DASH streaming statistics via WMSPanel reporting SaaS. It has built-in support so you don't need to parse logs or anything like that - Nimble will send required metrics to central service for your convenience.


WMSPanel is currently an associate member of DASH Industry Forum. We will extend DASH feature set with all scenarios available for HLS. Check also MPEG-DASH live streaming via RTMP transmuxing, Please contact us if you need to cover some specific use cases or if you just have any feedback about DASH handling in Nimble Streamer.

Related documentation


Nimble Streamer, MPEG-DASH live streaming from RTMPDASH industry forum, HLS VOD streaming, HLS live streaming, Hotlink protection and paywall for MPEG-DASH

November 30, 2014

The State of Streaming Protocols - November 2014

WMSPanel team continues analyzing the state of streaming protocols. November showed a lot of views which means more of interesting content to look at.

We expectantly see the increase of HLS share (it's 69% now). The share of RTMP (23%) remains the same while RTSP (4.5%) has decreased. MPEG-DASH is showing a growth still having less than 1% overall.

All these metrics calculations are based on 1.88 billion views.

The State of Streaming Protocols November, 2014

November 26, 2014

Re-streaming SSL-protected HLS

Re-streaming of HLS streams from origin via edge server is one of the most popular features of Nimble Streamer. You can use any origin of HLS media and make it available to large number of viewers because Nimble Streamer is very light-weight and fast. So regardless of origin performance, your infrastructure will be able to handle thousands of viewers with minimum investments.

You may use secure origins so they have SSL protection for HLS traffic and use HTTPS for their connections. Now Nimble Streamer is able to use SSL to communicate to these origins for HLS re-streaming.



The output would be the same as Nimble has now. To make it use SSL, go to Re-streaming setup dialog and click on Use SSL checkbox. for the routes where origin uses HTTPS as shown below.

Set up HLS SSL re-streaming for Nimble Streamer.

If you'd like to stream the received content via SSL for your viewers, Nimble can do that as well. Read this article for details.

Re-streaming is just one of the use cases where Nimble Streamer is used. You can set it up as HLS origin for multi-bitrate live streaming as well as an origin for VOD streaming. It also has RTMP re-publishing feature set which allows setting up efficient live re-streaming across multiple origin-edge servers.

If you need more sophisticated protection for HLS, please consider using HLS AES-128 DRM encryption supported by Nimble.

Contact us if you have any questions regarding this or other Nimble Streamer features.

Related documentation


Nimble Streamer, HLS re-streaming via NimbleStreaming VOD with Nimble StreamerPull RTMP to HLS transmuxingRTMP republishingPay-per-view for Nimble Streamer,


November 13, 2014

Icecast and MPEG-TS hotlinking protection

WMSPanel paywall framework is the foundation for a variety of content protection systems within environment of our customers. It's available for both Nimble Streamer and Wowza Streaming Engine.

As Nimble Streamer has Icecast and MPEG2-TS transmuxing capabilities we also made changes to the paywall framework to support that. How you may specify Icecast and MPEG-2 TS in the Links re-publishing protection section. This is primarily used for streams hotlink protection as well as for pay-per-view processing.

Protecting HLS, progressive download, Icecast and MPEG-TS against links re-publishing.

Nimble Streamer also provides unique capabilities like domain lock and stream-name based protection for your content.

Please feel free to install Nimble Streamer to try this and other security-related features in action. If you need any help, check our FAQ first and contact us in case of other questions.

Related documentation


WMSPanelNimble StreamerHotlink protection for Nimble StreamerWMSAuth security feature set articlesPaywall for Nimble StreamerPaywall FAQMPEG2-TS transmuxing via Nimble Streamer

November 12, 2014

Nimble Streamer performance tuning

Nimble Streamer is created with high performance in mind. Being a native Linux application, Nimble is fast and has low resources consumption. This is why it is chosen for robust high-availability infrastructures and high-speed transmission use cases.

So our customers want to learn more about hardware configuration to be best fit for usage with Nimble Streamer. They also want to know what is their existing hardware capable of when using Nimble.

The description below covers these and other aspects of Nimble Streamer performance tuning. We will refer to Nimble config and its parameters - it is described in Nimble Streamer configuration article.

Calculating RAM amount for live streaming cache


The most used parameter which influences the streaming process is the amount of RAM available for caching. This amount is used for HLS chunks storage.

For each stream, Nimble stores 4 chunks in cache. Once the chunk is out of the playlist, it gets timeout of 45 seconds. So additionally the cache stores several chunks and the number depends on chunk duration. If it's 6 seconds, this would be 4 + 45/6 = 4 + 7 = 11 chunks. For 10 seconds chunks this would be 4 + 45/10 = 4 + 4 = 8 chunks.
The consumed memory amount for those chunks will depend on the bitrate:

RAM size (bytes) = number of chunks * chunk duration * bitrate / 8

I.e. for 1Mbps stream with 6 seconds chunks this would be 8.25MB. If you have an ABR HLS streaming with 512Kbps, 1.5Mbps and 2Mbps, with 10 seconds chunks, your cache amount would be around 40MB.

Notice that this number does not depend on a number of simultaneous viewers.

In addition to cache size you also need to consider the RAM size which your OS will take for network processing. As you can see from this real-life example the OS itself may take a lot more than Nimble Streamer instance.

RAM cache size parameter is set up via web UI.

CPU-related tuning for high load


CPU consumption of Nimble is very low. However, processing large speed streaming will require additional CPU resources. This is why we introduced worker_threads parameter in the config which defines how many threads will handle the streaming.

On average, 1 core process may handle up to 4 Gbps. If you need more bandwidth you can increase workers appropriately. Number of worker threads should not be larger than total number of processors' cores. Our advice is to keep it as low as possible to process expected bandwidth. E.g. if you have 10 Gbps NIC you should set workers to 3. If you won't have more than 4 Gbps then keep the default value.

In addition, you need to be sure your server can process all available bandwidth dividing IO interrupts between cores. It's not a nimble part but more HW server configuration.

VOD streaming cache control


VOD streaming also requires cache settings. As in case of live streaming, by default it's located in RAM. In addition, when RAM cache is full, VOD cache starts residing in the file system. So if you're doing VOD, you need to use "Max disk cache size" parameter for setting the maximum size for VOD cache. This is done via web UI. You may also need vod_cache_timeout and vod_cache_min_storage_time parameters in config file for TTL of cached chunks.

Please read "Improving cache control for VOD re-streaming" article to learn how to control VOD streaming cache.

Examples


Let's see some common questions coming from our customers.

How many connections can be handled on 2 CPU 512MB RAM server having 1.2Mbps stream with 1Gbps network?
1.2Mbps would require about 10MB of RAM cache. Also, 1Gbps will not require changing worker threads parameter and and 1 extra CPU. So the only limit in this case is the network speed. For given bitrate, the channel will handle 830 connections.

Handling 10 streams, 512Kbps each for approximately 10K viewers, what hardware do I need for that?
From RAM cache perspective, this will take around 42MB RAM cache. However, 10000 viewers will produce 5.1 Gbps bandwidth (i.e. transmission speed). This would definitely need an additional CPU core (making it 2 CPU cores total) and worker_threads parameter set to "2".

The ABR stream has 10 seconds chunks for 240, 360, 480 and 512 Kbps bitrates. What is the cache size for that?
Sum of bitrates is 1.6Mbps. 8 chunks, each 10 seconds, divided by 8 will make 16MB of cache size. You can have 10 streams like that and still not get the limit of the cheapest 512MB RAM virtual machine. With average bandwidth of around 400Kbps, your 10Gbps network will allow you to have around 25000 simultaneous connections but that will depend on the popularity of bitrates.


Contact us if you have any further questions or need some advise on Nimble Streamer usage.

Related documentation


Live Streaming scenarios in NimbleBuild streaming infrastructure with Nimble Streamer,  Utilizing 10Gbps bandwidth with a single Nimble instanceNimble Streamer APINimble Streamer configurationVOD cache control,
Live Transcoder for Nimble Streamer

November 3, 2014

Nimble Streamer status API

Nimble Streamer is being used in a variety of streaming use cases and scenarios. Many customers use multiple instances for load balancing and robustness purposes. The majority of balancing techniques use geo-location approach or just round-robin balancing to split the incoming requests equally between edges. However this does not guarantee that edge servers will have equal load as some viewers many disconnect from some edges while other edge users will keep watching.

So system administrators who use Nimble Streamer need a way to get status of each server to make real-time decisions about which servers should be processing current incoming requests. Usually this means changing the URL of the media streams on the website so any player would pick it up for playback. This is the most reliable way to make balancing happen regardless of the players' implementations.

This is why we extended common WMSPanel API by adding a pull API to Nimble Streamer itself. A customer may now launch a request to any Nimble instance and get its status and live streaming settings.


Enable API for Nimble Streamer instance


To make Nimble Streamer responding to API requests, the API settings must be set up in /etc/nimble/nimble.conf configuration file. You may check config description to get details about other parameters.

All parameters mentioned below are excluded from config by default.

management_listen_interfaces
This parameter specifies which IP addresses will be used for accepting AI requests. If it's not set, the API requests are not accepted.
Examples:
management_listen_interfaces = *  - all available interfaces are used
management_listen_interfaces = 127.0.0.1, 192.168.0.1

management_port
This one specifies which port is used to listen to API requests. If it's missing, the 8082 port is used.
Example:
management_port = 8086

management_token
This parameters specifies the token (i.e. password) which is used for authorizing API requests. See Making authorized requests section below for details.
If this parameter is missing, there will be no authorization made and anyone will be able to get information.
Example:
management_token = anypassword


Making authorized requests


This is an optional step for the cases when you use management_token parameter for authorizing requests. To make authorized requests you need to make MD5 hash based on the specified token. Please refer to this code sample to see how you can generate this hash.
<?php
$salt= rand(0, 1000000);
$key = "anypassword"; // the token specified in management_token parameter
$str2hash = $salt . "/". $key;
$md5raw = md5($str2hash, true);
$base64hash = base64_encode($md5raw);
$requiest_url = "http://127.0.0.1:8082/manage/server_status?salt=$salt&hash=$base64hash"
echo $request_url;
?>


Get server basic status


This API method allows getting current number of connection and bandwidth (transmission speed) level.

Request URL
/manage/server_status

Response parameters
Connections - number of active connections
OutRate - current transmission speed, bits per seconds
ap - Available processors
scl - System CPU load
tpms - Total physical memory size
fpms - Free physical memory size
tsss - Total swap space size
fsss - Free swap space size

Request example
curl -vvv http://127.0.0.1:8082/manage/server_status

Response example
{"Connections": 10, "OutRate": 5120000, "SysInfo": {"ap":2,"scl":0,"tpms":2098434048,"fpms":775127040,"tsss":2145382400,"fsss":1707151360}}


Get RTMP connections status


Request URL
/manage/rtmp_status

Response parameters

  • app - name of application; if there are several applications, they will have their separate sections.
  • streams - list of streams and their parameters
    • strm - stream name
    • publish_time - The value returned generally represents the number of seconds since 00:00 hours, Jan 1, 1970 UTC
    • bandwidth - transmission speed
    • resolution - video resolution
    • vcoded - video codec spec
    • acodec - audio code spec

Request example
http://127.0.0.1:8082/manage/rtmp_status

Response example
[{"app":"live","streams":[{"strm":"stream","publish_time":1456961902, "bandwidth":"507882","resolution":"424x240","vcodec":"avc1.66.30","acodec":"mp4a.40.2"}]}]


Get RTMP settings


Request URL
/manage/rtmp_settings

Response parameters
They are nested under RtmpSettings node.
  • hash - response hash
  • interfaces - which interfaces are set to process RTMP streaming
  • login - login for RTMP publishing
  • password - password for RTMP publishing
  • duration - default chunk duration
  • protocols - which protocols' streams are generated as output
  • apps - specific applications' settings
  • abr - individual ABR streams settings
    • app - application name
    • stream - stream name
    • streams - single bitrate streams included into the ABR, each having its app and stream names
Request example
http://127.0.0.1:8082/manage/rtmp_settings

Response example
{"RtmpSettings":{"hash":"1414983917310","interfaces":[{"ip":"*","port":1936}],"login":"","password":"","duration":6,"protocols":["HLS"],"apps":[],"abr":[{"app":"nimble_live_abr","stream":"abrstream","streams":[{"app":"live","stream":"stream"}]}]}}


Get MPEG-TS connections status 


Request URL
/manage/mpeg2ts_status

Response parameters
They are nested under Cameras node. Each stream has entries for

  • id - stream ID
  • st - the stream status
  • tr - processed traffic delta
  • bw - current bandwidth 
  • pmts - processes details


Request example
http://127.0.0.1:8082/manage/mpeg2ts_status

Response example
{"Cameras":[{"id":"5456fab17d5c00547f000002","st":"online","tr":"0","bw":"440623","pmts":[{"id":4096,"pids":[{"pid":256,"t":27},{"pid":257,"t":15}]}]}]}


Get MPEG-TS settings


Request URL
/manage/mpeg2ts_settings

Response parameters

  • CamerasHash - response hash
  • Cameras - information about each stream
    • id - source stream ID
    • ip - IP of the source stream
    • port - source stream port
    • protocol - whether UDP or HTTP is used.


Request example
http://127.0.0.1:8082/manage/mpeg2ts_settings

Response example
{"CamerasHash":"1414986417897","Cameras":[{"id":"5456fab17d5c00547f000002","ip":"127.0.0.1","port":1234,"protocol":"udp"}]}



This set of APIs is the first step to building reliable and robust load balancing. If you have any questions or further use cases which you'd like to cover, let us know about it, any feedback is appreciated. Check also a full Nimble Streamer API reference.

Update: You may also find useful the Nimble Streamer routes control API and RTMP streaming API which allows controlling Nimble behavior.

Related documentation


Nimble Streamer, Nimble Streamer API reference, Nimble Streamer routes control APIRTMP and MPEG-TS streamingWMSPanel API referenceRTMP playback and streaming via Nimble,

October 31, 2014

The State of Streaming Protocols - October 2014

WMSPanel team continues analyzing the state of streaming protocols. October had a lot of connections which means more of interesting content to look at.

We still see the increase of HLS share (now it's 67%). The share of RTMP (23%) and RTSP (9%) has decreased but the absolute number of connections did not go down significantly which means that newcomers preferred HLS. Other protocols did not have significant changes. MPEG-DASH has shown a small growth by several thousands of connections.

All these metrics are calculated based on 870M+ views.

The State of Streaming Protocols October, 2014

October 30, 2014

Publishing RTMP from Nimble Streamer to Fastly CDN

UPDATE: RTMP publishing is now a deprecated function of Fastly CDN. However, you can use the description below as a general reference to publishing media to RTMP-compatible CDNs.


Nimble Streamer is a media server which can be used both as origin server and as an edge for end-users delivery. Some customers prefer using it as an origin server only and have content delivery network (CDN) to bring streaming media to viewers.

One of the CDNs which our customers use is Fastly CDN. It provides streaming media delivery network so our customers create Nimble Streamer origin and publish their media into Fastly. Here is a brief instruction about how you can make the setup using WMSPanel products.

1. Set up RTMP streaming in Fastly settings.


First, request support team to enable it. Then define your stream name and the stream key for authenticating your media. Use the "How do I publish a live stream?" article for details.

October 27, 2014

RTMP, RTSP and Icecast pulled streams fallback

RTMP to HLS transmuxing is one of the popular use cases of Nimble Streamer as well as other protocols transmuxing. It allows producing HLS with high efficiency and low resources consumption which allows building robust streaming solutions. However, Nimble is just a link in delivery chain and other elements like source transcoder or origin server may go down. This is why a robust live streaming network needs to have multiple media sources. And Nimble Streamer needs to handle all fallback sources and still produce output streams with no interruptions.

This is why Nimble Streamer team introduces RTMP, RTSP and Icecast pull sources fallback support.

When you define RTMP pull streams, you just specify 2 or more sources of the same pulled stream and if the first stream goes down, other stream will be picked up for processing.

To set this up you need to follow basic setup steps described in Pull RTMP to HLS transmuxing article. The main enhancement is multiple edit boxes in Live pull settings for adding new pull URL.



Being in the list of pulled streams, you can click on Add URL and see the following dialog.


Here the URL is a mandatory field while Fallback URLs can be added one by one, regardless of their number. Saving the settings will launch the RTMP to HLS processing. Also you can use advanced RTMP pull settings to specify incoming RTMP streams. Please read the Processing RTMP and RTSP pull streams per request article for details.

WMSPanel also provides multiple edit capabilities. You may edit RTMP pull sources as a text setting to able to do things like:

  • adding big amount of streams;
  • making backup and restore of settings;
  • transition of settings between servers.

Just click on Multiple edit button to use the dialog as shown below. Here, a "dr_urls" is a field containing fallback links mentioned above. "url", "application" and "stream" are the fields available in the "Add URLs" dialog.



With this entire failover feature you can easily handle RTMP disaster recovery in case of any origin source availability problems.
You may also consider using RTMP streaming API to control this behavior remotely.

If you need to change the pulled content, like change the bitrate, use our Live Transcoder for Nimble Streamer to transform. It has high performance and low resource usage.


Please check other live streaming, audio streaming and streaming infrastructure features available in Nimble Streamer and let us know if you face any questions or issues.

Related documentation


Live Streaming features in NimbleLive Transcoder for Nimble StreamerRTMP feature setPull RTMP to HLS transmuxingRTMP republishing via Nimble, Audio streaming features

October 23, 2014

Players and devices statistics API

WMSPanel gives statistics for media servers which include statistics for players and devices. As our customers need to integrate these stats into their of workflow, our team provides pull API for obtaining the aggregated data.
We introduce a pull API for players and devices metrics to give more flexibility in data analysis.

All you need is to make some setup on WMSPanel side and then make proper API calls using any programming technology you like. Let's go step by step.

1. Set up API on WMSPanel side


To start using the API, you need to make small setup on WMSPanel side.

First, the API should be enabled by WMSPanel team, so please contact us to enable it for your account. Then you need to follow these steps:
  1. Go to Control menu -> API setup -> Pull API tab.
  2. Copy Client ID for further usage in your scripts.
  3. Click on "Generate New Key" to copy API key as well. This will be used for further authorization.
  4. Populate white list with IPs of the hosts where you will be making API call from, like your development machine or your web server. Just enter new IP and click on "Add IP to Whitelist" one by one.
Check this screenshot as a reference:

Duration statistics API

WMSPanel provides various statistics for media servers which include playback duration statistics. As our customers need to integrate these stats into their of workflow, our team provides pull API for obtaining the aggregated data.
We introduce a pull API for duration metrics to give more flexibility in data analysis.

All you need is to make some setup on WMSPanel side and then make proper API calls using any programming technology you like. Let's go step by step.

1. Set up API on WMSPanel side


To start using the API, you need to make small setup on WMSPanel side.

First, the API should be enabled by WMSPanel team, so please contact us to enable it for your account. Then you need to follow these steps:
  1. Go to Control menu -> API setup -> Pull API tab.
  2. Copy Client ID for further usage in your scripts.
  3. Click on "Generate New Key" to copy API key as well. This will be used for further authorization.
  4. Populate white list with IPs of the hosts where you will be making API call from, like your development machine or your web server. Just enter new IP and click on "Add IP to Whitelist" one by one.
Check this screenshot as a reference:

Daily statistics API

One of the most popular statistics for media servers in WMSPanel is daily statistics report. As our customers want to integrate our stats into their of workflow, our team provides pull API for obtaining the aggregated data.
Now we've made a pull API for daily stats in order to give more flexibility in data analysis.

All you need is to make some setup on WMSPanel side and then make proper API calls using any programming technology you like. Let's go step by step.

1. Set up API on WMSPanel side


To start using the API, you need to make small setup on WMSPanel side.

First, the API should be enabled by WMSPanel team, so please contact us to enable it for your account. Then you need to follow these steps:
  1. Go to Control menu -> API setup -> Pull API tab.
  2. Copy Client ID for further usage in your scripts.
  3. Click on "Generate New Key" to copy API key as well. This will be used for further authorization.
  4. Populate white list with IPs of the hosts where you will be making API call from, like your development machine or your web server. Just enter new IP and click on "Add IP to Whitelist" one by one.
Check this screenshot as a reference:

October 21, 2014

Server offline notification API

WMSPanel gets data about each of the servers being registered in customer account via periodical sync-up which happens each 30 seconds. So when the sync-ups stop, this means that a server is inaccessible and an administrator needs to take some actions. So we've added servers offline notifications to cover that case and to send email alerts when the server goes offline from our panel point of view.

Now we introduce push API for offline notifications. You may now get calls to your handler application from our service when any of your streams are unavailable.

Here's how it works.

1. Create a handler


A handler is a publicly available web application which can get HTTP POST requests. This might be implemented using any programming technology. Check this example from our streams un-publish notifications for Wowza for to see how this can be done via PHP with PECL packages installed.

October 16, 2014

Dispersa alerts API

WMSPanel team continues improving Dispersa streams availability monitoring service. After introducing streams monitoring history, we wanted to make Dispersa be more flexible in terms of notification capabilities. As example, people would may want to re-set a stream if it's not visible to the checkpoints, or just send several messages to end-users who use WMSPanel via white label.

Today we introduce push API for Dispersa check-over events. You may now get calls to your handler application from our service when any of your streams are unavailable or available back online again.

Here's how it works.

1. Set up streams to monitor


Use this instruction to set up streams which you'd like to monitor via Dispersa distributed network of checkpoints.

2. Create a handler


A handler is a publicly available web application which can get HTTP POST requests. This might be implemented using any programming technology. Check this example from our streams un-publish notifications for Wowza for to see how this can be done via PHP with PECL packages installed.

October 10, 2014

Hotlink protection with stream-based signature

One of WMSPanel key capabilities is WMSAuth security feature set for streaming protection and restriction. Hotlinking protection is one of our most popular features, as it prevents media streams theft.

We've got requests for improvements of this feature and one of the most popular ones was to add stream name into stream signature to make it unique for each stream.

And so we did. In addition to existing functionality, a couple of new parameters were added to cover this use case. Let's go step by step to see how it's deployed.

Caution. You need to apply this instruction to the test applications and streams first before running it in production mode.

1. Set up WMSAuth


Install Nimble Streamer and then follow hotlink protection setup instruction.

October 8, 2014

Server tasks remote management via web UI

With its current feature set, WMSPanel became a reporting and control center for a diverse streaming environment. You may have any number of Wowza, Red5, nginx, Nimble Streamer or even Windows Media and still have the same excellent set of reports with stats aggregated from all of them and split by servers, apps or streams. With API available, it's also a single source of data for further analytic.

Now to make WMSPanel also a central tool for controlling these servers' behavior, our team introduces server-side tasks control web interface.

WMSPanel allows defining tasks. A task executes some server-side command and shows its execution status. The tasks are processed via pre-installed Nimble Streamer. It acts as an agent which runs and tracks commands. So WMSPanel interacts with Nimble and Nimble interacts with system processes.

Easy to use web interface allows controlling multiple tasks for multiple servers from the same UI with no need to log into each remote machine.

These tasks can run external transcoders like FFMPEG, image processing software and any other command-line tools.

Notice that task management works only on Linux installations of Nimble Streamer.


Let's see how server tasks are defined and used.

October 6, 2014

RTMP and RTSP republishing via Nimble Streamer

Robust and reliable delivery for live streaming requires a network of servers to transfer streams via multiple routes. This is especially important when live content must be delivered across the borders and continents to consume as less bandwidth as possible. So having single stream pushed to the distant edge server for further transmuxing to multiple viewers will be the way with the least resource consumption.

RTMP and RTSP are the protocols which are popular for live transmission between media sources and servers. This is why Nimble Streamer provides RTMP re-publishing. Once you have published stream, you may set up where it needs to be pushed further. The same applies to RTSP re-publishing as it's popular protocol for delivery from cameras.
Setting multiple rules, you can set up flexible delivery chains for any scenarios.

Take a look at simple delivery network which uses RTMP as an input and several formats as an output.

RTMP republishing for flexible delivery chain.


Let's see how to set this up.

September 30, 2014

The State of Streaming Protocols - September 2014

WMSPanel team continues analyzing the state of streaming protocols. The first month of autumn is over so we can take a look at it.

September showed the expected increase of HLS share (which is nearly 62%) and decrease of RTMP (26%) and RTSP (~11%). Other protocols did not have significant changes. These metrics are calculated based on 768M views.




You can compare that with August stats to see the increasing share of HLS.

September 17, 2014

End-user access for WMSPanel API

WMSPanel has a set of APIs which allows requesting aggregated pre-processed data and take it into customer environment for further processing. Recent real-time and in-depth stats APIs give ability to request data on entire account level selecting data for all available servers and data slices.

Some of our customers need to provide access to their own clients so they could make their specific analysis. WMSPanel now allows that as well as account-wise API access. End user may now access data which is visible to his account according to data slice settings so his scope may be limited to some subset of stats. If a user is given access to several servers and slices, he may request specific slice and server.

This control has become part of users management feature set. To enable API for selected user, choose Control / Users management menu to see the list of users in your account.

Account's users management page.

Clicking on Edit link will bring a user details dialog. Click on API access check box to see API ID and API key. A user may use them for further requests.

User details with API access parameters.

You may re-generate API key in case of security concerns or just disable it any time.

Once the access is given, the user may go to Settings menu to API setup tab to see the API ID and generate the key for further usage. He may also control his own white list to access the API.

End-user settings for API access.

User will be able to send requests and get data according to his access level. You may give this access to some non-admin user as well as create separate admin user specifically for API requests.

Our team continues working on a Please also check full set of APIs. Let us know if you have any cases which need to be covered to build flexible streaming infrastructure.

Related documentation


Media servers reporting, WMSPanel API referenceReal-time stats API, In-depth stats API, WMSPanel users managementDaily stats push APIPay-per-view frameworkRTMP publish/unpublish notifications, Slices and branding in WMSPanel


September 5, 2014

Transmuxing Icecast/Shoutcast to HLS/RTMP/MPEG-DASH

Nimble Streamer has wide audio streaming feature set.

This includes various Icecast and SHOUTcast related features.

You can give any supported protocol as an input: Icecast and SHOUTcastRTMPRTSP and MPEG-TS.
These streams will be transmuxed using the same engine and they will be given as HLS, MPEG-DASH, RTMP, RTSP, MPEG-TS and Icecast.
This means Nimble can work both as a transmuxer for Icecast to HLS and as a re-streamer for Icecast. Notice that the result Icecast stream has same metadata tags as original stream.

Both MP3 and AAC codecs are supported.




To use it in your scenarios, follow these simple steps.

September 2, 2014

Dispersa streams monitoring history

When we introduced Dispersa streams availability monitor, we new that people need not only to monitor but also to track the performance of their streams. Bringing proper quality of service for streaming media business requires data for analysis.

Now Dispersa is able to store the history of check-overs for last 32 days and view it via easy to use chart. Being a premium Dispersa user, you may use Monitoring menu to see streams monitoring panel.

Streams monitoring dashboard.
Now click on a stream name to view the history. If some transmission wasn't available between some moments time, the chart will show the breakage. Each checkpoint, including private checkpoints, will have its separate history.

View stream availability history at all checkpoints.
View stream monitoring results over time.
Stream may be unavailable for certain period of time for some of checkpoints.

You may zoom to any time slot within stored period by picking range.

Viewing period details for stream monitoring.

If you'd like to have same statistics within your monitoring or analytic tools, use Dispersa alerts push API to get notified about streams going offline and online.

We will extend Dispersa with more QoS-related functionality so if you have any suggestions, just let us know about it.

Check other current and future streaming QoS features of Dispersa.

Related documentation


Dispersa streams monitoringHow to set up streams availability monitoring, Dispersa alerts push APIAdding private checkpoints for DispersaAllowing Dispersa to check WMSAuth protected streamsWMSPanel YouTube channelEnd user reporting for media servers

September 1, 2014

The State of Streaming Protocols - August 2014

WMSPanel team continues analyzing the state of streaming protocols which we began previously. August is over so we can take a look at past month as well as at the entire summer time.

August showed the increase of HLS share (which is 59%) and decrease of RTMP (27%) and RTSP (~13%). Other protocols did not have significant changes and share the remaining 1%. These metrics are calculated based on 700M views from August.

The State of Streaming Protocols - August, 2014.

You can compare that to the metrics of all summer months. WMSPanel processed statistics about more than 2 billions of views during that time.

The State of Streaming Protocols - summer of 2014.

These stats are collected from 1100 media servers, including Wowza Streaming Engine (mostly 3.x and 4.x flavors) and Nimble Streamer.

We hope this snapshot will be useful for our audience and we'll continue analyzing protocols going forward



This report is brought to you by WMSPanel team.

August 25, 2014

Transmuxing RTMP to Icecast with Nimble Streamer

Icecast remain a very popular protocol for streaming audio over the Internet. Numerous online radio stations use this way to deliver their content due to its simplicity and low overhead.

Nimble Streamer allows transmuxing any RTMP stream into Icecast stream. You may both pull existing RTMP or get published RTMP and produce stream with audio/mpeg MIME type output. Check also Icecast to HLS/MPEG2TS transmuxing and Icecast re-streaming.

This article also applies to other supported protocols like RTSP and MPEG-TS as Nimble has same transmuxing engine for all protocols.

To produce Icecast stream you need to follow these simple steps.

1. Install Nimble Streamer


Follow this easy to use instruction to set up Nimble Streamer instance.

2. Define RTMP settings


Now you need to describe how Nimble will take data from available RTMP source.

Go to Nimble Streamer / Live streams settings menu.

Global tab has service-wise settings.
Chunk duration sets the default duration of chunks for all outgoing streams.
Protocols field allow defining which protocols will be used for providing output streams. If you need Icecast use "Icecast" checkbox. You may have several types of simultaneous streams like HLS and Iceast or Icecast and MPEG2TS.



If you use published RTMP for further transmuxing, you may define Push login and password for applied to all incoming RTMP publishing by default.

These settings can be overlapped by individual applications settings. Click on Applications tab to see list of individual apps.

Applications' individual settings list.


Click on Add application settings to see a dialog for adding new app setting.

Adding new Iceast application setting.


If you pull RTMP streams for further transmuxing, the next tab you may need is Live pull settings. It allows defining live streams from multiple media sources.




Click Add RTMP URL to define new media source.

Adding new source of RTMP media.


Here you need to enter URL of RTMP stream and then application and stream name which you'd like to use for outgoing HLS stream.

List of individual RTMP pulled streams settings.

3. Use outgoing streams


Once the incoming streams accepted by Nimble, you will see the outgoing stream available in Outgoing streams page. Click on Outgoing link or Outgoing section on the streaming scheme picture.

List of ourgoing streams transmuxed from incoming RTMP streams.

Here you can see result streams available for your viewers. You can see its basic parameters of video and audio stream as well as bandwidth and resolution. In case of audio stream it has less details. To use the outgoing stream, click on URL for Player to see dialog showing URLs to insert into client's player.




If you select URLs for the protocols which you defined in global or application-wide settings. If your server has several IP addresses, there will be more URLs to use.


That's it. You may use it now for streaming and use full variety of reporting features to know more about your audience and your streams' popularity and performance.If you select several protocols in application of server-wise settings, or if your server has several IP addresses, there will be more URLs to use.
Having same application my produce URL for several media type like:

  • http://192.168.0.4:8081/sample/stream/icecast.audio - for Icecast
  • http://192.168.0.4:8081/sample/stream/playlist.m3u8 - for HLS output

You may also consider using RTMP streaming API and Icecast control API to control this behavior remotely. RTMP republishing is also available for scenarios of multiple edge servers live delivery.
You may also apply full featured Paywall framework for your audio streams.
To make sure your streams are available, set up Icecast streams monitoring with Dispersa.

Related documentation