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 cache performance

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 in terms of caching. We will refer to Nimble config and its parameters - it is described in Nimble Streamer configuration page.

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.

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.


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.

More performance tuning

You could see how you can improve RAM cache, however there are several other techniques which allow Nimble Streamer to process large amounts of viewers and data.
Read our performance tuning guide to learn more about this.

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

Related documentation

Nimble Streamer performance tuningLive Streaming scenarios in NimbleBuild streaming infrastructure with Nimble Streamer, Nimble Streamer APINimble Streamer configurationVOD cache control,

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.

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

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

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.
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.
$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 = "$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

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

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

Note: /manage/rtmp_status is considered deprecated.

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 - encoding bandwidth
    • resolution - video resolution
    • vcoded - video codec spec
    • acodec - audio code spec
    • publisher_ip -  publisher's source IP  in case RTMP/RTSP/SRT streams are pushed into Nimble instance
    • publisher_port - publisher's source PORT  in case RTMP/RTSP streams are pushed into  Nimble instance

Request example

Response example
    "app": "larix",
    "streams": [
        "strm": "srt",
        "publish_time": "1706701873",
        "bandwidth": "0",
        "resolution": "1280x720",
        "vcodec": "avc1.42001f",
        "protocol": "MPEGTS",
        "publisher_ip": ""
    "app": "rtmp",
    "streams": [
        "strm": "stream",
        "publish_time": "1706701540",
        "bandwidth": "11711170",
        "resolution": "1920x1080",
        "vcodec": "avc1.64002a",
        "acodec": "mp4a.40.2",
        "protocol": "RTMP",
        "publisher_ip": "",
        "publisher_port": 60349

Get RTMP settings

Request URL

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

Response example

Get MPEG-TS connections status 

Request URL

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

Response example

Get MPEG-TS settings

Request URL

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

Response example

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,