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 x64 or Android.

The mobile SDKs coming soon to cover iOS and Android devices.

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.

April 9, 2017

Streams failover hot swap via Live Transcoder

Nimble Streamer Live Transcoder now supports hot swap capabilities for live streaming scenarios.

This covers use cases when there is some original (primary) stream active all the time and a substitute (secondary) stream to replace it on some occasions. Those include cases like emergency stream activation and an opposite one like streams failover which is described below.

During stream failover, the substitute stream is always active and once the original stream goes down, the data from substitute stream is taken. Once the original stream is online again, it replaces the substitute stream back.

This feature requires making the swap smoothly from viewers point of view, which means a player must not stop the playback. Nimble Streamer covers this properly.

The setup is similar to emergency stream hot swap. with a few changes.

April 5, 2017

Emergency streams hot swap via Live Transcoder

Many of our customers requested us to support hot swap capabilities for live streaming scenarios.

This basically refers to use cases when there is some original (primary) stream active all the time, some substitute (secondary) stream to swap on some occasions, and either of the following actions needs to be done:

  • Emergency stream activation. The substitute stream is usually inactive but when it goes live, it must replace the original stream. Once the secondary stream becomes inactive, the original stream must be continued.
  • Failover stream. The substitute stream is active and once the original stream goes down, the data from substitute stream is taken. Once the original stream is back online, it replaces the substitute stream again.

Both cases require to make the swap smoothly from viewers point of view, which means a player must not stop the playback. Nimble Streamer handles both cases correctly. This article covers the first case.

Emergency stream hot swap is used for several cases, and the most notable example is the support of United States Emergency Alert System (EAS). It requires a broadcaster to replace any media with the content provided by EAS once it becomes available.

Let's take a look at the setup process of this capability.