The State of Streaming Protocols - August 2015

WMSPanel team continues analyzing the state of streaming protocols.

The metrics calculations are based on nearly 1.5 billion views. The stats are collected from 1900+ media servers (including Nimble Streamer and Wowza).

The most interesting fact of this month is that MPEG-DASH has bigger views count than SmoothStreaming. This is a result of continuous work of DASH community for improving tools and solutions. Being a member of DASH-IF, our team keeps on improving our MPEG-DASH feature set as well.

Other protocols share is pretty much the same with HLS being a leader with 69%. Check the chart below for more.

The State of Streaming Protocols - August 2015.

You can compare that to July stats below.

Building RTMP live streaming network via Nimble Streamer

Broadcasting companies often face with overcoming the bottlenecks of ISPs networks, when streaming online video. In addition to that, this companies need to take care about load balancing between the media servers to improve robustness.

You can create broadcasting network which is consist of origin and several edge servers to overcome those challenges. You can locate your origin server in a large data center and install your edge servers near your viewers. In this case you can create failover broadcasting network which allows to perform load balancing between origin and edge servers. Essentially, you are going to create you own Content Delivery Network (CDN). In this article we are going to show how to do that via Nimble Streamer and RTMP restreaming.


We will use the Adobe FMLE as a source of live video in our example. But you can use any encoder which supports RTMP streaming (e.g. FFMPEG).


To create a network which is described above, we will perform the following steps:
1. Set up streaming from encoder to origin.
2. Set up republishing from origin server to edge.
3. Set up edge server to receive RTMP stream from origin and to transmux it to HLS.

Install Nimble Streamer

We assume that you already have Nimble origin and Nimble edges installed. If not, please read about the process of Nimble Streamer installation in this page.

Setup streaming from encoder

Launch the Adobe FMLE application. Setup the "Device", "Format", "Frame Rate",  "Input Size", "Output Size" parameters. In our example we will use the following values:
Devece: Build-in web camera;
Format: H.264;
Frame Rate: 30.00;
Input Size: 320:240;
Output Size: 320:240.

Specify the "FMS URL" and "Stream" parameters for streaming RTMP to media server. For example,  rtmp://192.168.5.5:2935/origin and livestream. The names origin and livestream will be used later during republishing set up.

Click the "Connect" button and then click "Start" button. The encoder will be started.

Go to Nimble Streamer setup.

Setup origin server

Log in to wmspanel.com. Go to "Nimble Streamer" -> "Live streams settings" In the "Global" tab check the RTMP protocol checkbox and press the "Save" button.

Go to the "Interfaces" tab and click the "Add RTMP interface" button. Specify the port number for incoming RTMP streams in the appeared dialog (e.g. 2935) and click the "Save" button.

Go to "RTMP republish" tab and click the "Add" button. In the "Source application" and "Source stream" of the appeared dialog insert values from your encoder settings (see Setup streaming from encoder section). Specify the IP address of edge server in the "Destination address" field. Specify edge RTMP port number. Specify values for "Destination application" and "Destination stream" fields for edge server. Click the "Ok" button to save changes.

Then you need to define the edge server settings to allow receiving of RTMP stream from you origin server and for transmuxing RTMP to HLS for further streaming to your viewers.

Setup edge server

On the "Nimble Streamer" -> "Live streams settings" page choose your edge server in dropdown list left of "LIVE STREAMS SETTINGS" page name. In the "Global" tab set the HLS and RTMP checkboxes. Click the "Save" button.

Go to "Interfaces" tab and click the "Add RTMP interface" button. Specify the RTMP port number in the appeared field (1935 in our example). Verify that your edge server is chosen. Click the "Save" button.

After few seconds your edge server will provide output streams via HLS and RTMP protocols. To verify, go to "Nimble Streamer" -> "Live streams" and click on the number in "Outgoing streams" column in your edge server row.

The outgoing stream should appear with green "Online" label. Click on question mark sign to see your outgoing stream.

You can see your stream in the opened dialog. Choose proper protocol and player from dropdown lists in order make sure they work fine.

If you need to add more edges just repeat this procedure and specify your new edge "Destination address", "Destination application" and "Destination stream" in the "RTMP republish" tab of your existing origin server.

You can perform additional settings on edge servers to increase it's performance. Please read the "Nimble Streamer performance tuning" article for details.

We described RTMP republishing but Nimble Streamer has more capabilities to create origin-edge networks.

For RTMP you can use pull mode instead of publishing. You can use RTSP protocol in pull and/or publish mode (depends of which of your servers has open IP address). Also you can use MPEG-TS HTTP/UDP. You can combine these protocols, for example transmit stream to origin from camera (mobile device encoder) by RTSP protocol, use RTMP to republish from origin to some edges, and set up pulling MPEG-TS via HTTP for other edges. Then you can stream from you edges to viewers using HLS, MPEG-DASH and RTMP.

Multilevel hierarchy of media server can by used for large geographically destributed broadcasting networks when edge servers of middle layer will be configured as origins for the next edge servers layer.

If you need to change content parameters when streaming to end users, e.g. change the bitrate to create ABR streams, then you can use our Live Transcoder for Nimble Streamer. It has high performance and low resource usage so your edge server can handle trans-rating very well.

First you may take a look at video tutorial about RTMP setup.

It shows basic scenarios with RTMP processing.

Related documentation

Take a look at snapshots page on our website showing typical use cases of Softvelum products usage.

Power origin snapshot demonstrates how else you may build your delivery system using origin-edge approach. In addition, please get familiar with Reliable Low Latency Delivery with SRT+SLDP article in Haivision blog showing SRT and SLDP approach of building live streaming delivery.

Live Streaming features in Nimble, RTMP capabilities in Nimble Streamer, RTSP in Nimble Streamer, MPEG-TS support,  Nimble Streamer performance tuning, RTMP republishing via Nimble, Live Transcoder for Nimble Streamer, Build streaming infrastructure with Nimble Streamer,

Achieving low latency for live streaming using Nimble Streamer

Latency is what one part of media companies doesn't care about while the other part is really concerned with. If you provide a content, which requires real-time interaction or impact wide audience simultaneously, like great sports event broadcast, then latency is important for you. Actually, it isn't related to media companies only. At the moment, almost anyone can pick up a mobile device (modern, of course), install streaming application and broadcast themselves all over the globe.

In the video world, latency is the amount of time between the moment a frame is captured and the moment that frame is displayed. Low latency is a crucial requirement for many streaming scenarios. For example, surveillance systems require immediate reaction of observer on any restricted action. Remote participation in public auction doesn't make sense if buyer sees the situation happened several seconds before. Popular sports broadcast, video conferencing and remote quadrocopter piloting are also obvious cases.

There is no specific common value that defines "low latency". Instead, what is considered acceptable low latency is defined by a field of application. For example, 600 milliseconds delay is considered acceptable for remote auction participation system, while certain medical instrumentation require latency to be under 30 milliseconds. But of course those systems are completely different from a technical point of view and the medical system approach would be never suited for any distributed communication system.

Video content is passed through several stages of processing from being captured to being displayed for the viewers and each stage makes contribution to the total delay. The main contributors are the stages those require temporal data storage, i.e. buffering. It's imposed whenever processing must wait until some specific amount of data is available. Therefore, to achieve suitable latency for given system, we need to inspect the system's configuration, identify the major contributing stages and find a way to reduce buffering.

In this article we consider a system streaming H.264 1080p30 video content from a camera or encoder to a display over Internet using media server as intermediate. The processing pipeline can be broken down as follows.

1. Video capture
Short step, depending totally on hardware. Can be excluded from consideration, due to low impact on the delay (< 0.5 ms).

2. Encoding (video compression)
Very important step having influence on all consecutive steps. Hardware encoders are preferred over software ones from the latency point of view, because software codecs typically feature latency overheads related to memory transfers and task-level management from the OS. Correctly set up encoder doesn't introduce noticeable delay itself, but defines bit rate attributes and of resulting stream. The bit rate is considered of 2 types: variable (VBR) and constant (CBR).

The main advantage of VBR is that it produces a better quality-to-space ratio compared to a CBR for overall data. However, it requires more processing time and impose problems during streaming when the instantaneous bitrate exceeds the data rate of the communications path, thus increasing the decoders's buffer (as it was mentioned earlier, buffering is imposed whenever processing must wait for particular data). That's why CBR is mandatory for real-life low-latency video systems.

There is more to consider about CBR. In fact CBR isn't constant at any level, because H.264 video content consists of frames having different size. So encoder performs bit rate control processing to force producing the same amount of stream data over equal periods of time, called averaging periods. Bit rate control comes at the expense of quality. The less is averaging period and therefore decoder's buffer, the lower is quality of streamed video.

Production encoders provide various  bit rate control capabilities, which are intended to provide CBR with minimum impact on quality. Description of those capabilities is behind the scope of this article, but you may consider some key features to distinguish latency efficient encoders, including sub-frame Rate Control Granularity and Content-Adaptive Rate Control.

3. Streaming to media server over local network
This step contribution consist of local network delay, which depends on configuration and hardware, possible internal buffering of the encoder and streaming protocol overhead. In order to achieve best of this step, encoder should be properly configured to have at most few frames in it's buffer, and connected as close as possible to media server. Streaming protocol should be selected depending on encoder and media server capabilities. The recommended protocols having negligible latency overhead are: MPEG2-TS, RTSP or RTMP.

Also consider using WebRTC for low latency browser-based stream ingest.

4. Streaming to viewer's device over Internet
That's most interesting step and the biggest contributor for many scenarios. However, using efficient media server, real-time streaming protocol and reliable Internet connection this step can add comparable or even less delay, than the next one. The first contributor within this step is the media server's internal buffering, which is used during transmuxing of the input stream from encoder. The second is media server buffering related to streaming protocol specifics.

If you want to use HTTP-based protocol, such as HLS or MPEG-DASH to deliver video content to a viewer, be ready to significantly increase streaming latency. The reason is that HTTP-based protocols are designed to deliver media content chunked into segments. The segment size may vary depending on the protocol's parameters, but it shouldn't be less than 2 seconds. For example, the Apple HLS implementation has segment size equal to 10 seconds. So, if you use HLS in such configuration, only this step adds more than 10 seconds to your video streaming system's end-to-end latency.

You may suppose, that HLS or MPEG-DASH can be configured to achieve really low latency by reducing the segment size. Yes, that can be done theoretically but in a very specific environment, having almost no restrictions on networking and software capabilities, which is far away from real life. If you want to create low latency video system in real environment, you should use real-time streaming protocols, such as RTMP and RTSP to deliver content to your viewers.

The last part of this step, that can't be configured but must be taken into account is network delay and jitter. The network delay is simply added to the total latency value, while jitter is considered in the decoder's buffer size.

5. Decoding
It's not really obvious, that this step can be the major contributor. To make sure the decoder doesn’t run out of data during playback, the playout buffer must store all the data corresponding to one complete averaging period of stream with respect to network jitter. So, buffer may vary from containing several GOPs down to few frames, depending on encoder and network parameters. Many players consider the default minimum value for playout buffer equal to 1 second and adjust it during the playback. The least possible playout buffer can be achieved using hardware decoders (players) such as Raspberry Pi.

6. Displaying
This step is similar to the first step described above and is mentioned to complete the picture.

To sum up all the above, we have a real life example, which was provided to us by our customer. His company has built a video streaming system, that is used for remote auction participation and horse-race bets conducted in Australia. Bidders can participate from all over the world, but the main stage, having the best streaming performance is located in Macao.

The system's configuration is very simple. Hardware Encoder publishes stream to Nimble Streamer via RTMP protocol over local network. The outgoing stream is pulled by Raspberry Pi embedded RTMP player and is displayed on a large presentation screen in Macao. Ping time from the company's location in Australia to Macao is 141 milliseconds. Raspberry Pi RTMP player's buffer is set to 300 milliseconds. And the resulting end-to-end latency of the 1080p30 stream that is displayed in company's Macao location varies in range from 500 milliseconds to 600 milliseconds.

As you can see, a low latency video streaming system is built in a very easy way and has reasonable cost, which consists mostly of hardware expenses. Nimble Streamer is freeware, so you can build your own streaming system, using free or inexpensive products for encoding and playing. It may not have as high performance as the described streaming system, but suffice for your case.

SLDP low latency
Softvelum has its own ultra low latency technology called SLDP - Softvelum Low Latency Protocol. This is a protocol based on Websockets which supports ABR and carries any modern codec including H.264/AVC, H.265/HEVC, VP8, VP9 video with AAC, MP3, Opus audio. Server side is implemented in Nimble Streamer. SLDP player side is covered by HTML5 player along with Android and iOS free apps and SDK.

Feel free to visit this page for more details.

Also, check real-lief use case of using Haivision encoder with Nimble Streamer for delivery live streams over SRT and SLDP.

Related documentation

Nimble Streamer, Real-Time Messaging Protocol in Nimble Streamer, Performance tuning of Nimble Streamer, Larix Broadcaster, WebRTC support in Nimble Streamer

Live stream broadcasting to YouTube via Nimble Streamer

Perhaps, everyone knows about YouTube, the third most visited site in the world. As you know YouTube allows to perform live streaming from any source. Nimble Streamer can be used as stream source to YouTube. You can combine social power of YouTube and performance of Nimble Streamer.

You can use any encoder to create live stream (e.g. Adobe FMLE or FFMPEG). In this article we are going to describe the process of live streaming publishing from Larix Broadcaster mobile app to YouTube via Nimble Streamer. Nimble Streamer perfectly republishes RTSP and RTMP streams to YouTube.

Notice that you may also find useful Streaming to Larix Broadcaster YouTube Live article.

To create live broadcast on YouTube you need to perform the following steps:
1. Set up the YouTube live event;
2. Configure the stream republishing in Nimble Streamer;
3. Set up and launch Larix Broadcaster mobile app;
4. Launch your live event on YouTube and check the result.

Nimble Streamer supports AVC/H.264 and HEVC/H.265 codecs for ingesting into YouTube.

Read more about Enhanced RTMP spec adoption to support HEVC and AV1 codecs.

Set up the YouTube live event

Sign in to the YouTube Video Manager Live Events page and click "New live event".

In the "Basic info" tab of the Info and Settings page, enter the relevant information about the stream (title, description, date/time, location, and so on) into the fields. For Type, select "Custom (more encoding options)" and press the "Create event" button.

In the "Main Camera" tab of the event's "Ingestion Settings" page, under "Choose maximum sustained bitrate of your encoder", select the ingestion option that best represents your network and encoding capabilities (for our example we choose 300 Kbps - 700 Kbps (240p)). We use low bitrate to guarantee streaming in any mobile network.

Under "Select your encoder", select "Other encoders". Then, copy the "Stream Name" and "Primary Server URL" information to some text document. We'll need this information to configure Nimble Streamer. Press the "Save changes" button.

Now we need to perform media server configuration. Do not close YouTube tab, we will return to it later for live stream checking.

Configure the stream republishing in Nimble Streamer

Log in to wmspanel.com and go to "Nimble Streamer" -> "Live stream settings". Check the HLS and RTMP checkboxes in "General" tab and then press the "Save" button. You may specify Push login and Push password to protect you connection with mobile device. This login and password will be used in Larix Broadcaster settings. Press the "Save" button.

Go to "Interfaces" tab and press "Add RTSP interface" button.

Specify the port number in appeared dialog, this port number will be used in Larix Broadcaster settings. Select your media server instance and press the "Save" button.

Go to "RTMP republish" and press the "Add" button.

Specify the "Source application" and "Source Stream" parameters in the appeared dialog, they will be used in mobile application settings. In the "Destination address" field provide the value of "Primary Server URL" field from YouTube live event settings. Leave default "Port" value 1935. Type live2 in the "Destination application" field. Specify the value of "Stream Name" field from YouTube setting in the "Destination application" field.

So, the Nimble Streamer configuration is completed. Proceed to configure mobile application.

Install, set up and launch Larix Broadcaster

Read the "Larix Broadcaster mobile streaming setup and usage" article for YouTube streaming setup details.

Then return to YouTube streaming.

Launch the YouTube live event and check the result

Verify that YouTube is receiving and playing the stream. Go to the YouTube "Live Control Room" page for your event and click the "Preview" button to enable the YouTube to process the incoming stream.

When the "Stream Status" is GOOD click the "Start Streaming" button.

Your live streaming should be started on YouTube. To view your live stream click the "View on Watch Page" button.

Now you can verify that live steaming from your mobile device is launched on YouTube.

The quality of live streaming depends of your mobile device computing power and connection speed in your cellular provider network.

Larix Broadcaster is used as example in this article. Any device (DSLR or web-camera) can be used as a source for a live broadcast stream. Such applications as Adobe Flash Media Live Encoder or FFMPEG can be used as an your live video encoder. Nimble Streamer equally well streams and restreams RTMP both to YouTube and to any other CDN from any source of live video.

Troubleshooting

1. If the stream fails to appear at YouTube, try changing pixel format to yuv420p. YouTube requires this for all incoming streams, so make sure you have it.

2. YouTube requires both video and audio in your live stream. It cannot process video-only or audio-only input streams.

Further usage

You can see some other examples of RTMP republishing:

• Re-publishing in Nimble Streamer
• Streaming to Facebook Live
• Streaming to Periscope
• Publishing to Limelight CDN
• Publishing to Akamai CDN
• Publishing to Edgecast CDN
• Re-publishing to Wowza with proper authentication and ModuleSecureURLParams module.

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.

If you need to change the outgoing content in any way, like change the bitrate, use our Live Transcoder for Nimble Streamer to transform. It has high performance and low resource usage.

Related documentation

YouTube live stream setup, Softvelum mobile solutions, Installing Nimble Streamer, Live Streaming features in Nimble,

Larix Broadcaster mobile streaming from Android to Nimble Streamer

In this article we are going to show how to create video streaming from Android based mobile device via Larix Broadcaster. Larix Broadcaster is a free mobile application which can stream live video or/and audio to media server via RTSP, RTMP and SRT protocols. For our example, we will use Nimble Streamer because it is free and powerful media server with rich set of documentation.

Visit Larix documentation reference to see more articles about app setup.

Please also visit Larix Broadcaster web page for full feature set description.

To launch the live steaming from a mobile device via Larix Broadcaster you need to perform several steps:

1. Install Larix Broadcaster on your mobile device;
2. Install Nimble Streamer and make necessary settings;
3. Specify published URL in Larix Broadcaster;
4. Open output stream from the media server and check that everything works fine.

Install Larix Broadcaster application

Install  Larix Broadcaster from Google Play.

Run the app and allow access to your camera, microphone and file system by pressing the "Accept" button. Application will be installed in a few seconds.
When you launch Larix Broadcaster you will see preview window with settings gear button (marker with arrow blow), "Broadcast" big red button and a few others.
See the screenshots below.

Install Nimble Streamer

Nimble Streamer can be installed on all popular Linux distributions - Ubuntu, Debian, RedHat and CentOS. For rapid deployment and periodical updates the batch installation is used. There are separate installers for Windows and Mac OS X.

For more details about Nimble Streamer installation visit this page. You need to sign up WMSPanel account before starting the installation.

Now lets proceed to Nimble Streamer setup.

Setting up transmux RTSP stream to HLS and RTMP

Log in to wmspanel.com and go to "Nimble Streamer" -> "Live stream settings". Check the HLS and RTMP checkboxes in "General" tab and then press the "Save" button. You may specify Push login and Push password to protect you connection with mobile device. This login and password will be used in Larix Broadcaster settings.

Go to "Interfaces" tab and press "Add RTSP interface" button.

Secify the port number in appeared dialog (this port number will be used in Larix Broadcaster settings). Select your media server and press the "Save" button.

If you'd like to avoid publishing from un-authorized sources, you need to set up login and password which you may then use in this app. Go to Global tab to set up server-wide credentials or create application-specific credentials. Refer to this article for basic workflow setup.

So the basic Nimble Streamer configuration to work with Larix Broadcaster is completed. Proceed to configure mobile application.

Configure Larix Broadcaster application

Launch the Larix Broadcaster application on your mobile device and press settings gear button. You'll see setup screen.

Choose Connections then click on New connection to enter URL setup dialog.

Use the streaming URL which you got during the server setup

rtsp://192.168.5.5:554/live/stream

For RTMP it will be

rtmp://192.168.5.5:1935/live/stream

If you have username and password, enter then in Login and Password fields.

Press "Ok" button to save your settings.

You can check Larix documentation reference to see other options of creating streaming URL.

Now return to mobile application and press big red button button (make sure, that your mobile device has network connection, e,g, wi-fi).

Check the streaming

Log in to WMSPanel. Go to "Nimble Streamer" -> "Live streams" and click on the number under the "Outgoing streams" column.

Then click on the Question sign in the stream name row.

The video playback from mobile device starts automatically in the appeared dialog. By default the most popular streaming protocol (HLS) is used for video playback. HLS is supported by the most modern mobile devices. However it has a quite long latency (about 6 seconds). If you need to playback video with minimum possible latency, please use RTMP protocol. To configure minimum latency please read the "Nimble Streamer performance tuning" article.

Also you can play streaming URL with system player (e.g. VLC).

You can broadcast live video and/or audio from your mobile device via Larix Broadcaster to your web page, YouTube live or any other CDN.

Larix premium SDK

If you'd like to create similar Android app capable of media streaming, you can use our mobile broadcasting library and SDK which is the core of Larix Broadcaster. You will get Larix source code and a library for further UI customization.

Take a look at our instructions for streaming to YoutTube Live and streaming to Facebook Live.

Visit our documentation reference page for more Larix setup information.

Mobile delivery example

Take a look at our Mobile to mobile snapshot which shows the example of using Softvelum products for building mobile streaming and playback network.

Please contact us if you have any problems with installation.

Related documentation

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

Hotlinking protection in case of dynamically changing IP address

Streaming protection is crucial for companies selling premium access to their content. In most cases it is enough to use Hotlinking protection to allow viewing your media for authorized users only. This method is very reliable and is used for years, but sometimes it might require additional settings procedure.

Quite often, a viewer's ISP performs connection via proxy chain. In this case it is necessary to extract client's IP address from the request headers to set up Hotlinking protection. You can check the "Using WMSAuth paywall with CloudFlare and other proxies" blog article for more information about this technique.

In rare instances, ISP changes client's IP address for every request to media server. In this situation media server blocks access to stream, because media URL signature isn't correct due to viewer's IP address mismatch. Therefore, even authorized users can't access media content.

You can use Pay Per View framework (PPV) to protect your content and allow viewing video for authorized users in this case. It allows to specify any unique user identifier instead of IP address to generate media URL signature.

Using SMIL for adaptive bitrate VOD via MPEG-DASH

Nimble Streamer has an excellent MP4 to MPEG-DASH VOD transmuxing feature set. As an addition to this scenario, our customers were asking if we plan supporting multi-bitrate (adaptive bitrate) support for VOD. The de-facto standard for this kind of tasks is the Synchronized Multimedia Integration Language, or SMIL.

Nimble now has SMIL support for MPEG-DASH VOD just as it has for VOD HLS. Let's see how it's set up and how a user may stream ABR VOD.

Domain Lock techniques for media streaming in Nimble Streamer

Streaming process is closely related to your website promotion. You need to restrict the ability of copying your media-links for maximizing profits. This limitation is called Domain Lock and allows to keep your content unique. Here are basic techniques you can use for that.

Robust protection can be achieved via the Hotlinking protection. You need to add a media URL signature and this signed URL won't be played on other domains. For more information please check the "Hot-linking protection" feature page. However, this type of protection requires to modify your front-end source.

Sometimes abusers act as "man-in-the-middle", requesting web page from viewer's IP address, taking URL from that page and pasting it into its own media player via special applications. In this case you need to use more complex protection (you can check the detailed information about this technique in "Protecting media links from web scraping" article in our blog).

In some cases it is sufficient to play a media file only from specific URL, which contains your domain name. There is a simplified method that doesn't require changing your front-end source and protects your content from viewing from third-party web pages. This method is based on checking the crossdomain.xml file by media player integrated in web page (see the Cross-domain policy and access control in Nimble Streamer blog article for details).

One more way to secure your stream is to use WMSAuth rules which is described below. This method allows to view video which has a specific domain name in the URL. This restricts the domain mapping to your domain and allows to track on which web resources URLs to your content is included.

You can also combine the above methods to create multi-level protection for your content. These methods completely cover more traditional approaches used in other security systems. They assume that you need to add specific domain names to restrict streaming while WMSPanel feature set is more flexible and powerful.

Let's see how Domain Lock can be implemented in Nimble Streamer using WMSAuth rules mentioned above.

You need to create two rules:
1. Allow viewing for your domain;
2. Deny viewing for other domains.

We assume that you already have streams those should be protected.

To set up streaming you could check the following articles:
HTTP Live Streaming (HLS) as live origin;
HTTP Live Streaming (HLS) for Video on Demand;
Streaming VOD from remote HTTP storage via Nimble Streamer.

Set up streaming rules

You need to specify the IP range before setting up the rules. We are going to allow all possible IP addresses for the first rule.

Set up IP range

Go to "Control" -> "WMSAuth paywall setup" and press the "MANAGE CUSTOM IP RANGES" link.

Press the "ADD IP RANGE" link in the appeared dialog. Give the Name and the Description for your IP range, then press the "Save IP range" button.

Specify the IP address range using CIDR notation. To set all possible IP addresses type 0.0.0.0/0  and press the "Add range" button.

After you add the IP range for all possible IP addresses (0.0.0.0 - 255.255.255.255) you need to add your media server in WMSAuth group and set up the rules.

Adding media server in WMSAuth group

Go to "Control" -> "WMSAuth paywall setup".
Press the "Add WMSAuth group" button in upper-left corner of dialog.

Type the Name of your group (e.g. Domain Lock) and Description in the appeared dialog. Then press the "Create WMSAuth group" button.

You need to assign one or more servers in the WMSAuth group in the appeared dialog.

Choose your media server in the dropdown list and press the "Assign server" button. You should see a message that server is already assigned. If you want to assign more media servers to this WMSAuth group just repeat the steps above.

Set up the allowing rule

Press the "Add rule" button to see a dialog for adding the rule.

First we should create the rule which allows access to media files only for your domain (e.g. example.com). Give a name to the rule (e.g. Allow streaming for example.com).

In the "Virtual Host" field specify the name of your domain (you can use POSIX regular expressions to specify parameters in this field).
Add the IP range which we created at the "Set up IP range" section in allow list. Choose the IP range ("All IP addresses" in our case)  and press the "<<Add" button. Our IP range should appear in "Allow countries and IP ranges" list. Press the "Create WMSAuth rule" button.

Next you should create the rule that deny access for all other domains.

Set up the denying rule

Press the "Add rule" button again to see a dialog for new rule.

Specify the rule name (e.g. Deny streaming for other domains). Scroll down to the "Links re-publishing protection" section and specify a strong enough password.

Press the "Create WMSAuth rule" button.

That's it!

As a result, we have two rules which allow viewing content only from your domain (example.com in our case) and block this ability for other domains.

Please contact us if you have any problems with installation. You are also welcome to suggest any improvements or ask any questions, we're opened for collaboration.
You can also read and post at WMSPanel company forum to find use cases and answers from other users and companies.

Related documentation

Paywall feature set, Prevent files download while streaming VOD, CORS and access control in Nimble Streamer,

Prevent files download while streaming VOD

Broadcasting companies pay considerable attention to protect their content because nobody wants to loose profit. One of the most urgent problems in internet streaming is blocking the ability to download  media files. If media file is streamed via Progressive download protocol then this file can be easily downloaded. To restrict the ability to download media files by most of your users you can use more complex streaming protocols such as HLS or MPEG-DASH. Progressive download streaming should be blocked.

You need to set up a rule in WMSPanel to protect your media files from downloading.

Setup

First you need to create a rule that deny Progressive download streaming.

We assume that you already have a preconfigured media server that performs Progressive download and HLS streaming.

Set up rules

You need to add your media server in WMSAuth group to set up a rule. Log in to WMSPanel, go to "Control" -> "WMSAuth paywall setup". Press the "ADD WMSAUTH GROUP" link in the upper-right corner of the dialog.

Specify the group name (e.g. PD_restriction) and give a short description for it in the proper fields.

Then press the "Create WMSAuth Group" button. The new dialog which allows to assign one or more media servers should appear in just created WMSAuth group. Select the media server from drop-down list and press "Assign" button.

You should see the message that server is already assigned. If you want to assign more media servers to this WMSAuth group just repeat the steps above. You can start to create rule that helps to avoid simple media file downloading after assigning media servers to your WMSAuth group. Press the "ADD RULE" link in the bottom right corner of the page.

The rule creation dialog should appear. Give a name for your rule (for example "Protect progressive download by password").

If you need to set the Geo-blocking, IP range restriction, limitation of connections or domain name (Virtual host) for the same rule just fill the proper fields (see the screenshot):

The detailed information about these settings can be found in "Restriction solution for geo, IP range and connections" article.
You can specify vHost, application or stream fields using POSIX regular expressions.

In this case we are going to apply this rule to all possible links, so we leave all the above fields empty.

To set up the Progressive download blocking rule, you need to define the following elements:

• Password - a secret key that would be known for both web server and media server.
• Protocols - which of media server supported protocols is this rule applied. You may want to protect particular protocol while other protocols might have another protection scheme.

Just specify a strong enough password and check the Progressive download checkbox (leave all other protocols unchecked). To save the rule press the "Create WMSAuth rule" button.

Now we have created the rule that blocks downloading media files via Progressive download.

Related documentation

Hot-linking protection and domain locking, Paywall features for Nimble Streamer and Wowza