The State of Streaming Protocols - May 2015

WMSPanel team continues analyzing the state of streaming protocols. April had less views than March but the same share of protocols.

The metrics calculations are based on nearly 1.5 billion views, which is twice less than previous month. The stats are collected from 1700+ media servers (including Nimble Streamer and Wowza) so we consider May was a bit "relaxed" comparing to April for our customers. Also, we introduced HTTP origin for "CDN-friendly" outgoing streaming which was adopted by our key customers - this affected stats as well. However, the picture remained pretty much the same.

HLS share went down to 72% share while Icecast and MPEG-DASH numbers increased. Check the chart below for more numbers.

The State of Streaming Protocols - May 2015.

You can compare that to April stats below.

Verimatrix VCAS live streams DRM support via Nimble Streamer

Monetizing the content requires various techniques for media protection. Nimble Streamer team helps streamers protecting their content via paywall capabilities which include hotlink protection, pay-per-view, geo-restriction, HLS AES-128 encryption support and some other features.
Now we introduce DRM capabilities for live streaming via Verimatrix Video Content Authority System (VCAS™) support.

VCAS pay-TV operator solution consists of combinations of the components optimized for a specific market segment. Based on a highly modular system architecture and efficient form factor, VCAS is inherently cost effective for the smallest deployment while scaling easily to operations with millions of subscribers.

With VCAS, Nimble Streamer can be used for media encryption and delivery of live content. Having RTMP, RTSP or MPEG-TS input, it will produce HLS streams properly encrypted. Nimble is optimized for handling large amount of viewers and building robust infrastructure so it may be the only element which you need for delivery of media from content owner to consumers. As it's a freeware and it requires low amounts of resources, this would allow decreasing the cost of ownership for your solutions.


This functionality has been moved into Nimble DRM feature set, please refer to its documentation to learn more about the setup.

Transmux RTSP to HLS, RTMP, DASH and more via Nimble Streamer

RTSP streaming still has its share among other protocols for playback and streaming from some of the encoders, especially from cameras. It's an opened technology available via RFC so companies widely use it for certain use cases and scenarios.

So Nimble Streamer now has support for RTSP protocol as well.
It handles any of allowed streams types:

• announced RTSP streams published to Nimble
• streams available via public URL (i.e. pulled streams)

The output streams protocols are:

• RTMP;
• RTSP - so it allows RTSP re-streaming;
• HLS;
• MPEG-DASH;
• Icecast;
• MPEG-TS.

So having one input stream, a streaming administrator may get 5 different outgoing streams to support various client types.

Let's see how this can be set up.

1. Install Nimble Streamer

Use this installation instruction to get Nimble on your server or desktop.

To take RTSP streams for transmuxing, you need to specify available sources. After that Nimble will pick them up and start producing streams for immediate use.

Go to Nimble Streamer -> Live Streams Settings menu to see live streaming setup page.

You can proceed with any of 2 possible scenarios or combine them:

• get announced (published) RTSP streams;
• pull RTSP streams from available URL.

2. RTSP setup

You may combine both scenarios and process both types of incoming streams to get outgoing streams.

Announced streams setup

Going into Live streams settings page, first you'll see several tabs. First one you need is Global. These are global server settings. they are as follows.

• Default chunk duration used for outgoing streams.
• Default chunks count for the playlist or manifest - this is used for HLS and DASH.
• Protocols which will be produced - you can generate all 6 supported types or just one of them, it does not affect the performance much.
• Push login and password for published streams - they will be used by default for published streams but can be overridden by individual apps settings.

You may also define individual applications' settings. Go to Applications tab to add new apps. Each app has the same set of fields as Global server settings.

Individual applications list.

Defining new application settings.

You may apply new application settings to several Nimble servers instances. Just click on the check boxes with their names in the dialog - the setting will be applied to each server within a few seconds.


Important: to make Nimble Streamer capable of getting published RTSP streams, it needs to listen to a specific interface - address and port. Go to Interfaces tab and click on Add RTSP interface.

Defining interfaces for processing RTSP streams.

You'll see a dialog for specifying an address and a port to listen to. You may leave IP address blank, in this case Nimble will listen to all IP addresses available. The default RTSP port is 554 but your can use any other un-mapped port.

New interface definition.

As in other dialogs, may apply new settings to multiple servers to convenience of administration.

Pulled streams setup

If your streaming content is available via available RTMP streams, you may pull them into Nimble instances for further transmuxing. To make proper settings, go to Live pull settings tab. 

List of pulled streams.

There you click on Add RTSP URL button to see new dialog for adding new stream to transmux.

Adding new RTSP source stream

You can use the following fields:

• "URL" - the address of RTSP stream.
• Optional "Fallback URLs" field - if you have multiple sources of the same stream, you may specify them to make robust streaming, so if main stream goes down, secondary streams could be used.
• "Output application" and "Output stream" are the names which will be used for outgoing stream URL.
• "Idle time" and "Dynamic stream name" fields are used for pull-by-request functionality for pulling the content only when it's demanded by the viewers. Read this article for more details.

"RTSP mode" field can be used to define content delivery mode. Possible values are as follows:

• TCP preferred - if the source supports both UDP and TCP, then TCP is used.
• UDP preferred - if both UDP and TCP are supported, then UDP is used.
• UDP only
• TCP only
• RTSP over HTTP (VAPIX) - this is for some AXIS cameras which use HTTP proxies.

RTSP over HTTP mode will require to specify the URL starting with "http://", not "rtsp://" as usual. Also, when you select this mode, you will get additional field called HTTP proxy - it's an optional field where you can specify a proxy to use when trying to fetch the data.

As in any other Nimble Streamer setting in WMSPanel, you may apply this one to multiple servers - just click on the check boxes with their names.

Once it's saved, you'll see it in settings list.

The output streams will be served via protocols which are set up in server global or application settings.
E.g. if you've set up "live" app individual settings in "Applications" tab and set it to produce RTMP and HLS, then pulled streams will be processed to produce RTMP and HLS.

Now the outgoing streams will be produced as soon as the incoming stream arrives.

3. Using outgoing streams

Having incoming streams defined and processed, you may now use the results of Nimble Streamer work for streaming your content via the protocols which you selected in global or application settings.

Go to Nimble Streamer / Live streams menu and on the new page click on Outgoing stream area on a chart or Outgoing link on top of the setup area. You will see all streams that are currently processed and ready for usage.
Each stream has:

• status, 
• names of servers which have this stream running, 
• stream name for playback URL,
• video and audio parameters and options,
• link for getting playback URL - it's a question mark icon.

Available outgoing streams list.

To use the outgoing stream for playback, click on question mark icon to see Sample URL for player dialog. Here you see links for all protocols which you defined for this server in global or per-app settings. In our case it's HLS, DASH and RTMP. You may also choose RTSP as output in case you need it for your viewers or for pulling it by other servers.

Besides links, you will be able to try playing these streams in any of the popular players. First you choose URL to play then an player from list of available players based on the chosen protocol. E.g. dash.js will be shown only if you choose MPEG-DASH link - manifest.mpd. For the selected player you will be able to see its source code for embedding.

Adaptive bitrate

Having outgoing streams defined, you may also create adaptive bitrate (ABR) streams.
Read this article for more details regarding ABR setup and usage.

Further usage

Having the output streams ready for usage, you may follow various scenarios from playback to live media delivery between origins and edges. For example, check RTMP re-publishing feature set which uses stream publishing rather then stream pulling. You may control Nimble Streamer RTSP behavior via pull API. Please check the API reference for details.

RTSP may be recorded for further playback via HLS and MPEG-DASH using the DVR feature set. Read this article for setup details.

RTSP publishing may be controlled according to your business logic using our publish control framework for RTSP and RTMP.


Usage snapshots page shows how you can use Softvelum products for building your streaming infrastructure.

Related documentation

Live Streaming features in Nimble, Live Transcoder for Nimble Streamer, WMSPanel API reference, RTSP playback, Build streaming infrastructure with Nimble Streamer, WMSPanel paywall,