February 24, 2024

SLDP is now played on iOS17 iPhones with MMS

Our team introduced SLDP low latency playback protocol several years ago as a replacement for RTMP due to sunset of Flash. It's a WebSocket-based technology which can be played on any browser platform that has MSE. Up until now, this was the reason why SLDP live streams couldn't be played on iPhones since they didn't have MSE, even though, it played on Windows, Linux, macOS and even iPads. The only exception was Opus audio-only playback on iOS.

Now with the latest releases of iOS 17, iPhone iOS has full support for MMS - Managed Media Source - which provides necessary capabilities to make the MSE-based playback possible.

Hence, SLDP playback is now available on iPhones running iOS17+.

The setup is the same as for other browsers.

  1. Go to SLDP HTML5 Player page, download and embed HTML5 player into your web page.
  2. Follow Nimble Streamer setup instructions for SLDP output setup if you haven't does this yet.

That's it.

You may also try our players testing page as well as raw HTML5 reference implementation to test your streams on iPhones.

You can also subscribe for SLDP HTML5 SDK to make more customized setup for your use case and viewers' experience.

About SLDP

Softvelum Low Delay Protocol a.k.a. SLDP was created with last mile low latency in mind.

  • Close to one second delay with buffer offset support for decreasing zap time (start latency).
  • Codec-agnostic and may carry whatever your end-user platform has: H.264, AV1, VP8, VP9, H.265/HEVC video with AAC, MP3, MP2, AC3, E-AC3, Speex, PCM G.711, Opus audio.
  • ABR real-time support. Switching channels takes just a GOP time and each channel may use its own codec.
  • Simultaneous synchronized playback among multiple browsers and mobile devices.
  • CEA-608/708 closed captions are supported with HTML5 Player SDK.
Contact our team to ask questions or share your experience with SLDP playback.

Follow us in social media to get updates about our new features and products: YouTubeTwitterFacebookLinkedInRedditTelegram

February 12, 2024

SCTE-35 markers support in Nimble Streamer Playout

We're glad to introduce an update for Nimble Streamer Playout feature (also referred to as a Server Playlist sometimes). It now provides enhanced functionality for SCTE-35 markers insertion through the playlist. Any systems with SCTE35 support can process the Playlist output in order to insert ads. E.g. Nimble Advertizer can do that for you.

The latest update introduces a new section in playlists called "Scte35Markers". It allows the insertion of SCTE-35 markers at a specific time spot within a playout-generated stream. Using key parameters like "Type", "Start", and "Duration" users can precisely control marker placement.

"In" and "Out" markers types are supported.

Out” markers support either a precise time in UTC format ("YYYY-MM-DD HH:MM:SS") or the offset from the beginning of the currently running file set in milliseconds.

Here's a self-explanatory example:

{
  "Type": "vod",
  "Start": 0,
  "Duration": 600000,
  "MaxIterations": 0,
  "Source": "test/content/mp4/sample.mp4",
  "Scte35Markers": [
    { "Start": "2023-11-03 04:00:00", "Type": "Out", "Duration": 2000 },
    { "Start": "2023-11-03 04:00:02", "Type": "In" }
  ]
}


You can find full example on Nimble Streamer Playout page.

The improved Playout in Nimble Streamer allows effortlessly inserting SCTE-35 markers directly through the playlist, eliminating the need for additional Nimble API calls.

Install the latest Nimble Streamer version and check these enhancements.

We look forward to enhancing your streaming experience. Let us know if you have any questions.

Related documentation




February 6, 2024

Larix Broadcaster on MacOS

 We're glad to inform you that Larix Broadcaster for iOS is now available on the latest macOS via the AppStore!

Larix Broadcaster for macOS provides:

  • Support for MacBook's internal cameras
  • Support for Continuity Camera feature to use iPhone as an external camera
  • Support for USB cameras
  • All the basic and advanced features of a Mobile App: Multicamera(Picture-In-Picture, Side-by-Side modes), Overlays, RTMP, SRT, WebRTC and all other protocols
  • The same Apple ID can be used for several devices.

Now you may also stream with a wired connection to a preferred publish point.

Please check this video to see how it's set up:


January 17, 2024

Zixi streaming setup in Nimble Streamer

Zixi is a well-known brand in the broadcasting and streaming industry. It provides a reliable and secure technology to transmit video content, especially in situations where maintaining low latency and high video quality is crucial.


Nimble Streamer provides integration with Zixi Broadcaster in order to create a bridge between the Zixi protocol and all the technologies that are supported by the Nimble Streamer live streaming feature stack. This article describes the technical details of Zixi-Nimble integration.

1. Prerequisites


We assume that you already have some experience with Nimble Streamer and WMSPanel, so the basic topics are not covered here.

The concept is to have Zixi Broadcaster be controlled by WMSPanel as a backbone for receiving the Zixi stream, while all further processing is performed by Nimble Streamer with its variety of features including live streaming protocols transmuxing and transcoding, Paywall, Reporting, DRM and others.

A dedicated server is required to concurrently operate Nimble Streamer and Zixi Broadcaster on the same hardware.

Both Windows and Linux platforms are supported. The setup is tested with Zixi Broadcaster v16 and the latest version of Nimble Streamer.

Both Zixi Broadcaster and Nimble Streamer need active licenses or subscriptions.

The installation process for Zixi Broadcaster is not covered in this article. Please refer to Zixi documentation or reach out to Zixi support about this.

As for Nimble, you can find all related technologies’ documentation on this page and beyond. If you have any questions or issues installing a Nimble instance, please contact our support team.

Notice that the Zixi Broadcaster will be used by Nimble exclusively, and any additional manual settings of Zixi Broadcaster will be deleted.

2. Setting up Nimble Streamer config


In order to allow Nimble to control Zixi Broadcaster, please specify Broadcaster’s admin user credentials in the nimble.conf file.


The location of the Nimble’s config for the Linux version:
/etc/nimble/nimble.conf
The location of the Nimble’s config for the Windows version:
C:\Program Files\Nimble Streamer\conf\nimble.conf
Do not forget to elevate the current user permissions for accessing the config files, like running the editor via sudo for Linux or ‘as Administrator’ for Windows.


Add the following lines to the end of the config file and substitute *actual_zixi_broadcaster_password* with a real one (without asterisks).

### Zixi ###
zixi_port = 4444
zixi_username = admin
zixi_password = *actual_zixi_broadcaster_password*

Next, restart Nimble to apply the above changes e.g. via the command line for Linux or services snap-in for Windows.


If you succeed you will notice Zixi interfaces detected on the Server Info page in WMSPanel:



3. Receiving Zixi stream via Nimble


Navigate to 'Live Streams Settings' and go to the MPEGTS IN tab. Find and click the 'Add Zixi Stream' button. A dialogue will appear for specifying parameters to receive a Zixi stream. The Receive mode options include 'Listen' for pushing a stream to this server (e.g. by Larix Broadcaster for iOS) and 'Pull' for retrieving a stream from another location, such as another Zixi server or source.

3.1 Setup Listening for Zixi Stream


Choose Receive mode as Listen:


When Listen mode is selected, a notification that Nimble detects Zixi Broadcaster by the ‘Zixi input interfaces:

zixi://*:2088’ is displayed. If there’s no such line then it’s a sign that Nimble can’t reach the Broadcaster.

For unified management of any incoming MPEGTS streams, Alias, Description and Tags could be specified for additional identification. These handy labels help quickly find and group streams through WMSPanel. They are available for many other settings and we advise using them.

A Zixi stream must have a unique StreamID to be accepted. The StreamID is a string that identifies the stream. It is set in the respective field and must be the same as on the sender.

Next, the fields for Custom parameters and Values where optional parameters for the Zixi stream can be filled out.

These are used to specify additional options like latency, stream password, encryption type, etc.

We suggest referring to Zixi documentation for details, however, here's a description of options shown on a screenshot:
  • password - Set stream password (blank by default)
  • latency - Set latency in milliseconds: overrides remote latency configuration (this one is optional, by default the latency is defined on the sending device)
The ‘Add outgoing stream’ checkbox will add the respective MPEGTS OUT at the moment when MPEGTS IN is created. The output will be named the same as set in the Application name and Stream name fields. This step may be omitted if you decide to make outputs later: Nimble will receive the stream in this case, but no output will be generated. That’s why specifying the output name at this step is recommended. The stream will be transmuxed into the protocols defined for the specified Application.

Click Save to initiate synchronization of the settings between Nimble Streamer, Zixi Broadcaster and WMSPanel.

Any manually created settings of Zixi Broadcaster will be erased and substituted by the parameters received from WMSPanel. The record for the Listening for Zixi stream settings will appear in the MPEGTS IN section. As the syncs are complete a green checkmark will confirm Nimble received and is ready to use this setting:




By the way, sharing Zixi’s publishing URLs is also supported by the Larix Grove format. To get a publishing URL or a QR code for it, click on a ‘?’ icon:


Set up the source for streaming and start pushing the stream from another Zixi-capable software like Larix Broadcaster to your Nimble instance.


4.2 Setup Pulling of a Zixi Stream


The 'Pull' mode is used to fetch a stream from a different location. To switch to it, please choose ‘Receive mode’ as ‘Pull’ in the ‘Incoming Zixi stream’ window. The dialogue will change to the following:

In order to confirm that the stream is received, navigate to the ‘Live Streams’ page. There’s a handy way to do it: click on a server name in a breadcrumb located between ‘Live streams /’ and ‘/ Live stream settings ‘ to switch to the Live Streams page instantly.

The received stream’s parameters are stored here. Click ‘?’ to get the output stream’s URL or play this stream with the embedded set of video players.


It is crucial to properly define the Remote IP or domain name and the Remote port of a remote Zixi server. Make sure they are reachable from the Nimble instance for successful reception.

The ‘Source’ value is a StreamID of a Zixi stream defined on a remote machine.

The ‘StreamID’ field refers to the unique name which Nimble will use after receiving the Zixi stream locally.

All other configuration options are the same as for Listen mode as explained above.

Please refer to the previous section for respective details.

Click ‘Save’ to sync and apply settings to Nimble and Zixi Broadcaster. The settings record will appear with a Bandwidth, program count and a green check mark.

If MPEGTS OUT was defined, please navigate to Live Streams to check the received stream settings or watch it via video player.

4. Publish a Zixi stream from Nimble to another Zixi Broadcaster instance


Any stream that reaches Nimble by any supported protocol can be re-published as a Zixi stream to other destinations.

4.1 Push mode Zixi streaming


First, ensure the reception is defined on a remote Zixi Broadcaster server. Login to Zixi Broadcaster’s panel, Click ‘+New Input’ in the ‘INPUTS’ section, and type in the Stream ID which will be used to identify the stream coming from Nimble:



Use any other Zixi options as required.

Click ‘OK’ and switch to WMSPanel to set Nimble for sending Zixi stream.

Navigate to the ‘Live Streams Settings’-> ‘UDP Streaming’ tab and click ‘Add Zixi settings’.

The setup is similar to MPEGTS UDP Streaming, which you may be familiar with.



To Push a stream, fill in the Remote IP, Remote Port and Stream ID of a Zixi’s remote point. Note the same ‘Stream ID’ is used as defined on Zixi Broadcaster earlier.

Any additional Zixi parameters can be passed via the ‘Custom parameter’/’Custom value’ fields.

Specify a stream to send, by typing its application and name in the ‘Source application name’ and ‘Source stream name’ under the ‘Set source streams’ bullet. It’s allowed to specify several apps/streams here to form a multiple-program TS stream.

The ‘Raw MPEGTS source’ is also available to pass through some received sources intact, as described in the respective documentation page.



On a Nimble side, the Push record appears in the MPEGTS IN tab:


4.2 Listen mode Zixi streaming


The ‘Listen’ mode assumes that Nimble will wait for a connection from a remote Zixi server, and as soon as it is established, it will serve stream data for pulling.

On a Zixi Broadcaster side, click ‘+New Input’ in the ‘INPUTS’ section, and select the ‘Pull’ radio button:

Click ‘Save’ to start pushing a Zixi stream from Nimble and find it on a remote Zixi Broadcaster server:


The StreamID here will be the RemoteID for Nimble. Use some unique name.

‘Host’ is a Nimble Streamer box, and ‘Port’ is the port used for output in Zixi’s integration. 2088 is the default.

‘Stream’ is the StreamID we will define on Nimble side a bit later. It’s used to link Nimble’s streams with the Zixi protocol under this ID. This is a stream that will be taken from Nimble by Zixi Broadcaster.

Use any other parameters here, but don’t forget to ‘mirror’ them on the Nimble side if it is required by the protocol. For instance, if you define encryption type and string on a source, don’t miss to set the decryption params on the receiver.

Click ‘OK’, and move on to WMSPanel to configure Nimble.

As before, navigate to the ‘Live Streams Settings’-> ‘UDP Streaming’ tab and click ‘Add Zixi settings’, but now choose ‘Listen’ mode.


The dialogue will highlight available Zixi’s interfaces.

The crucial difference with the Push mode is that you must specify a StreamID of Zixi’s remote Pull settings, which is named ‘Remote ID’ here.

Specify the ‘Source application name’ and ‘Source stream name’ of streams which are available on Nimble, and assumed for transfer.

Fill a local ‘StreamID’ that will unite the streams that are specified in the Source Application/Stream name fields to transfer to Zixi Broadcasters. Keep in mind, that on a Zixi Broadcaster’s side, this name must be specified in a ‘Stream’ field of a Pull settings.

All other options are similar to Push mode and already described in the Zixi Push section above, please refer to them.

Click ‘Save’, and WMSPanel will confirm the settings are accepted by a green checkmark:


Navigate to Zixi Broadcaster to confirm reception:


This article has taken you through the process of integrating Zixi streaming with Nimble Streamer. With the combined capabilities of Nimble and Zixi Broadcaster, you’ll get efficient and top-notch video content delivery.

If you have any questions or issues regarding this functionality, our support team is ready to help, ensuring a successful Zixi streaming with Nimble.

Related documentation


Widevine DRM support for HLS

 Nimble Streamer has extensive DRM support for live and VOD streams. It covers all DRM systems - Widevine, Playready and FairPlay - and multiple DRM management platforms.

Traditionally, HLS streams could only be protected using Apple FairPlay and could only be played on Apple devices.

With recent updates, HLS can now be protected using Google Widevine in addition to FairPlay.

This means that you may have just a single multi-key multi-DRM HLS stream and play it on the devices that support either FairPlay or Widevine. This practically means that this single multi-key HLS stream is protected on any modern streaming device like PC, Mac, Android, iPhone/iPad and more.

This also applies to Low Latency HLS DRM protection, no special setup is needed for that.

You don't need to have a separate MPEG-DASH stream specifically for Widevine protection now.


Multi-key HLS can be protected with Widevine DRM


Widevine HLS encryption setup

The DRM setup is specific to your DRM provider and described on Nimble Streamer DRM setup page.

In addition, you need to add this parameter to your app setting section in drm.conf file:

widevine_hls_enabled = true

Like this:

drm {
  application = live_ezdrm
  type = ezdrm
  widevine_hls_enabled = true
  user = user@yourcompany.com
  password = 12yourpassword34&*@#
}

We have EZDRM here enabled for all streams within "live_ezdrm" application. This can be any other DRM management solution.

Once you save the config file and re-start Nimble, the stream will be protected right away. You may also apply drm.conf changes by using native API call without Nimble re-start.

Widevine multi-key HLS playlist example

We have a sample DRM-protected HLS stream

https://drm-test-cf.softvelum.com/live_ezdrm/bunny/playlist.m3u8

Here's an example of an HLS playlist that has both encryptions.

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-TARGETDURATION:9
#EXT-X-MEDIA-SEQUENCE:703
#EXT-X-KEY:METHOD=SAMPLE-AES,URI="skd://fps.ezdrm.com/;5a0XXXX4-8XX2-11ea-9XX8-040XXXXXXXXX",KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1"
#EXT-X-KEY:METHOD=SAMPLE-AES,KEYID=5a0XXXX4-8XX2-11ea-9XX8-040XXXXXXXXX,URI="data:text/plain;base64,AAAAP3Bz XXXXXXXXX nWSs6jyXXXXXXXXXXXXXXXXXXXXXXXXSkAEaBWV6ZHJtSOPclZsG",KEYFORMAT="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed",KEYFORMATVERSIONS="1",IV=0x5a08XXX485XX11XXXXX401999XXXX
#EXT-X-MAP:URI="video_1.fmp4?nimblesessionid=189205"
#EXTINF:6.666,
v_42_380062500_703.fmp4?nimblesessionid=189205
#EXTINF:2.375,
v_42_380662500_704.fmp4?nimblesessionid=189205
#EXTINF:4.583,
v_42_380876250_705.fmp4?nimblesessionid=189205
#EXTINF:8.75,
v_42_381288750_706.fmp4?nimblesessionid=189205

This element is for FairPlay:

#EXT-X-KEY:METHOD=SAMPLE-AES,URI="skd://fps.ezdrm.com/;5a0XXXX4-8XX2-11ea-9758-040XXXXXXXXX",KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1"

And this one is for Widevine:

#EXT-X-KEY:METHOD=SAMPLE-AES,KEYID=0x5a0XXXX4-8XX2-11ea-9XX8-040XXXXXXXXX,URI="data:text/plain;base64,AAAAP3Bz XXXXXXXXX nWSs6jyCfc1R0h7QAAAB8XXXXXXXSFIhHql1gEAZmSkAXXXXXXXXJtSOPclZsG",KEYFORMAT="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed",KEYFORMATVERSIONS="1",IV=0x5a08XXX485XX11XXXXX401999XXXX


Widevine HLS Players

You may use Shaka Player to play this stream, it fully supports this kind of Widevine-encrypted HLS. Other commercial players have that support, please refer to their documentation.

You may try playing our sample stream above using our players page. Here's an example of Widevine playback:

https://wmspanel.com/p/#player=shaka&url=https://drm-test-cf.softvelum.com/live_ezdrm/bunny/playlist.m3u8&drm_url=https%3A%2F%2Fwidevine-dash.ezdrm.com%2Fwidevine-php%2Fwidevine-foreignkey.php%3FpX%3DB03B45

Notice the License Server URL field that you'll need to use for your stream.

The FairPlay is played the same way, with its respective License Server URL and Certificate URL fields being set properly.


Related documentation

January 2, 2024

New WebVTT Features: Transcoder Passthrough and Playout Support

We are glad to announce that we added new features to our Nimble Streamer software media server to support WebVTT subtitles. WebVTT is one of the popular formats for displaying timed text tracks in VOD or live streams. Based on the feedback from our customers, we were working on adding WebVTT support for Live Streams.

First, you can produce a live stream with WebVTT subtitles from VOD files via Nimble Playout. However, there is a limitation that only one subtitle file can be used for one VOD file. Please find more details in respective section of the Playout documentation.

Another new feature is the Transcoder Passthrough option, which allows you to pass through WebVTT subtitles if they are detected in the source stream.

Please also check Subtitles digest page to see what else Nimble can do for you.

We are continuously working on enhancing subtitles support. Any suggestions and comments are welcomed.

December 19, 2023

Apple HTTP Live Streaming Tools for Linux

Apple has released a new version of its HTTP Live Streaming Tools, a package of command-line tools for creating and testing HLS solutions. There’s a delightful surprise for developers,  as the recent release is also available as Centos 7 package.

This brings a lot of convenience to global developers' community!

The HTTP Live Streaming Tools package includes five tools for CentOS Linux 7: Media File Segmenter, Media Subtitle Segmenter, Media Stream Segmenter (Low Latency HLS mode included), Variant Playlist Creator and Media Stream Validator. These tools help developers segment, validate, and optimize their HLS streams using almost any web server infrastructure for streaming to iOS, macOS, and tvOS.

The latest release adds a new feature: the ability to segment spatial video content for delivery to Apple Vision Pro, a device that enables immersive viewing experiences. Spatial video technology allows capturing the full 360-degree environment around the camera.


The HTTP Live Streaming Tools are available for download from the Apple Developer website. Users need to have a valid Apple Developer account to access the tools. We commend Apple for making these tools available for Linux developers, as it shows their commitment to supporting the open-source community and the web standards.

December 4, 2023

Nimble Streamer OpenSSL 3 fix

Nimble Streamer team is continuously working on improving the stability and robustness of our media server, including the underlying libraries and components.

OpenSSL 3 issue

A new behavior was introduced in OpenSSL 3, causing SSL library to return EOF-related errors during SSL shutdown sequence. The following pages for more technical details: OpenSSL issue 11381commit for corresponding fix.

As we found Nimble could also receive such errors unexpectedly during SSL send operations which could lead to unexpected connection interruptions when streaming over any protocol that use TLS/SSL, such as HLS, MPEG-DASH, SLDP, Icecast as well as RTMPS in all modes.

Nimble 4.1.0-5 contains a fix for this behavior setting SSL_OP_IGNORE_UNEXPECTED_EOF flag for compatibility with OpenSSL 3.

OpenSSL 3 is used on Ubuntu 22.04, so if you're using 22.04 we'd strongly recommend to upgrade to Nimble 4.1.0-5 or later to avoid potential streaming issues.

Upgrade instructions

To upgrade Nimble Streamer to the latest version, please go to Nimble Streamer installation page, select your operating system and scroll down to "Operating, upgrading, uninstalling" section.

If you have any questions or issues please send them to our helpdesk.

October 25, 2023

GPS HTML overlays in Larix Broadcaster

Larix Broadcaster provides a wide variety of features for IRL streamers, from advanced connectivity options to web overlays.

To add more capabilities for IRL, we introduce GPS data support for HTML overlays. It allows showing current spatial position and other parameters.

The following parameters are supported:

  • Current date and time
  • Current GPS coordinates (latitude and longitude)
  • Instantaneous speed of the device
  • Altitude, i.e. height above the sea level
  • Device's azimuth relative to true or magnetic north
  • Current location name (e.g. as shown on Apple maps)

You can learn more about GPS overlays setup on GPS params page.


This feature is available as part of Larix Premium in-app subscription. By subscribing to Premium you support our engineering team and allow us to move forward with new features.


Download Larix Broadcaster:


September 29, 2023

WHEP WebRTC low latency playback in Nimble Streamer

Nimble Streamer team is continuously improving low latency streaming features to provide our customers with the best set of options they can choose from.

Last year we introduced WebRTC WHIP (WebRTC-HTTP ingestion protocol) support in Nimble Streamer to provide ultra-low latency ingest into the media server. You can read full WebRTC WHIP setup instructions and try it in action.

Now it's time to take the next step and give our customers low latency playback. Our team has always preferred to rely on open standards so we chose the best option available.

WebRTC WHEP (WebRTC HTTP Egress Protocol) provides easy communication between a server and a client, while being interoperable with other solutions that support WHEP signaling. This is a result of industry cooperation, thanks to Sergio Murillo and Cheng Chen who developed it into an IETF standard draft.

Nimble Streamer uses Pion implementation of WebRTC API. This framework not only gives the flexible API but also provides high-performance and low resource usage which completely correlates with our own approach to creating sustainable and cost-effective software.

We'd like to thank Sean DuBois and all Pion contributors for maintaining such a great framework.

1. WHEP support overview

Nimble Streamer generates WHEP playback output with the following codecs:

  • Video: H.264/AVC, VP8, VP9 and AV1
  • Audio: Opus

You can refer to supported codecs page to see how you can deliver the pre-encoded content and re-package it without additional action. For instance, you can ingest VP8 video and Opus audio using WebRTC WHIP and generate WHEP playback as is, with no additional overhead.

If your source has different codecs then you can transcode the content. E.g. if you get RTMP with H.264 video and AAC audio from your source, you use Live Transcoder to transcode AAC into Opus and then to pass through H.264 with no need for decoding and encoding.

You can read more about various scenarios in Further Usage section below.

The stream can be played in any browser using WHEP player. Please refer to Player setup and usage section below for more details.

Notice that WHEP AV1 playback is currently working only in Chrome. We're looking forward to other browsers and platforms to support it via WebRTC.

Our team likes to contribute back to the open source that use use. In order to handle AV1 WebRTC playback, we've made a code contribution into the Pion framework to add proper AV1 support.


2. Server setup process


Follow these steps to get WHEP working in your Nimble Streamer instance.
We assume you already have a paid WMSPanel account. If you don't, please sign up and subscribe.

2.1 Installation

First, make sure you've installed the latest Nimble Streamer or upgraded it to the latest version.

Second, WHEP implementation has some dependencies on Nimble Live Transcoder so you need to install it first, then subscribe for a license and register it on your server. Please refer to Transcoder installation page for details.

2.2 Set up SSL for Nimble

The next step is to enable SSL for your Nimble instance for further playback.

You can set up your SSL certificate using this general instruction. You may obtain CertBot Let's Encrypt free certificate as we've described here. For testing purposes you may create your own self-signed certificate but in order for it to work, you'll need first to open any https:// page like https://yourhost.com:port/ and accept security risk. For production purposes in general, you need to have a valid SSL certificate. Also, your server must be assigned for the domain of this certificate.

Once you've set up SSL for Nimble, you need to test it. Open https://yourhost.com in your browser, where yourhost.com is the host of your Nimble. If you get error 404 and have no warnings from your browsers then your SSL was set up is properly and is working.

2.3 Add parameters into config

The next step is to enable the feature set in Nimble config file. On Linux, it's located at /etc/nimble/nimble.conf.  Please check parameters reference page for more details about operating with the config.

Here are the parameters you need to have in the config
webrtc_whep_support = true
access_control_allow_headers = content-type,location
access_control_expose_headers = location
transcoder_change_params_on_the_fly_enabled=true
If you use WHIP ingest, you're familiar with some of those as we described in respective article. So you just need to put webrtc_whep_support there in addition.

Once you've added the parameters, don't forget to re-start Nimble as described here.

2.4 Enable WHEP for streaming application


Now you need to enable WHEP for the output applications that you will provide for your users.

Log into your WMSPanel account, go to Nimble Streamer top menu and click on Live streams settings item.

Here you can enable WHEP either globally on server level, or for a specific application.


Once you enable the checkbox and save settings, you won't need to re-start Nimble, it will be applied automatically within a few seconds.


3. Player setup and playback

Now lets see how you can play the WHEP low latency stream generated by Nimble Streamer.


3.1 WHEP Player

Softvelum WHEP Player is available in our github account for cloning and further usage.

We forked WebRTC player by Eyevinn as we consider it the best open source player for this purpose. Besides the fork, we contributed back the code for handling audio-only WHEP streams, we'll show this use case below.

Please refer to Getting started section in our repo to see how you can set up and customize the player for your own website, e.g. enabled audio-only playback.

Try now: you may also try our WHEP player at Stream test page where we provide several most popular players to check your streams. You'll find webrtc-player as the first option in the list. 


3.2 Playback URL

WHEP uses HTTP for establishing connection so the URL for playback will look familiar:

https://127.0.0.1:8443/live/whip/whep.stream

You can see HTTPS protocol and port 8443 for streaming via SSL.

Please also notice "whep.stream" element after the stream name. This is how Nimble Streamer will handle it as a request for WHEP playback.

App and stream name is defined based on your input and output streams setup, please refer to respective protocol setup instruction.

You can use that URL for further playback in our WHEP Player or any other WHEP-enabled player.


4. Network-related parameters


By default, Nimble Streamer works in ice-lite mode.

If Nimble server instance runs on a host with public IP address then additional configuration is not needed.

If a server instance runs on Amazon EC2 then you'll need to create an additional config file at /etc/nimble/whep_config.json and add the following JSON there:
{
"NAT1To1IPs":"a.b.c.d",
"NAT1To1CandidateType":"host"
}
where "a.b.c.d" is a public address assigned to AWS server instance. If it has multiple IP addresses, just add them in the same parameters separating by comma like this:
{
"NAT1To1IPs":"a.b.c.d,w.x.y.z",
"NAT1To1CandidateType":"host"
}
This file is processed by Nimble at the beginning of each new publishing session, so you can change it without re-starting the server.

To define ports range, you can also add these parameters:
{
"PortMin":1000,
"PortMax":40000
}
In this case the candidates will be selected only from the range of ports 1000 to 40000.

If you want to use the same port for all WHEP playback connections, you can use the following parameter instead of PortMin and PortMax:

{
  "ICEUDPMuxPort":1234
}

Notice that you cannot use the same port for both WHEP playback and WHIP ingest simultaneously.

If you use network parameters mentioned above, the combined JSON in this case will be:
{
"NAT1To1IPs":"a.b.c.d",
"NAT1To1CandidateType":"host",
"PortMin":1000,
"PortMax":40000
}
JSON format requires this kind of syntax and if you add them in different blocks or have no commas between parameters, Nimble will not process the config.

5. Further Usage

WHEP Playback is a great addition to the existing set of output protocols. This means that you can create new combinations of input with output as well as use proven existing feature sets on top of WHEP playback to add more power to it.


5.1 Live transmuxing and transcoding

The number of use cases for combining WHEP with other streaming protocols is huge, here are some of them.

Combine WHIP input and WHEP output. You can take WHIP ingest into Nimble instance and then re-package it into WHEP playback. It's a very light-weight operation, so ultra-low latency WebRTC ingest from your browser or mobile app will flow seamlessly into low latency playback in other browsers. Use this article to set up WHIP ingest and use the setting above to complete the WHEP part.

Convert RTMP into to WHEP. You use your favorite RTMP-powered media source to deliver H.264 video with AAC audio into Nimble Streamer. Then you set up Nimble Live Transcoder scenario which passes through the H.264 content without decoding/encoding, decodes AAC and encodes it into the Opus output. With this H.264/Opus combination you then create WHEP output just like we described above. This will not require too much resources because audio transcoding is a cheap operation.

Use SRT HEVC source for WHEP output. You use some HEVC-powered encoder or media server which is able to deliver it via SRT stream. Once you route it to Nimble instance, you can then use Live Transcoder to transcoder HEVC video into H.264 or VP9, and also transcode AAC into Opus. This resulting content is then easily delivered via WHEP into viewers' browsers for convenient playback.

These are just few possible option, but the general idea is that you may juggle transmuxing and transcoding features of Nimble Streamer to achieve the best combination of codecs and protocols to provide the best user experience. And all that comes at the low cost of ownership.


Notice on transcoding scenarios for Opus output.
Once you create a scenario and put audio encoder element, please use FFmpeg as encoder and libopus as codec name as shown below.


5.2 Audio-only low latency playback

Nimble Streamer is used extensively for audio-only scenarios, like online radios. This includes a huge Icecast feature set, audio-only HLS and audio only SLDP.

With WHEP in board, you can add one more element to this kind of cases. Audio processing is a light-weight operation that will enable you to give more playback options to your listeners.

Most obvious case is when you ingest Icecast, transcode audio from MP3 or AAC into Opus, and then just generate WHEP output for browser playback.

Speaking of audio-only, you can do the same with Dante audio which is widely used in professional live production environments. Just set up Dante input and transcode it  into Opus output the same way as you do for Icecast.

In addition, you can use traditional sources like RTMP or SRT to pick up audio track from it, transcode into Opus and make audio-only output via WHEP. It works the same way as for Icecast transformation.

MPEGTS input can carry multiple tracks, including several audio channels for different languages or additional comments. You can pick up each track and generate Opus output.

Audio mode is something that we wanted to take care of, knowing the interest from our online radio customers to it. As was mentioned above, we even made a contribution into Eyevinn's player to to handle this case.

5.3 NDI to WHEP

NDI ingest can also be a good source for WHEP output. If you're running a live production based on that technology, you can get NDI into Nimble Streamer and transcode it into WHEP live stream. This will give you a seamless ultra-low latency bridge between your internal production environment and the Internet viewers in their browsers.

It's a unique use case to any existing solution so if you use NDI, you should definitely try it. Just set up the NDI input and the procedure above to generate WHEP.

5.4 Playout (server playlist)


Nimble Streamer Playout, or as we often call it server playlist, is also able to generate WHEP output. With Playout way you may combine live streams with pre-recorded videos. This allows creating your own TV or radio station with just one Nimble Streamer instance.

So now your viewers can watch Playout output in the browser with the WHEP Player, just like they do with other protocols.

Notice that you will still need to transcode the Playout output into supported video codecs and Opus audio, unless your original content is already encoded with them. Once you set up Playout config, just add the Transcoder scenario to make the proper output.

5.5 Paywall and authorization features

Nimble Streamer Paywall feature set fully covers WHEP playback just like it does for other protocols

So everything you need to protect your stream, can be used for WebRTC playback. Just check an additional protocol in your WMAuth rule.


5.6 HTTP aliasing

WHEP URLs can also be used in combination with HTTP Aliasing feature.

Aliasing allows mapping multiple names to single media stream in order to add some flexibility into streaming process. It's good for cases when you have some media stream and you need to provide it under different names. For example, you are a content provider and want to give your stream to multiple partner websites and services. Aliased streams can use different security and monetization approaches as well.

So full aliase-based flexibility is now available for WHEP as well.


5.7 Playback statistics

Last but not least, WMSPanel web service provide wide and rich feature set for reporting the viewers' statistics which now include WHEP views. Any stats and metrics our customers have been using for more than a decade, now cover low latency playback as well:

  • Daily stats with geo-location and devices report
  • Deep stats with per-stream daily stats
  • Unique viewers
  • High-precision reporting

WHEP playback is handled like any other HTTP-based protocol so it has the same proven reliability.


As WebRTC allows tracking lost packets, the daily stats have Lost column which indicated the lost traffic in addition to overall bytes sent and received.


6. Performance tuning

If you serve your live streams to dozens of thousands of viewers, you may need to tune up the perfomarnce of Nimble Streamer for that. There are a couple of a parameters that you can put into  /etc/nimble/nimble.conf. file.

  • webrtc_whep_worker_threads - this parameter sets the number of working threads for WHEP sessions processing. It's "1" by default.
  • webrtc_whep_max_viewers - in some high load cases the number of simultaneous WHEP connections can be significant. By default Nimble processes 2500 simultaneous connections per each WHEP working thread, but you can increase/decrease this value with this parameter.

Please refer to parameters reference for more options.



Let us know how this feature works for you and what else we can do to enhance it from your practical perspective.

Later on we'll introduce more tutorials - both text and videos - to show full power of WebRTC WHEP playback.

Follow us in social media to get updates about our new features and products: YouTube, Twitter, Facebook, LinkedIn, Reddit, Telegram