Nimble Streamer also allows decreasing network load from source to edge server by setting up RTMP, RTSP, SLDP and Icecast live streams pull on demand, i.e. by pull by request from user.
In large networks not all your streams are requested by all users all the time. But all of these streams continue to be pulled from origin server, that is why fee for the traffic is continuously charged.
Nimble Streamer allows to optimize usage of bandwidth via setting up RTMP, RTSP or Icecast streams to be pulled only if users request to view these channels via one of supported output protocols:
- HLS;
- MPEG-DASH;
- RTMP;
- RTSP;
- SLDP;
- Icecast;
- MPEG-TS.
For example, large content providers can offer thousands of media URLs of live video, but only part of them will be requested by users at certain periods of time. So if 1 viewer is requesting an RTSP stream via HLS and another one requests it via Icecast, then 1 stream will be pulled via RTSP and transmuxed into HLS or any other protocol for output as long as these viewers watch the stream.
The same approach is relevant when using CCTV cameras which transmit video streams over RTSP protocol. Usually in this case only about 20-30 cameras are displayed on the monitor, but overall cameras count may be several hundreds (i.e. for the systems like "Safe town").
Setup procedure
First you may take a look at video tutorial about RTMP setup.
It shows basic scenarios with RTMP processing.
You can perform the advanced Live pull settings setup via Nimble Streamer. This setup allows you to pull only those streams which are requested by viewers and also you can configure media server to pull any streams for the certain application.
We'll show RTMP input as example but you can apply this to RTSP and Icecast/SHOUTcast input as well.
To perform these settings go to "Nimble Streamer" -> "Live streams settings" -> "Live pull settings" and click the "Add RTMP URL" button.
Specify the pulled live video URL in the appeared dialog. You can specify fallback URL (optional). Specify the "Output application" and "Output stream" fields.
For per-request pull of streams, you also need to specify the "Idle time" value. If the viewers have stopped watching the stream then Nimble Streamer will keep pulling the stream from the origin for this period of time and if nobody else connects to it, the transmission from the origin is stopped. If you need constant stable connection, you don't need to use this option.
This configuration can significantly save the bandwidth if your streams are rarely used. At the same time latency, associated with the resumption of the stream, will not exceed 200 ms. If your streams are constantly demanded, the enabling of this function will not give the advantages. For more details about live streaming latency please read "Achieving low latency for live streaming using Nimble Streamer" blog article.
If you want to speedup the playback start time, you may also consider improving buffer setting. This origin-side setup will allow improving this behavior.
However, you should be very careful when using dynamic stream names. The application could have several hundreds of streams (e.g. video cameras), and not all of these streams need to be pulled from the source.
This creates the risk that users can force media server to pull a huge amount of streams by their actions. It can cause of unnecessary using of bandwidth and computational resources. In order to prevent the use of such scenario, you can create the WMSAuth rule, which allows to take and to play only those streams that the user is allowed to access. For more information about restricting access by streams names please read "Hotlink protection with stream-based signature" article.
If you need to secure your RTMP streams during transmission over public networks, 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.
Specify the pulled live video URL in the appeared dialog. You can specify fallback URL (optional). Specify the "Output application" and "Output stream" fields.
For per-request pull of streams, you also need to specify the "Idle time" value. If the viewers have stopped watching the stream then Nimble Streamer will keep pulling the stream from the origin for this period of time and if nobody else connects to it, the transmission from the origin is stopped. If you need constant stable connection, you don't need to use this option.
You can setup receiving of any RTMP, RTSP or Icecast streams by checking the "Dynamic stream name" and specifying only application name in the Primary URL (i.e. rtmp://remotehost:1935/live). In this case, any stream belonging to the specified application (e.g., live) is pulled from a source and is processed as described above. This allows you to specify the entire set of possible streams instead of one stream, which greatly simplifies the configuration.
Once the server is configured, the first user requesting the video over HLS, RTMP or other supported protocol will initiate a pull session.
This configuration can significantly save the bandwidth if your streams are rarely used. At the same time latency, associated with the resumption of the stream, will not exceed 200 ms. If your streams are constantly demanded, the enabling of this function will not give the advantages. For more details about live streaming latency please read "Achieving low latency for live streaming using Nimble Streamer" blog article.
If you want to speedup the playback start time, you may also consider improving buffer setting. This origin-side setup will allow improving this behavior.
Security settings
However, you should be very careful when using dynamic stream names. The application could have several hundreds of streams (e.g. video cameras), and not all of these streams need to be pulled from the source.
This creates the risk that users can force media server to pull a huge amount of streams by their actions. It can cause of unnecessary using of bandwidth and computational resources. In order to prevent the use of such scenario, you can create the WMSAuth rule, which allows to take and to play only those streams that the user is allowed to access. For more information about restricting access by streams names please read "Hotlink protection with stream-based signature" article.
If you need to secure your RTMP streams during transmission over public networks, you can also use SSL for RTMP transmission.
Ads, transcoding and more
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.
Related documentation
Live Streaming features in Nimble, Live Transcoder for Nimble Streamer, RTMP feature set, RTSP feature set, WMSPanel paywall framework, Icecast features
No comments:
Post a Comment
If you face any specific issue or want to ask some question to our team,
PLEASE USE OUR HELPDESK
This will give much faster and precise response.
Thank you.
Note: Only a member of this blog may post a comment.