July 1, 2020

Q2 2020 news: SRT PASSet, RIST, DRM and Larix Broadcaster on Drafts

Softvelum team kept working during this intense Q2 of 2020 and we have several important updates for our products.


Nimble Streamer

First we'd like to address a Nimble Streamer issue which appeared back in May. Our external dependency package - libjson - introduced a fatal issue which caused multiple malfunctions across the entire Ubuntu users community. Within a few hours we detected a problem and released a fix which allowed us to overcome any consequences. We sent proper announcement to our Linux users so our clients got proper assistance on time, so most of them were not affected by this. 
That's just one of the advantages of being our subscribed customer.

Now let's see some new features.

Nimble Streamer SRT Publisher Assistance Security Set (SRT PASSet) is our new security and management framework for SRT. These are major capabilities:
  • Process incoming streamid.
  • Make per-server, per-application and per-stream authentication with user and password.
  • Apply any SRT parameters to every individual publisher and each individual stream.
  • Apply allow and deny lists for IP addresses on server and stream level.
  • Manage published streams via the publish control framework.
This provides our customers with great flexibility for publication control, especially for handling mobile publishers. Read these articles for more details:

Speaking of SRT, we've also added Forward Errors Correction support as part of our freeware feature set. FEC filter is still under development by the SRT community and we've added it per requests from our customers, so please use FEC filter feature at your own risk.

Nimble DRM has finally become available this quarter. It covers these features:
  • Google Widevine™ support to protect MPEG-DASH.
  • Microsoft Playready™ support to protect MPEG-DASH.
  • Apple FairPlay™ support to protect HLS.
  • Widevine Cloud Service support with key rotation.
  • EZDRM’s DRM-as-a-Service support for Widevine, FairPlay and Playready.
  • Verimatrix™ VCAS key management support to protect HLS with AES.
DRM is a premium feature set of Nimble Streamer.

Both SRT PASSet and Nimble DRM are part of Nimble Addenda - a premium package which also covers Nimble Advertizer. Package license costs just 50 USD per month per server and gives extended feature set with proper support.

RIST protocol support. A new protocol has been introduced by RIST Forum. RIST provides an open, interoperable and technically robust solution for low-latency live video over unmanaged networks.
Read this setup article to try it in action.

Last but not least, we've released an article on Handling fuzzy FPS to get proper bitrate output with some sources that produce streams with uncertain frame rate, like mobile encoders.


Larix Broadcaster

Our mobile team made a number of updates.

Larix Broadcaster app was mentioned in a few articles on SVG News:
Softvelum team was very proud to see Larix Broadcaster in such awesome use cases.

Now, let's look at new features.

We've released Larix Grove - an easy to use format which allows distributing streaming setup details. You use our web wizard to create a URL and a QR code to send to your publishers. It's supported in Larix for Android and iOS.

Larix Broadcaster for iOS is now able to provide Dual/Triple camera system support on iPhone 11+, including wide-angle and telephoto camera.
We also have multiple cameras streaming (via picture-in-picture and side-by-side) on modern supported devices in our beta version. You can use this link to install TestFlight and try it in action.

Larix for Android now has USB OTG camera support if the hardware vendors give that capability.
You can also go to Google Play and Join Beta to get early access to new features like multiple physical cameras on Android 10+.

Our YouTube channel also has a number of new videos explaining some of Larix features and other company updates



If you'd like to get our future news and updates, please consider following our social networks: Telegram channelTwitter, Facebook, LinkedIn and YouTube.

June 28, 2020

Setting per-stream authentication and parameters with SRT PASSet

SRT Publisher Assistance Security Set - or SRT PASSet - is a premium feature set of Nimble Streamer which allows extending authentication and control capabilities for SRT input.

The key capabilities of SRT PASSet are as follows:
  1. Accept streamid parameter.
  2. Make per-server, per-application and per-stream authentication with user and password.
  3. Apply any SRT parameters to each individual stream and even individual publisher.
  4. Apply allow and deny lists for IP addresses on server and stream level.
  5. Manage published streams via publish control framework.
We have an article about per-user authentication for per-server and per-application processing and publish control the same way it's available for RTMP and RTSP, you can use that approach for various cases. However, more complicated cases of per-stream authorization and SRT parameters require different approach.

This article describes the following capabilities setup:
  • Accepting "streamid" parameter in "<application>/<stream>" format.
  • Creating configuration file for controlling per-stream settings.
  • Setting server-wide allow and deny lists or IP ranges.
  • Setting per-stream settings with allow/deny lists, user/password authentication and custom per-stream SRT parameters.

The key element of this feature set is a separate configuration file which has JSON-based format for describing all settings on global and per-stream level. So this article describes how this feature is enabled and set up.

A few notes
These features are applied when Nimble Streamer works as a receiver of SRT in Listen mode. Other receiving modes such as Pull and Rendezvous are not supported by PASSet feature set.
Current article assumes you have a WMSPanel account, you have a Nimble Streamer instance registered in your account and that instance is capable of receiving SRT streams via a designated port.

1. Activate Nimble Addenda


SRT PASSet is available as part of Nimble Addenda premium package and it requires a license to operate and a subscription to cover that license. That license also enables a number of other features like DRM and server-side ads insertion.

So if you don't have Addenda license yet, follow these steps:
  1. Go to Settings menu and open Addenda licenses tab
  2. Click on New Addenda subscription and select number of licenses, then click Next and once you see final cost, click on Pay now button.
  3. Follow the payment procedure and once you complete it, you’ll see your active licenses.
  4. Click on the license to see the registration procedure.
  5. Log into the server which has Nimble Streamer installed and which you will use as your host.
  6. Use the registration procedure to make it work.
That's it. Now all features described below will become available.

2. Set up SRT listener


In your WMSPanel account, click on Nimble Streamer -> Live Streams Settings menu and open MPEG-TS In tab.


Here you need to click on Add SRT stream button to see the following dialog.



Make the following setup:
  1. Set Receive mode to Listen. This feature doesn't work for other modes.
  2. Define Local IP and port. By default we recommend using 0.0.0.0 IP address.
  3. Alias is a name of this setting for further usage in other setup areas. 
  4. Un-check Add outgoing stream checkbox.
  5. Finally, you need to add "nimble-srt-password-path" custom parameter with full path to a JSON text configuration file located on the same server where Nimble Streamer is running.
Save this setting and it will be synced to the Nimble Streamer instance within a few seconds.

Now let's look at how you can operate this JSON configuration file the path to which you've specified in listener socket settings.

3. JSON configuration file


First thing to notice is that the configuration file must have at least "read" permissions for a user which Nimble Streamer is running under.

This file is requested by Nimble Streamer every time when a new publisher is trying to connect to Nimble Streamer. So you may change the rules any time you need, either manually or via some script according to your business logic.

If the file is specified in listener settings but it doesn't exist or cannot be accessed or it has a malformed JSON then no publishers will be allowed to publish to this listener.

Here is the top-level structure of this JSON file:
{
"publishers": {
},
"streams": {
}
}
Both "publishers" and "streams" sections can be used alone, so you can define only one of them if needed.

3.1 "publishers" section 

The publishers section gives ability to define server-wide allow and deny rules for IP addresses of publishers. Those IP ranges are defined as CIDR ranges. You can define one range, several ranges or none of them for allow and deny lists.

The "deny" list defines the ranges of IPs to deny connection from. If a publisher with denied IP tries to connect then it will be rejected, and you'll find a proper line in Nimble log (see "Troubleshooting with logs" section for details).

If the "allow" list is added into the config then only publishers from allowed IP ranges will be able to connect.

Let's check an example.
{
"publishers": {
"deny": "127.0.0.1/32, 192.0.0.2/32",
“allow":"127.0.0.0/24, 192.0.0.0/24"
  }
}
With these rules, all publisher from 127.0.0.0/24 and 192.0.0.0/24 allowed ranges can publish, except for 127.0.0.1 and 192.0.0.2 from deny list. Publishers from any other IPs will be rejected.

Both IPv4 and IPv6 IP addresses are supported.

If "publishers" section is not available then publishers from any IPs can publish unless something else is defined for specific stream in "streams" section.


3.2 "streams" section 

All stream which you want to allow for publishing must be described in this section.

Every stream has "allow", "deny" and "users" section. Both "allow" and "deny" sections work the same way as it's described in section 3.1. All allow/deny rules from "publishers" section will be applied first, then corresponding rules for a stream will be applied. Then if a publisher is allowed to publish then "users" section is applied.

Let's look at this example.
{
  "streams": {
    "live/stream": {
      "allow":"192.168.0.1/32",
       users": {
         user_id": {"passphrase": "123456789"}
       }
    }
  }
}
Here, only "live/stream" is allowed to be published into this listener, any other streams will be rejected. Also, only a publisher from 192.168.0.1 is allowed to stream, any other IP will be rejected.

The "users" section defines a list of users allowed to publish into particular stream. Each user can be assigned the SRT parameters which will be applied to that particular user.

Let's check another example.
{
  "streams": {
    "live/srtstream": {
      "allow":"127.0.0.1/32,::1/128",
      "users": {
        "srt_user": {"passphrase": "1234567890"},
        "ID_1": {"passphrase": "0987654321"}
      }
    },
    "srtlive/srtstream": {
      "allow":"127.0.0.1/32,::1/128",
      "users": {
        "srt_user": {"passphrase": "1234567890"}
      }
    }
  }
}
In this example, both "srt_user" and "ID_1" users can publish into "live/srtstream" and only "srt_user" can publish into "srtlive/srtstream".

There may be any unique "passphrase" parameter set to each individual user.
Also, any supported custom SRT parameters can be used for each user, e.g. latency, maxbw and pbkeylen.

Let's check another example:
{
  "streams": {
    "live/srtstream": {
      "users": {
        "user_1": {"passphrase": "1234567890", "latency": "2000"},
        "user_2": {"passphrase": "0987654321", "latency", "1000"}
      }
    } }
Here you see "user_1" has SRT latency set to 2000ms and "user_2" has 1000ms latency.

3.3 Listener socket parameters vs. user parameters

If you define some SRT parameters in listener settings, they will be applied to all users unless you re-define them on user level in JSON config file.
E.g. if "latency" is set to "2000" in listener socket and then a user is set latency as "1000" then this user will connect with 1000ms latency. And if some user doesn't have "latency" parameter then it will have 2000ms latency.

This applies to all SRT custom parameters, including "passphrase".

4. Authorization options when using JSON configuration file


If you use JSON configuration file you have two options for authorizing your publishers.

4.1 Login authorization

This way you will authorize users with their respective passphrases.

Here's a JSON example:
{
  "streams": {
  "live/stream": {
    "users": {
      "user_1": {"passphrase": "0123456789"}
    }
  }
}
Your publisher can use this command to connect:
ffmpeg -re -i video.mp4 -codec copy -f mpegts pipe:1 | ./srt-live-transmit -v file://con "srt://127.0.0.1:2020?passphrase=0123456789&streamid=/live/stream?srtauth=user_1"
The "srtauth" parameter has only a user name which is listed in our config. The "passphrase" is used as a password for authorization. If you try to publish to any other stream, the publication will be rejected and you'll see a record in Nimble log. If publisher uses a user not specified in the config then it will be rejected as well.

The output application and stream will be created automatically based on "streamid" like this:
http://localhost:8080/live/stream/playlist.m3u8
If you want to pass SRT parameters, you can add them like this:
ffmpeg -re -i video.mp4 -codec copy -f mpegts pipe:1 | ./srt-live-transmit -v file://con "srt://127.0.0.1:2020?passphrase=0123456789&latency=1000&streamid=/live/stream?srtauth=user_1"
Here a publisher will pass a "latency" parameter with "1000" value.

4.2 Publish control authorization

The second option is to use publish control framework signature with user ID in it. The publish control signature is created the same way as described in section 5 of this article.

Here's a config example:
{
  "streams": {
  "live/srtstream": {
    "users": {
      "srt_user": {"passphrase": "0123456789"}
      "ID_1": {"passphrase": "0987654321"}
    }
  }
}

The publication command would be 
ffmpeg -re -i video.mp4 -codec copy -f mpegts pipe:1 | ./srt-live-transmit -v file://con "srt://127.0.0.1:2020?passphrase=0987654321&streamid=/live/srtstream?publishsign=aWQ9SURfMSZzaWduPWc5U093SGFJK2x2d3ZVd0FMMG9wcmc9PSZpcD06OjE="

If you decode base64 from publishsign you'll see "id=ID_1" and this is the user which will be taken for authorization with "passphrase" of "0987654321".

Read publish control framework overview, detailed setup description and PASSet per-user authorization setup articles to learn about full context of this control feature usage.

5. Troubleshooting with logs


We've made SRT PASSet feature as easy for you to analyse as possible.

Check logs. Nimble Streamer logs are very verbose for SRT PASSet use cases and they will include description of all errors which you may face. Read this article to see more details on server logs.

Make sure your stream to publish is described in JSON config. If you don't have respective stream there, you'll get a message in your log.

Then make sure you have a user and a password assigned to that stream.

Please check server logs in case of any problems. If you still have questions, please feel free to contact our helpdesk.

If you use Larix Broadcaster for publishing, we recommend using Larix Grove format for passing connection details including host and port, streamid, passphrase and other parameters.

Further reading



June 24, 2020

Setting SRT user and password authentication with SRT PASSet

SRT Publisher Assistance Security Set - or SRT PASSet - is a premium feature set of Nimble Streamer which allows extending authentication and control capabilities for SRT input.

The key capabilities of SRT PASSet are as follows:
  1. Accept streamid parameter.
  2. Make per-server, per-application and per-stream authentication with user and password.
  3. Apply any SRT parameters to each individual stream and even individual publisher.
  4. Apply allow and deny lists for IP addresses on server and stream level.
  5. Manage published streams via publish control framework.

Receiver in Listen mode. These features are applied when Nimble Streamer works as a receiver of SRT in Listen mode. Other receiving modes such as Pull and Rendezvous do not support PASSet feature set.

This article describes the following capabilities setup:
  • Accepting "streamid" parameter in "<application>/<stream>" format.
  • Setting server-wide user and password authentication.
  • Setting per-application user and password authentication.
  • Publish control framework signature.

Other capabilities will be described in related articles, see "Further reading" section below.

Let's see how the feature is enabled and used.

Notice that the current article assumes you have a WMSPanel account, you have a Nimble Streamer instance registered in your account and that instance is capable of receiving SRT streams via a designated port.

1. Activate Nimble Addenda


SRT PASSet is available as part of Nimble Addenda premium package and it requires a license to operate and a subscription to cover that license. That license also enables a number of other features like DRM and SSAI.

So if you don't have Addenda license yet, follow these steps:
  1. Go to Settings menu and open Addenda licenses tab
  2. Click on New Addenda subscription and select number of licenses, then click Next and once you see final cost, click on Pay now button.
  3. Follow the payment procedure and once you complete it, you’ll see your active licenses.
  4. Click on the license to see the registration procedure.
  5. Log into the server which has Nimble Streamer installed and which you will use as your host.
  6. Use the registration procedure to make it work.
That's it. Now all features described below will become available.

2. Set up SRT listener


In your WMSPanel account, click on Nimble Streamer -> Live Streams Settings menu and open MPEG-TS In tab.


Here you need to click on Add SRT stream button to see the following dialog.




Make the following setup:
  1. Set Receive mode to Listen. This feature doesn't work for other modes.
  2. Define Local IP and port. By default we recommend using 0.0.0.0 IP address.
  3. Alias is a name of this setting for further usage in other setup areas. 
  4. Add "nimble-srt-password-path" custom parameter and set it to "none". This parameter is required to enable this feature.
  5. Also, un-check Add outgoing stream checkbox.
Save this setting and it will be synced to the Nimble Streamer instance within a few seconds.

Custom SRT parameters. You may also set any other SRT parameters you need, they will be applied to all incoming streams processed under the settings described further. For example, passphrase will encrypt all connections regardless of users and passwords which you define further.
If you need to set different passphrases or other parameters to different users separately then you need to use a different part of PASSet feature set which will be described in a different article soon.

The "streamid" is the parameter which we use for defining the publication business logic as described below.

3. Publish without authentication


Now when the Listener setup is ready, you can start publishing at your sender side using streamid parameter. The streamid value must have "<application name>/<stream name>" format similar to RTMP and RTSP naming. To demonstrate sender behavior, we'll use srt-live-transmit tool with input from ffmpeg.

Here is an example of publication command:
ffmpeg -re -i video.mp4 -codec copy -f mpegts pipe:1 | ./srt-live-transmit -v file://con "srt://127.0.0.1:2020?streamid=live/stream"
The output will be generated just like you normally see it with RTMP and RTSP. Here you see "live" is application name and "stream" is stream name. In our example it will be a stream from localhost, for HLS this will generate the output stream with this URL:
http://localhost:8080/live/stream/playlist.m3u8
Each application may have any number of separate streams, just like you have with RTMP or RTSP. So your first contributor may publish with streamid=live/stream1 and the second one may use streamid=live/stream2, that will generate two separate output streams: http://localhost:8080/live/stream1/playlist.m3u8 and http://localhost:8080/live/stream2/playlist.m3u8.

Now let's see how you can set up user authentication.

4. Server and per-application settings


4.1 Setting input authentication


Now switch to Global tab. Here you can set up settings which are applied on a server level.



You can see Push login and Push password fields where you can define user and password for publication.

You can also define what protocols will be produced for output streams, along with HLS and MPEG-DASH parameters.

If you'd like to setup specific settings for specific applications, go to Applications tab


Click on Add application settings button to see the following dialog.



All parameters are the same as you saw in Global tab except that it also has Application name field. It defines part of the "streamid" parameter utilized as application name.

Once you click on Save, the settings will be applied to the designated server in a few seconds.




Global settings publishing example

Here is an example of SRT publishing using a global server setting.
ffmpeg -re -i video.mp4 -codec copy -f mpegts pipe:1 | ./srt-live-transmit -v file://con "srt://127.0.0.1:2020?streamid=live/stream?srtauth=global_user:pass"
You can see streamid parameter set to live/stream?srtauth=global_user:pass where "live" is application name, "stream" is stream name and "srtauth" has user and password which we defined earlier in Global tab.

The output will be generated just like you saw in section 3, e.g. for HLS this will be http://localhost:8080/live/stream/playlst.m3u8.

Application settings publish example

The same applies to specific app name. Here's an example of SRT publication to srt_stream application:
ffmpeg -re -i video.mp4 -codec copy -f mpegts pipe:1 | ./srt-live-transmit -v file://con "srt://127.0.0.1:2020?streamid=srt_steam/input?srtauth=user2:pass"
You can see streamid parameter containing srt_steam application with input stream having "user2" user with respective password. The result stream will have corresponding app and stream, here's the example of MPEG-DASH stream:
http://localhost:8080/srt_stream/input/manifest.mpd

Each application may have any number of separate streams, just like it was described in section 3.

4.2 Combining global and application settings


Each individual application setting overrides global settings. So if you globally define a full set of protocols and then create an application setting with just one particular protocol and separate user and password then this application will produce only that specific protocol when it gets an SRT stream published into that application.

The only exception is password. If an application has empty user or password then a global user and password will be taken. This way you cannot set up a global user and password and leave some specific application without authorization.

With that application override approach, you can combine global and application settings for the purpose of specific setup for specific cases.

For example, you can set some random user and password for a global setting, and then create applications for specific users. This way you'll forbid publication from anyone except for the people which you want to explicitly give access to. In addition to that, you may provide different set of output protocols, i.e. someone premium users can have low latency output (Low Latency HLS and SLDP) while others will have just conventional HLS.

5. Publish control framework


Adding a user/password setting enables the ability to use a publish control framework. It allows the following:
  • Add publishing signature to authenticate publisher to make sure that your publisher is exactly the one you are expecting to produce the stream.
  • Use an external handler to verify a caller. The handler is your own web application which is able to control the initial connection process according to your business logic.
  • Control the streaming process. You can create a separate web app or a script which will request a server instance to check current streaming sessions against your rules and to make an immediate interruption of any on-going streams.
In case of SRT you add publication signature into streamid along with other parameters. Here is an example of publishing command:
ffmpeg -re -i video.mp4 -codec copy -f mpegts pipe:1 | ./srt-live-transmit -v file://con "srt://127.0.0.1:2020?streamid=/live/srtstream?publishsign=aWQ9SURfMSZzaWduPVQ3SzVlMkMySlRxRExmSTdybVdibVE9PSZpcD0xMjcuMC4wLjE="
The publishsign parameter contains the signature required by this feature. You can read this overview article to get familiar with all publish control capabilities and read detailed setup description.

6. Troubleshooting with logs


We've made SRT PASSet feature as easy for you to analyse as possible.

Check logs. Nimble Streamer logs are very verbose for SRT PASSet use cases and they will include description of all errors which you may face. Read this article to see more details on server logs.

Log examples. If you have incorrect user and password authentication you will see the following message in logs
url auth failed, streamid=[live/stream?srtauth=wrong:password],ip=[127.0.0.1],client=1038565310
If you try to publish without user and password while your setting have then on global or application level you will see something like this:
url auth failed, streamid=[live/stream],ip=[127.0.0.1],client=1038565318
So please check server logs in case of problems. If you still have questions, please feel free to contact our helpdesk.


Further reading


Use a custom rules file. You can define rules to apply SRT parameters and setup authorization on each individual user and stream as well as define deny and allow lists of IP addresses. This functionality is described in this separate article.


June 22, 2020

SRT Publisher Assistance Security Set

SRT is the protocol which many professionals consider as a replacement for RTMP for content delivery among encoders, decoders, origin and edge servers. SRT has a tremendous set of features which make it great for reliable streaming, and we see comprehensive adoption of SRT among our customers for those use cases.

Softvelum was an early adopter of SRT with Nimble Streamer and most of SRT-related features were implemented within the first year after Haivision opened the spec and the SRT library source code. The feature set covered all transmission modes and protocol parameters which allowed our customers to try the technology and start transitioning to SRT easily.


However the technology evolved and Haivision as the leader of SRT Alliance followed the feedback to add features like "streamid" parameter and other improvements which made SRT the replacement to RTMP for publication use cases.

Filling the gap in Nimble Streamer


As our customers adopted the technology, they continuously gave a lot of great feedback, especially from use cases where they got user-generated content into their delivery networks. They compared Nimble Streamer RTMP implementation for securing and managing the publication process, and asked for the same extended support for SRT.

Main concerns were related to a few key areas. First one was to support for "streamid" parameter and give abstract layers of "application name" and "stream name" to perform processing of multiple streams on the same host and port. Second one was to give user name and password for each application and stream to have more authentication options. Advanced users wanted to be able to apply publish control framework to SRT like they did for RTMP and RTSP, which would allow controlling publishers all along the streaming process. So our team wanted to solve these problems by utilizing the latest features of SRT to fill the gap in our functionality.

Softvelum now has a premium SRT Publisher Assistance Security Set - or SRT PASSet - to cover those concerns.

Here are key capabilities of SRT PASSet which are applied when Nimble Streamer works as a receiver of SRT in Listen mode:
  1. Accept streamid parameter.
  2. Make per-serverper-application and per-stream authentication with user and password.
  3. Apply any SRT parameters to each individual stream and even individual publisher.
  4. Apply allow and deny lists for IP addresses on server and stream level.
  5. Manage published streams via publish control framework.
Let's have a bird-eye view on how these features work. Detailed technical articles will be published shortly.

Per-server and per-application SRT authentication via user and password


With SRT PASSet enabled, Nimble Streamer allows setting server-wide and per-application processing settings. This was available for RTMP and RTSP, now you can go to WMSPanel and define all that for SRT published streams too. You can define:
  • authentication details - user and password;
  • output protocols set and their details like HLS chunk size.
This combination of server and application levels gives wide capabilities for providing proper security levels for your publishers and create various service levels.


Publish control framework for SRT


With per-app settings in place you can get tighter control over the publication process using publish control framework. It's a functionality to authorize and control a publisher using custom business logic. It has several levels of control capabilities.

A. Add publishing signature to authenticate publisher. It allows making sure that your publisher is exactly the one you are expecting to produce the stream.

B. Use an external handler to verify a caller. The handler is your own web application which is able to control the initial connection process according to your business logic.

C. Control the streaming process. You can create a separate web app or a script which will request a server instance to check current streaming sessions against your rules and to make an immediate interruption of any on-going streams.

Read overview of Publish control framework
 to learn more about this feature set and setup details article showing the process step by step.

Those levels of authentication and control provide a flexible framework itself, however you can go even further.

Your rules: Per-stream per-user and global SRT parameters


Besides providing the authentication and control functionality similar to RTMP, we also developed separate SRT-specific mechanics which would cover SRT-related use cases. A separate file with rules definition is placed on the server where the Nimble Streamer instance is running. Here are the key features.

Global server-level allow and deny lists of publishers' IP addresses with IPv4 and IPv6 supported.

Stream-level settings can be used to define parameters for each individual stream:
  • Allow and deny lists for publishers' IPs for each stream and per-server.
  • Per-user settings. If callers specify user name or user ID, then each user can be associated with any available SRT parameters, such as passphrase, pbkeylen, latency, maxbw and any other.
  • SRT Listener socket parameters can be combined with per-user parameters. E.g. you can define socket-level default latency and then re-define it for individual users.
Rules control can also be automated so you could update them according to your business logic.


Premium flexibility


The features which you saw above give true flexibility for handling SRT publishers. If you manage or build a streaming infrastructure relying on SRT-based delivery, they are must-have for your use cases. 

All the above SRT PASSet functionality is delivered as part of Nimble Addenda premium package which provides a number of extra capabilities which you may find interesting.

More articles with setup details and usage examples are coming soon.

Stay tuned for updates and follow us in TwitterFacebook, LinkedIn, YouTube and Telegram to get further updates.

May 3, 2020

Larix Grove for distributing Larix Broadcaster settings

Usually all connections in Larix Broadcaster are set up in application settings, and you need to add each connection manually.

With Larix Grove you can distribute and import streaming settings using a special URL format.
You make a URL with Grove wizard and send it via email, messenger, a web page or QR code.

When you tap on the link on a web page, Larix Broadcaster is launched and you need to confirm settings import.

You can create a QR code and once you scan it, you will import connections settings.

You may also open the Settings -> Connections -> Import Larix setting app menu to process the links manually copied from an email or a messenger.

Try Larix Grove in action and let us know of any ideas to improve it.

Here's a demo video showing this feature in action.


April 22, 2020

Handling fuzzy FPS to get proper bitrate output

Nimble Live Transcoder allows creating transcoding scenarios with various transformations, including control over output bitrate. Usually you have some input stream with expected parameters like frame rate (FPS) and resolution and want to create one or more output with certain bitrate.

Normally you can define output bitrate using various parameters of encoder libraries, like it's described for x264 bitrate, constant x264 bitrate, NVENC bitrate and QuickSync bitrate setup in respective articles.

However, some sources may produce streams with uncertain frame rate. For example, mobile encoders may produce variable bitrate so when your users are streaming with apps like Larix Broadcaster you may get streams with unexpected FPS. As a result, if you ingest such fuzzy stream into a transcoding scenario, the encoder may produce the unexpected bitrate - higher or lower than you've defined in encoder settings.

You can use two approaches to handle this: by adding FPS filter or by defining FPS numerator and denominator parameters for encoder.

Option A: Add FPS filter


The best way to handle this is to set some definite value for FPS using a custom "fps" filter.
If you expect your users to stream with framerate around 25-30 FPS, you can set filter to 30 FPS. If you need a better framerate, just set it to proper value like 60 FPS. This filter uses optimized algorithm to insert extra duplicate frames, and encoders are optimized to process such repeating frames, so this will not add any processing overhead.

A.1 Add video_filter_reset_by_pts_enabled parameter to config

Before setting a filter, add video_filter_reset_by_pts_enabled = true parameter into your nimble.conf. With FPS filter, if you have MPEG-TS input (e.g. if you use SRT) and if input gets time gap, the output may hang up, so this parameter avoids that.

A.2 Add filter

Here's how you add the filter into transcoding scenario. Open your scenario and drag a Custom filter onto a pipeline. 


Then connect it to other filters and the encoder.


Now if you have your bitrate set up in the encoder element, you'll get the output bitrate which you've defined there after you save the scenario.

Option B: Using FPS numerator and denominator


Another option is to set output FPS numerator and denominator. All Transcoder encoders' libraries support them, so just set them as part of parameters: fps_n for numerator and fps_d for denominator. These parameters will "introduce" the encoder to the numbers which it will use for further bitrate calculation.

If you need 30 FPS, use fps_n=30 and fps_d=1, as shown below. The same formula applies to 60 FPS: use fps_n=60 and fps_d=1.


In this example, once you save encoder setting and then save scenario, the encoder will be likely to produce 1Mbps output based on expected frame rate of 30 FPS.



Let us know if you have any questions about these approaches.

Related documentation


Nimble Live Transcoder, Live Transcoder documentation reference,

April 20, 2020

RIST protocol in Nimble Streamer

RIST (Reliable Internet Streaming Transport) protocol is a new protocol for low-latency live video over un-managed networks. You can find out more about this protocol in RIST website. RIST is developed and promoted by RIST Forum where Softvelum is an affiliate member.

RIST is available via libRIST open-source library so Softvelum uses it to integrate this technology into Nimble Streamer media server. We give our customers all delivery options available on the market so libRIST is now one more delivery protocol in our stack.


Nimble Streamer allows both receiving (Listen and Pull) and sending (Listen and Push) RIST streams.

All supported protocols can be used as input for re-packaging into RIST: SRT, RTMP, RTSP, MPEGTS, HLS and Icecast.

Having any RIST input stream, it can be re-packaged into all supported output protocols: HLS, MPEG-DASH, SRT, RTMP, RTSP, MPEGTS and Icecast, as well as recorded into DVR.

This article describes the steps to set up RIST streaming via Nimble Streamer.

Install Nimble Streamer and RIST package


RIST is available via separate package for Nimble Streamer. You need to install it in order to use this protocol.
  1. Sign up for WMSPanel account if you haven't done it yet.
  2. Install Nimble Streamer or upgrade it to latest version.
  3. Follow instruction RIST page to install RIST package. RIST package is currently available only on Ubuntu 18.04 and later versions.
Now you may proceed with the setup.

Receiving RIST streams


Being logged into WMSPanel, click on Nimble Streamer -> Live streams setting top menu. Then choose MPEGTS In tab.


Click on Add RIST stream button to open the dialog shown below.

RIST provides two modes for obtaining the stream:

  • Listen sets Nimble to wait for incoming data and process it as soon as it arrives. Your source needs to be set "Push" mode.
  • Pull sets Nimble to initiate the source server to start sending the data. Your source needs to be set to Listen mode.
If you select Listen, you'll need to specify the local interface - Local IP and Local port - which Nimble will listen to in order to get a stream. If you'd like it to listen to all interfaces, just set Local IP to 0.0.0.0.



Alias is the name that will be used in incoming streams list.

Also check Add outgoing stream checkbox and fill in the Application name and Stream name fields if you'd like to automatically create outgoing stream for further processing. This step is specific to MPEG-TS streams in Nimble.

If you'd like get stream in Pull mode, you'll need to specify the Remote IP and Remote port where you'll get your stream from.


Once you save setting, the settings will be applied  create outgoing stream, you can use a breadcrumbs on top of settings page to go to live streams of specific server (by clicking "RIST demo" server link in this example):


You can now use this stream for further processing and playback similar to other MPEG-TS processed streams.

Sending RIST streams


We assume that you have a live stream ready to be sent out. If you don't, please refer to live streaming scenarios to see how you can set it up.

Go to UDP streaming tab to add new setting.


Click on Add RIST setting to see dialog below.
RIST allows streaming in two modes:

  • Push will initiate the active sending of the selected channel to the destination IP/Port which is working in Listen mode.
  • Listen will make Nimble Streamer wait for the Pull command from remote server.

Mode is a field to set this behavior.


If you choose Push mode, you'll see Remote IP and Remote port fields to specify the destination.

If you choose Listen, you'll be able to specify Local IP and Local port to be used for listening for a connection. Just like in receiving use case, If you'd like it to listen to all interfaces, just set Local IP to 0.0.0.0.


Source application name, Source stream name and their respective PMT PIDs, Video PIDs and Audio PIDs describe where the content is taken from for further transmission. Those streams need to be defined prior to making this setup. You may define multiple sources - in this case RIST channel will have multiple streams in it.

Supported RIST parameters


Nimble Streamer allows using the following parameters. You need to set them both on sender and receiver side. You can refer to RIST documentation for more details and tips on their usage.

  • aes-type is encryption type, set if only secret is not empty. Available values are are: 0 - none, 128 - AES-128, 192 - AES-192, 256 - AES-256.
  • bandwidth is RIST recovery bandwidth (Kbit/s), it's 100000 by default
  • buffer is maximum RIST recovery buffer size in milliseconds, it's 1000 by default.
  • cname is a manually configured identifier.
  • compression defines compression, 0 is for disabled, 1 is for enabled.
  • keepalive-interval is a Keep-alive timeout in milliseconds, it's "100" by default.
  • miface is multicast interface name.
  • profile is RIST profile. Available values are are: simple, main (default)
  • reorder-buffer is reorder buffer size in milliseconds, it's 25 by default.
  • return-bandwidth is RIST recovery return bandwidth (Kbit/s), it's 0 by default
  • rist-logging is logging level. Available values are are: quiet (default), info, error, warn, debug, simulate
  • rtt is round-trip-time (RTT) in milliseconds, it's 500 by default.
  • secret is encryption password.
  • session-timeout is a session timeout, in milliseconds.
If you have any questions about these parameters, please refer to librist documentation as describe below.

libRIST


Nimble Streamer uses librist library version 2.6.5. If you have any questions on RIST parameters usage and other topics, please refer to RIST documentation. and contact RIST team about it.


Related documentation


Softvelum Nimble Streamer, MPEG-TS support in Nimble Streamer

April 12, 2020

Nimble Streamer DRM with Widevine, FairPlay, Playready, EZDRM and VCAS

Softvelum team is glad to announce that Nimble Streamer now has full support for a number of Digital Rights Management (DRM) capabilities for live streaming.

The following encryption engines are supported to protect MPEG-DASH:
  • Google Widevine™
  • Microsoft Playready™
Also, Apple FairPlay is supported t protect Apple HLS streams.

The following key management servers are supported:
  • Widevine Cloud Service with key rotation
  • EZDRM™ key management support for Widevine, FairPlay and Playready
Also, previously supported Verimatrix™ VCAS key management for HLS protection is fully supported.

DRM configuration is performed via easy-to-use configuration file which allows defining per-application setting for all available DRM features.

Visit DRM feature page to learn more about DRM setting.

Nimble DRM is part of Nimble Addenda premium package which requires a license accessible via monthly subscription. Addenda covers Nimble DRM and Nimble Advertizer capabilities.

Please read Nimble DRM spec and subscribe for a license to try it in action.

Later on we'll release some other popular key management systems, let us know which one you're looking for the most.

Related documentation


Nimble Streamer DRM, Nimble Addenda, Nimble Advertizer

April 7, 2020

iCloud support and file operations in Larix Broadcaster for iOS

Larix Broadcaster for iOS now has improved capabilities for recording live stream into local files.

Here are the options you can use for files storage:

  • Local storage available via MacOS Finder as described in this article.
  • iCloud Drive
  • Photo Library

You can also split video into sections, like it's usually done in dash cams. The recording is divided into multiple files by length.

Here's how you can set this up.

First, install Larix Broadcaster from AppStore.

Go to app Settings / Capture and recording / Record menu.


First, turn on the Record stream to automatically record any live stream.

Tap on Storage to select the default storage for recorded videos and screenshots. This will be one of 3 options mentioned above.

Split video into sections allows defining the length of recording which the stream will be split into. By default of Off.

Once you make recordings, go to Settings / Manage saved files menu.


Here you can long tap on file name to move it to proper destination. You can also tap Edit to perform multiple files operation. The iCloud tab will show the content of respective iCloud Drive folder. The recorded or copied files an be found in respective folders.

Take a look at a brief video overview of this feature.





Let us know if you'd like any improve in this feature set.

Related documentation


Larix Broadcaster, Larix documentation reference, Softvelum YouTube channel,