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.
Let's see how to set this up.
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.
It shows basic scenarios with RTMP processing.
1. Install Nimble Streamer
Follow this easy to use instruction to set up Nimble Streamer instance.
2. Define RTMP/RTSP streams
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 A: Set up published RTMP incoming stream
Read Streaming RTMP to HLS article describing how to get published RTMP stream.
Option B: Set up pulled RTMP incoming stream
Read Pull RTMP for ABR HLS transmuxing article to see how you can pull existing RTMP stream by Nimble.
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.
"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.
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
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.
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.
 |
| RTMP republishing multiple edit. |
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:
More capabilities
If you need to secure your RTMP streams, you can also use SSL for RTMP transmission.
We also recommend using our Live Transcoder for content transformation activities. It has performance equivalent to FFmpeg while having flexible web UI.
Visit Advertizer web page to find out more about server-side ads insertion functionality.
For other live streaming scenarios, check our live streaming use cases.
Related documentation
Live Streaming features, Live Transcoder for Nimble Streamer, RTMP feature set, RTSP feature set, Easy ABR HLS setup from RTMP, Pay-per-view for Nimble Streamer,
Dear Team,
ReplyDeleteCould you please help us for the detail of RTSP re-publishing? Because It is not working when we push a RTSP stream from ffmpeg. (RTMP is ok)
Thanks & Best regards
Please post all details to our helpdesk https://wmspanel.com/help We do not provide support in social media comments.
Delete