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.
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.
Take a look at this tutorial showing the setup process for Icecast as an example.
If you need to secure your RTMP streams, you can also use SSL for RTMP transmission.
When transmuxing incoming RTMP streams, you can use Nimble Advertizer for server-side ads insertion. It provides a framework for inserting pre-roll and mid-roll ads into live streams for further output via RTMP, SLDP and Icecast with custom business logic and per-user ads.
Visit Advertizer web page to find out more.
If you need to change content parameters, like change the bitrate, use our Live Transcoder for Nimble Streamer to transform. It has high performance and low resource usage.
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:
Go to Control menu -> API setup -> Pull API tab.
Copy Client ID for further usage in your scripts.
Click on "Generate New Key" to copy API key as well. This will be used for further authorization.
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.
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:
Go to Control menu -> API setup -> Pull API tab.
Copy Client ID for further usage in your scripts.
Click on "Generate New Key" to copy API key as well. This will be used for further authorization.
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.
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:
Go to Control menu -> API setup -> Pull API tab.
Copy Client ID for further usage in your scripts.
Click on "Generate New Key" to copy API key as well. This will be used for further authorization.
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.
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 servers are unavailable. The call is made after 20 minutes of not getting sync-ups from the server.
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.
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.
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.
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.
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.
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.
First you may take a look at video tutorial about RTMP setup.
As you have some existing incoming RTMP streams, either published or pulled, you need to define them for Nimble Streamer for further usage, i.e. to "show" them to Nimble. So here are two possible RTMP options.
Option C. Set up RTSP incoming streams.
Read RTSP transmixing article to see how you can process incoming pulled and announced RTSP streams.
You may combine and have both types of streams. Let's assume you've created "live" application with a stream called "show". With RTMP applications and streams defined, you can proceed with setting up republishing.
3. Set up republishing
Go to Nimble Streamer / Live streams settings menu. Choose Republishing tab to see the setup options.
Now click "Add" to see the rule setup dialog.
RTSP republishing dialog is the same, only the "Destination stream parameters" field will not be there.
First two fields describe source of stream - the application and the stream which were previously defined on step 2.
Notice that you may leave Source stream name and Destination stream name fields blank, in this case Nimble will republish all streams from a given source to destination application.
"Destination" fields describe where the stream will be published. It's an address and a port of destination, application and stream names.
If you need some special parameters, then use "Destination application parameters". The "Destination stream parameters" field may be used for RTMP publication which requires special parameter or token, e.g. some CDNs like EdgeCast, see an example of setup.
In case if you need a RTMP login and password authorization, choose "RTMP" in "Authorization schema" drop-down box. This will open 2 new fields to enter user and password. This is a standard approach to authenticate of the publisher in cases when you publish into Nimble Streamer, Wowza or other servers.
If you need to some special authorization for publishing use cases, check "Some examples" section below.
When setting up complex infrastructure, you may need to setup big number or rules. To make it easier to edit, WMSPanel allows setting up multip
RTSP republishing dialog is the same, only the "Destination stream parameters" field will not be there.
le rules at once via simple JSON notation. In the same Republishing rules tab click on Multiple edit button to see this dialog.
RTMP republishing multiple edit.
Saving the text will apply the rules on affected servers.
Both RTMP and RTSP republishing starts working right after you set up any rule. If your RTMP source has live stream, it will be published to described destinations immediately. You can add, remove and modify rules without server restart any time. If you have multiple bitrate streams in an application, this works the same way. You just specify an application name only and all of its bitrate streams will be republished to bring ABR experience to the edge viewers.
Notice that if you have multiple streams republished from the same instance, you'll need to use rtmp_publisher_threads parameter. By default it's "1". Each publisher thread handles approximately 150 output republished streams. So if you need to handle more outputs you can add threads proportionally. Read params reference for more details.
If you use pulled RTMP or RTSP source, you may want to consider using pull streams fallback, which allows adding several sources, that will improve redundancy of your system.
Some examples
You can see some other examples of RTMP republishing:
We also recommend using our Live Transcoder for content transformation activities. It has performance equivalent to FFmpeg while having flexible web UI.
You may also consider re-publishing incoming RTMP streams with inserted ads. Nimble Advertizer provides a framework for inserting pre-roll and mid-roll ads into live streams for further output via RTMP, SLDP and Icecast with custom business logic and per-user ads. So if you create RTMP stream with ads insertion and pull it for further re-publishing, you can provide your target CDN with properly sponsored content.
Visit Advertizer web page to find out more about server-side ads insertion functionality.
Having that, you can create flexible delivery chains using Nimble Streamer for media hubs and WMSPanel for easy-to-use control panel. Install Nimble Streamer if you still haven't done that and contact us if your streaming scenarios need any updates of described functionality.
