May 30, 2017

Using SLDP with Nimble Streamer

Recently we introduced new real-time low latency protocol called SLDP. It allows sub-second delay for live streaming delivery for the cases when it's truly important.

From the setup perspective it's just another output protocol from the list of supported once which you can see on our live streaming digest page.
However, let's see how it can be added to your streaming scenarios based on Nimble Streamer, step-by-step.

Nimble Streamer upgrade

SLDP works on any latest Nimble Streamer version. So you can either install it or upgrade - the least version you should consider is SLDP is not working in earlier versions.

Operating SLDP

Enabling protocol

From the control perspective, SLDP is just another output protocol which needs to be enabled either for entire server or for specific application.

Notice that if you use published RTMP or announced RTSP as a source, you will need to re-publish the stream after enabling the protocol. Any newly applied protocol is enabled only when on the stream's start.

Click on Nimble Streamer -> Live Streams Settings menu. You will see Global tab for server-wise settings.

Click on Softvelum Low Delay and save settings to enable SLDP output.

You can also click on Applications tab to see list of available applications with their specific settings.

Click on edit icon to see app details dialog.

Check Softvelum Low Delay and save settings to enable it for this application.

As we noticed earlier, you need to re-publish the stream after enabling the protocol if it uses a publishing source.

Setting ABR

SLDP supports adaptive bitrate and it needs to be set up before any usage. It is done the same way as for HLS and MPEG-DASH. Read this article to see all the details.

Setting paywall

Nimble Streamer Paywall feature set supports SLDP just as all other protocols. So if you apply geo-location block to some application, its SLDP streams will be blocked properly, the same is valid for other blocking features.

If you create hotlink protection rule, you will need to select SLDP to protect it from re-streaming.


SLDP is available for playback in our players. As example, Nimble Streamer allows playback via direct link which you can insert into your HTML5 player code.
The link will be similar to other URLs: if you have http://server/app/stream/playlist.m3u8 stream then your SLDP stream URL will be ws://server/app/stream

To see sample a URL, click on Nimble Streamer -> Live Streams menu, select the required server and then click on Outgoing streams area to see all produced streams.

Then click on question mark to see Sample URL for Player dialog.

It will include full URL of stream and also a sample code for HTML5 SLDP player.

You can also play it in iOS applications built with SLDP Player SDK.

ABR streaming

SLDP supports adaptive bitrate streaming, so both Nimble Streamer and our web player has full support for ABR.
ABR setup is described in this article so follow its instructions to create proper streams.

Using SSL connection

SLDP can be secured with SSL and it's set up the same way as other HTTP protocols which Nimble Streamer supports. Read this article for all details regarding the setup.

The output URL for SSL connection will start with wss:// prefix, e.g. wss://server/app/stream.

Useful articles

First, take a look at the answers for frequent questions to improve your SLDP usage.
Also, please read Reliable Low Latency Delivery with SRT+SLDP post in Haivision blog describing a combination of both protocols for building reliable delivery networks.

Please visit SLDP website and contact us in case of any questions .

Related documentation

May 23, 2017

Introducing SLDP

Low latency has been a trending issue during past years as Flash and RTMP are being deprecated by the industry. So media streaming companies are trying different options to handle real-time video and audio delivery. Our company are getting requests about providing the solution which might address this concern.

We introduce SLDP: Softvelum Low Delay Protocol.

It's a last-mile delivery protocol to end-user devices at multiple platforms. SLDP is based on WebSockets.

It's basic capabilities are:
  • Sub-second delay between origin and player.
  • Codec-agnostic to play whatever your end-user platform has - H.264, VP9, HEVC.
  • ABR support with switching channels taking just a GOP time and each channel may use its own codec.
  • HTTP and HTTPS on top of TCP: use it with any network settings.
SLDP HTML5 playback is available in MSE browsers via light-weight JavaScript player. It works fine in Chrome, Firefox, Safari, Chromium and Microsoft Edge on the hardware platforms which have that support, like PC, Mac or Android.

As for server side, at the moment SLDP transmission is available Nimble Streamer. It's just another protocol output supported by our server. Any supported live protocols can be used as an input.

Feel free to try it in action right now by installing or upgrading your Nimble instance and selecting SLDP in live streams settings besides existing methods.

Please visit SLDP website and contact us in case of any questions as we're moving on with SLDP so your feedback is appreciated.

Related documentation

May 5, 2017

FAQ: Why are you better than your competitors?

Our trial users often ask us similar questions like "How are your solutions better than competitors' products? What are your benefits and advantages over products X, Y or Z? Why should I choose you instead of competitors?"

So basically the question is "Why do you think you are better than your competitors?"

The short answer is simple: You tell us why.

OK, let us give you more detailed answer.

Your project needs tools for media streaming, such as a media server, or a transcoder, or a mobile broadcasting solution. So you make a list of your own requirements and your perfect solution must comply with them.

The next step for you is to make a list of solutions you'd like to try before making your choice. Each product category has several candidates these days but the list will not be huge anyway.

Now the real work starts. You should install and try every candidate solution you find proper. Yes, install it, set it up and run your own test use cases and scenarios.
You should take a look at these areas of expertise:

  • Feature set. This is what you're actually looking for the most. All solutions on the market have ~80% of their functionality be the same. Some solutions are unique in their own area of expertise - and that 20% difference might be something needed for your project. And of course you need to check every feature you want to use, don't trust marketing materials.
  • Cost of ownership. Both CAPEX and OPEX should be considered, including license cost, hardware cost, consultants pricing etc. You must know your total expenses and revenues better than anyone, so use simple math instead of salesforce to help you.
  • Support and documentation. You should carefully check how each company support team handles your requests. You may need their help in future so need to be sure they will help accurately and on time. You don't want that documentation to be outdated and you expect it to help, not to confuse. Ask questions to support team in case if docs cannot clarify some points. 
  • Legal questions. Make sure the selected products have appropriate license agreements for used patents and technologies. Like we have. You don't want to find yourself in the middle of a lawsuit for patent infringements.

All these points matter, so you should carefully check them.

If you ask anyone about their solutions instead of trying yourself, you will probably be told lots of good things but no one's advice can compare with your own experience.

Trust your conclusions, don't listen to anyone, make your own decisions and decide what's best for you.

Another important point is that you should not rely on a single solution or tool set, you need to be familiar with several solutions. You can use them as soon as your requirements change or if any current solution becomes compromised or its support becomes discontinued.

Hopefully we answered your initial question.

If you still have something to ask, just contact us.

May 3, 2017

Encoding to MP3 with Nimble Streamer LIve Transcoder

MP3 audio format is widely used besides AAC. In April of 2017, the last patent related to MP3 expired. So it can now be used with no royalties or other limitations as part of audio processing and transmission scenarios.

Our Live Transcoder now allows taking various audio formats as input, such as

  • AAC
  • MP3
  • MP2
  • Speex
  • PCM G.711 (a-law and μ-law)

The output audio formats now are

  • AAC
  • MP3

So you can now easily transcode AAC to MP3. You can also apply various audio filters like re-sampling, transrating or audio channels manipulations.

This can be used as part of Nimble Streamer audio streaming capabilities.

Let's take a look at a simple scenario which takes incoming video+audio stream and transcodes audio into MP3, regardless of its original audio format.

Pulling HLS streams to process

Nimble Streamer has a transmuxing engine which allows taking any stream of any transport protocol in and generate streams in all available protocols as well. You can check our Live Streaming feature set to see full list.
Usually our customers use RTMP, RTSP or MPEG-TS to deliver streams to media server and create outgoing streams that can be consumed by end-users. However, there are cases when only HLS streams are available as a source. So now Nimble Streamer also supports HLS as an input.

The setup is similar to MPEG-TS input setup and uses the same approach of input and output streams. Let's see how you can set this up.