We expectantly see the increase of HLS share (it's 70% now). The share of RTMP (22%) has been decreasing along with RTSP (2.5%) while progressive download showed good growth (~5%).
All these metrics calculations are based on 3 billion views.
Protecting web clients against vulnerabilities is one of the core features for safe web browsing. This is why popular platforms use various mechanisms to improve the security. This also includes video playback scenarios. Typically it's covered cross-origin resource sharing (CORS) mechanisms. Nimble Streamer needs to handle those cases.
Cross-domain policy file
For instance, many web media players use the "crossdomain.xml" file. It's a cross-domain policy file which gives the player permission to talk to servers other than the one it's hosted on.
As per Adobe, a cross-domain policy file is an XML document that grants a web client permission to handle data across multiple domains. When a client hosts content from a particular source domain and that content makes requests directed towards a domain other than its own, the remote domain would need to host a cross-domain policy file that grants access to the source domain, allowing the client to continue with the transaction.
Nimble Streamer allows specifying this file content. It is done via configuration file located at /etc/nimble/nimble.conf. Please refer to Nimble config file format for more details.
Use the following parameter to specify the domain within the XML file:
Once it's ready, save it to local directory and point Nimble to it via crossdomain_xml parameter:
crossdomain_xml = /etc/nimble/crossdomain.xml
The file content will be returned to a client as soon as it's requested.
Cross-origin resource sharing
Another technique is cross-origin resource sharing. Players may require Access-Control-Allow* headers in server responses. You can use the following parameters for that:
WMSPanel reporting for media servers of various types has several types of metrics. Geo-location reporting is one of the most popular ones. It's part of daily statistics for particular data slice and it shows total number of connections established within selected dates range.
Today we introduce a highly anticipated improvement - geo-location stats how have extra information about regions within countries. Best example is a state within countries the United States of America or Brazil.
You can go to Reporting -> Geo stats menu to see a reporting page. This page contains a map representing views share and a list of countries, each having total number of connections and percents of share. You may select dates range to report and also export your data via CSV file.
List of countries in geo-location reporting.
Clicking on country name shows list of regions (e.g. states) list, each having total connections number and percentage.
List of states for USA in geo-location reporting.
Clicking on a region shows the list of cities in it, each having its own stats.
List of cities of a country in geo-location report.
With the additional regions metrics you will have full picture of your audience in any given country.
Secure streaming is required in several scenarios in our customers' environments. This is why we are working on implementing security feature set. One of the high-demand features is SSL streaming for HLS, MPEG-DASH, MPEG-TS, Icecast, progressive download and SLDP via Nimble Streamer. In this case streams are available via HTTPS protocols stack.
To set up HTTPS streaming, you need to generate SSL certificate first. Usually SSL certificates are purchased by some provider like GoDaddy and these companies provide plenty of information about this process.
In this article we assume:
you already have a certificate for further setup,
your certificate and its key are located at your server and
they are ready for further usage.
You will need to make changes to Nimble Streamer settings to make it work for your media streaming. These settings are stored in /etc/nimble/nimble.conf file, you should read configuration parameters reference page for more details about parameters' control, just click on SSL tag.
Follow the steps described below to enable SSL-powered streaming.
ssl_port parameter - this is port number for SSL connections. Example:
ssl_port = 443
By default, Nimble Streamer handles connections via the port specified in config at "port" parameter. Usually it's port 8081. If you need Nimble Streamer to handle connections via SSL only, please set this parameter to 0, like this:
port = 0
If it has some other value, Nimble still handles streaming connections through 2 ports via both HTTP and HTTPS. If you remove "port" parameter, Nimble will use default value "8081"
ssl_protocols parameter specifies what SSL protocols are used. It requires the list of protocols separated by spaces, e.g.
ssl_protocols = TLSv1 TLSv1.1 TLSv1.2
Full list is: SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2, default protocols are TLSv1, TLSv1.1 and TLSv1.2.
HTTP/2 is supported by Nimble Streamer and it can be used only when streaming over HTTPS. In order to process HTTP/2 requests, use this parameter:
The following parameters define the usage of SSL certificate for your Nimble Streamer instance:
ssl_certificate is full path to certificate located at your server;
ssl_certificate_key is full path to certificate's private key located at your server;
ssl_certificate_key_pass - if you use encryption for your certificate key, you need to specify a password here. This is optional parameter, so if you don't use encryption, just don't add it into the config.
Besides server-wide certificate, you can assign specific certificates and keys to a certain set of domains. This is handled by adding appropriate ssl_server sections to the config. Each section may have the following items.
server_name describes server name patterns to apply certificate to - see the description below;
ssl_certificate,ssl_certificate_key,ssl_certificate_key_pass and ssl_http2_enabled as described above.
server_name element defines the host names where the certificate will be applied to. Multiple names are separated by spaces.
There are 3 types of name patterns you may use:
exact match works when you specify the exact name of the host you want it to work for.
wildcard match name may contain an asterisk only on the name’s start, and only on a dot border. It will match all domains which start with anything before the asterisk with the exact name after it. So wildcard "*." may be used only once in one name pattern. Example: *.wmspanel.com matches for all <anything>.wmspanel.com host names.
regexp match starts with '~' character and consists of a Perl-compatible regular expression describing the name pattern for all required host names.
You may have any number of ssl_server sections in your Nimble Streamer config. The first section will be the default one in case of multiple server_name parameters match the same host.
Nimble Streamer has certificates cache. So it takes each SSL certificate from cache if it's already there, and it doesn't re-load it on each connection.
If you need to reload certificates in real-time without re-starting Nimble Streamer, you may use Nimble API. It has /manage/reload_ssl_certificates method for this. This method receives POST request and Nimble Streamer re-loads all current certificates. If they are loaded successfully, all new connections will use this new set, even though some of them may have been used previously. Currently connected clients will keep previous certificates for their current sessions until they are closed.
Example of API call:
curl -X POST http://127.0.0.1:8083/manage/reload_ssl_certificates
Some browsers or client software may fail to recognize your certificate even though it's valid. In this case you may need to get SSL certificate chain (root and intermediate certificates) combined into a single .crt file and use that file with Nimble Streamer. If you use Linux, you can do that by concatenating both files using this command:
One of the most popular feature sets of Nimble Streamer and WMSPanel is content protection. It allows creating easy-to-use paywalls and embedding them into existing websites. Major available features are hotlinking protection and pay-per-view framework.
Hotlinking protection
Hotlinking protection allows preventing "links hi-jacking". When you publish some media behind the paywall, anyone can take the direct URL to content and pass it to anyone else. Nimble Streamer allows preventing that. This is how it works.
You modify a webpage which shows a media link to include a "signature" - the URL parameter which is based on a secret password and viewer's IP address
You also set up protection rules in WMSPanel where you describe which streams are affected and what password will be used.
When a viewer requests the media from the media server, Nimble Streamer checks the signature against the viewer's IP and encrypted password. If they match, the connection is established, if they don't then it will be forbidden.
This scenario works already for HLS and progressive download already. Now it works perfectly for MPEG-DASH.
Hotlinking protection for MPEG-DASH workflow diagram.
Nimble Streamer team keeps exploring MPEG-DASH capabilities. In addition to MPEG-DASH VOD streaming introduced, we've continued moving towards live streaming support. Today we release RTMP to MPEG-DASH transmuxing. Nimble Streamer may take published RTMP as well as pull stream from RTMP source and transmux it into DASH in live mode.
To use this capability you need to install Nimble Streamer and then define RTMP settings - either specify RTMP publish settings or RTMP pulled streams. Once it's done, you'll be able to get live MPEG-DASH streams for single bitrates as well as make ABR streams from them.
NEW: Nimble Streamer supports AVC/H.264, HEVC/H.265 and AV1 codecs for re-packaging into MPEG-DASH. Read more about Enhanced RTMP spec adoption for more information.
To take RTMP streams for transmuxing, you need to specify available sources. After that Nimble will pick them up and start producing HLS chunks for immediate use.
Go to Nimble Streamer -> Live Streams Set Up menu to see list of available servers.
Available Nimble Streamer instances.
Then choose a server to make settings. Most of actions may be applied to multiple servers at once so you can choose any of them.
Incoming streams settings.
Now click on RTMP settings button to proceed with any of 2 possible scenarios:
a) get published RTMP streams;
b) pull RTMP streams.
You may combine both scenarios and process both types of incoming streams to get both HLS and MPEG-DASH outgoing streams.
2.a Publish scenario: Set up RTMP publish settings
Applications' settings
Going into RTMP settings page, first you'll see several tabs. First one you need is Global. These are global server settings. These are as follows.
Default chunk duration used for outgoing streams
Protocols which will be produced - you can generate all 4 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.
Global server 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' settings.
New application settings.
You may apply new application settings to several Nimble servers instances. Just click on their names' checkboxes in the dialog - the setting will be applied to each server within a few seconds.
Add interface
To make Nimble Streamer capable of getting published RTMP streams, it needs to listen to a specific interface - address and port. Go to Interfaces tab and click on Add interface.
Interfaces list.
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.
You may also apply new settings to multiple servers to convenience of administration.
Adding new interface to process RTMP publishing.
If you have only published streams, then you can move to step 3.
2.b Pull scenario: Set up RTMP pull settings
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.
Pulled RTMP streams list.
There you click on Add URL button to see new dialog for adding new stream to transmux. There you enter:
URL - the address of RTMP stream.
Fallback URLs - 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.
Application and stream are the the names which will be used for DASH stream URL.
As already mentioned in other settings, you may apply this setting to multiple servers - just click on their names' checkboxes.
New pulled RTMP stream settings.
Once it's saved, you'll see it in settings list.
New stream in the list.
3. Outgoing streams
Having incoming streams defined and processed, you may now use the results of Nimble Streamer transmuxing for streaming your content via MPEG-DASH and any other protocol which you selected in global or application settings, e.g. HLS.
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.
Available outgoing streams list.
To use the outgoing stream for playback, click on question mark icon to see Sample URL for player dialog.
MPEG-DASH and HLS stream names.
Here you see links for 2 protocols which you defined for this server in global settings - MPEG-DASH and HLS.
With streaming URLs ready for further use, you may now add them to your player. MPEG-DASH streaming of Nimble Streamer was tested with DASH reference player as well as with Bitmovin's bitdash™ player. If you find any other players more suitable for you - please share your experience with us.
4. Adaptive bitrate for MPEG-DASH streams
Another feature set common across HLS and MPEG-DASH streaming is adaptive bitrate streaming. It allows you to give a stream containing sub-streams with different bitrates so a player or a viewer could select appropriate bitrate according to their network conditions.
To define ABR streams, click on Adaptive stream area on a chart or ABR link on top.
ABR settings page.
Click on Add ABR stream from RTMP sources button.
Here you need to define the following fields:
ABR application name and stream name - they will be used for playback by your viewers.
Source application name and stream name - you can add several sources from currently available single-bitrate streams. Just start typing names to see gestures listing available sources.
Streams sorting in playlist:
Manual - as defined in list;
By bandwidth - descending;
By bandwidth - ascending.
As in other Nimble settings, you can select multiple servers to apply these settings to. Thus you can specify ABR stream for your entire infrastructure.
Having set up the stream, you will see it in the list. Once it's synced up, it'll be shown in "online" state. To start using it, click on question mark icon to see Sample URL for player dialog.
URLs for MPEG-DASH and HLS ABR streams.
Use these URLs for further playback in your DASH-capable or HLS-capable players as previously described on step 3.
You may also consider using RTMP streaming API to control this behavior remotely.
What's next
If you need to change content before transmuxing into ABR, use our Live Transcoder for Nimble Streamer to transform. It has high performance and low resource usage.
Using Nimble Streamer in your streaming infrastructure, you can get DASH streaming statistics via WMSPanel reporting SaaS. It has built-in support so you don't need to parse logs or anything like that - Nimble will send required metrics to central service for your convenience.
Also take a look at video tutorial about RTMP setup.
It shows basic scenarios with RTMP processing.
WMSPanel is currently an associate member of DASH Industry Forum. We will extend DASH feature set with all scenarios available for HLS. This includes features like live streaming from MPEG-TS (both UDP and HTTP). Please contact us if you need to cover some specific use cases or if you just have any feedback about DASH handling in Nimble Streamer.
Through past several years, MPEG-DASH has gone a long path from a basic concept to industry standard. Thanks to contributions from a lot of companies and stakeholders, this technology can now be used in a variety of scenarios, including video on demand.
Nimble Streamer team is up for HTTP streaming technologies like HLS or Icecast. So moving towards DASH is a great step forward to better user experience for our customers who would like to try advantages of this HTTP-based protocol.
Today we introduce VOD playback for MPEG-DASH in Nimble Streamer. Is allows transmuxing MP4 files to DASH stream on-the-fly with very low resources consumption. It supports both time-based and number-based manifests for VOD DASH.
You can follow these easy steps to set up DASH VOD streaming.
Upload your content to a designated location on the server. This needs to be MP4 file with H.264, H.265 or AV1 video and AAC or MP3 audio.
The user called "nimble" must have read access to this directory and its contents. Let's say it would be /home/user/video directory
3. Set up VOD streaming
Click on Nimble Streamer -> VOD & re-streaming routes menu to open streaming routes setup page.
Click on Set up VOD streaming button to see the following dialog.
Adding VOD transmuxing route for DASH, HLS and progressive download.
In section 1 "Where incoming requests are coming" you may see the following fields.
Path field contains the URL name part which will then be used for accessing streams. You need to enter some value here, it shouldn't be blank because it's used for stats calculation purposes. It's /vod/ in this example.
You may also set up Domain if you'd like this route to process only specific domains. You may leave it blank if you don't plan putting any limitations.
In section 2 you need to fill in Path field with full path to your content in your file system.
Then you need to select which Nimble Streamer instances will get these settings. So you may apply them to any number of instances at once in just a few clicks.
Once the route is set up, you may request any of the uploaded files via any protocol you need:
With streaming URLs ready for further use, you may now add them to your player. MPEG-DASH streaming of Nimble Streamer was tested with DASH reference player as well as with Bitmovin's bitdash™ player. If you find any other players more suitable for you - please share your experience with us.
Using Nimble Streamer in your streaming infrastructure, you can get DASH streaming statistics via WMSPanel reporting SaaS. It has built-in support so you don't need to parse logs or anything like that - Nimble will send required metrics to central service for your convenience. Check also MPEG-DASH live streaming via RTMP transmuxing.
Troubleshooting
Nimble Streamer internal transmuxer buffer sometimes may not be enough to fit generated HLS chunk. This may lead to this error in Nimble Streamer logs:
You can also take a look at the video where Jan Ozer of Streaming Learning Center and Yury Udovichenko of Softvelum discuss pros and cons of dynamic packetizing of live, VOD and DVR content. It gives more details about Nimble Streamer VOD streaming.
