August 28, 2017

Splash image, MP3 and other settings of SLDP HTML5 player

Our company keeps improving HTML5 player for our low latency protocol - SLDP. You can find protocol overview in this page and some basic setup and usage described in this article.

We've got some updates for you that might be interesting.

Splash image


You can now define the splash screen image which is shown before a user initiates the playback.
It's defined by splash_screen parameters.


MP3 support


We've added MP3 audio codec support for Safari and Firefox. Check also audio-related features of Nimble Streamer in addition.

Multiple instances


SLDP player may now be used in multiple instances on the same web page.
You use container parameter for each instance to specify proper element to show the player in.

Disabling ABR


By default, if your initial stream has multiple channels (e.g. renditions), they will be shown in the list of channels in ABR settings.
However you can lock specific player on a specific rendition using adaptive_bitrate parameter. It's "true" by default. You can set it to "false" to lock the rendition, in his case the initial_resolution parameter will be used to determine the default stream, and if it's absent then the lowest resolution will be taken.

You can see these and other parameters of our HTML5 player on this player page.

Take a look at the answers for frequent questions to improve your SLDP usage and visit SLDP website and contact us in case of any questions.

Related documentation


SLDP low latency streaming, SLDP Player, Live Streaming via Nimble Streamer, Live Transcoder for Nimble Streamer,

August 21, 2017

Review: Softvelum Nimble Streamer Is Flexible and Well-Featured

Recently Jan Ozer, a leading expert on H.264 encoding for live and on-demand production, and a contributing editor to Streaming Media Magazine, has published a full review our Live Transcoder:

Review: Softvelum Nimble Streamer Is Flexible and Well-Featured
The overall impression is very good although he found some things to improve in our products.

We'd like to thank Jan for sharing his opinion, it gives us a great feedback and inspiration.

Feel free to share your thoughts in your own blogs, we appreciate any feedback from our users.

August 20, 2017

Streaming Media Readers' Choice Awards 2017

The Streaming Media Readers' Choice Awards 2017 voting has been started to get industry opinions on the best solutions on the market.

Our company is presented in 2 nominations and we hope to get your votes. Here's a brief instruction how to proceed.

1. Find and vote


Go to voting page here, enter your name and contacts to see the full list of nominees.

Find Softvelum products in the following nominations:

1. Encoding Software: Nimble Live Transcoder.
Jan Ozer has a comment in his latest article called Review: Softvelum Nimble Streamer Is Flexible and Well-Featured: "The product, which has been nominated for a Streaming Media Europe Readers’ Choice Award, seems like a real winner to me.

2. Media Server: Nimble Streamer.
Well-known media server, the finalist for Best Innovation category in European Reader's Choice Awards of 2016, is now nominated again with more useful features and latest technologies on board.

We hope you enjoy our products and will choose them in the list.

2. Confirm your vote


You'll receive an email asking you to confirm your vote (to prevent automated ballot-box stuffing). Be sure to confirm, or your vote won't count.

Voting closes September 25.

Winners will be announced November 3 at Streaming Media West.


Thanks for being our loyal customers, looking forward to getting your votes.


August 14, 2017

Setting UDT in Nimble Streamer

Nimble Streamer doesn't have UDT support any more.

Instead we encourage live streaming community to use SRT - Secure Reliable Transport - a UDP-based protocol for low latency live streams delivery with error recovery and other high-reliability features.

Nimble Streamer has full support for SRT protocol from both sending and receiving sides, as Softvelum team is an active participant of SRT community.

August 8, 2017

Use SLDP player latency tolerance against environment glitches

Our company keeps improving new real-time low latency protocol called SLDP. It provides quick start, sub-second  delay and real-time ABR for live streaming delivery. You can find protocol overview in this page and some basic setup and usage described in this article.

One of the features of SLDP is an ability to keep up with live stream without delays regardless of environment glitches. Let's take a look at this capability more closely.

Let's say you have a live stream which you'd like to take a close look real-time, e.g. you're watching a game or following some bid at auction.

At some point, an environment glitch may appear on a viewer side, e.g. CPU stuck with decoding or some network delay happened. In this case the picture in a player will freeze, waiting to proceed. Meanwhile stream's frames will still be arriving without being displayed.

There are 2 possible scenarios here:
  1. Resume playback from the point where the glitch has started.
  2. Skip the playback to initial latency.

The first option is the default one. To handle the second option, SLDP player supports latency_tolerance parameter. It's a latency retention expressed in milliseconds. When initial delay has increased by more than the specified value, it forces the player to reestablish the initial latency as it becomes possible.

It's important to understand that latency retention has its cost, the player skips a part of stream to preserve latency. The rough analogy can be TV broadcast, when corrupted image is displayed but the whole stream is not delayed.

So you can use it if your streaming use cases require that type of behavior.

You can see this and other parameters of our HTML5 player on this player page.

From the media server setup perspective SLDP is just another output protocol from the list of supported ones, which you can see on our live streaming digest page. So feel free to try it in action with our HTML5 web player.

Take a look at the answers for frequent questions to improve your SLDP usage and visit SLDP website and contact us in case of any questions.

Related documentation


August 4, 2017

Using offset to decrease start time (zap time) in SLDP player

Recently we introduced new real-time low latency protocol called SLDP. It provides sub-second delay for live streaming delivery for the cases when it's truly important. Some basic usage of SLDP protocol is described in this article.

One of the key features of SLDP is a quick start - a.k.a. zap time or join latency - of a stream on a client side. Typically the best way to reduce start time is to set GOP size to 1 second or less. This can be done with any transcoder, e.g. Nimble Live Transcoder. This will increase bandwidth however so you need to reach some balance between start time and traffic consumption.

So if you cannot make that GOP size reduction, SLDP has an offset player parameter which allows affecting the start-up behavior. The following description shows how you can use it for your use cases.

Typically, a playback starts with a key frame of each GOP (group of pictures) as the player cannot start decoding and processing without the key frame information. This means a delay between the start of connection and the start of the playback and it may be several seconds, depending on the encoding settings - all this time a viewer will see a black screen waiting for a picture. This is what needs to be avoided, let's see how this can be avoided.

Here's a pseudo-graphics example of frames sequence of a live streams:

   |---------|---------|

Here, "|" means key frame and "-" means intermediate frames of any type. In this example we have GOP of 10 seconds total.

Once a viewer connects to the stream, he will probably get non-key frame and will have to wait until some key frame arrives:
   |---------|----n----!
Here, "n" means a moment of time which is "now" and "!" is the key-frame which will be used to start the playback.

This means that a playback will start 6 seconds after the moment when the player connected to the server.

Now we add "offset" parameter which specifies how many milliseconds back from now a source media server needs to go back to get previous key frame. In our example this will be 8s. The player connects to the server and defines the offset. The server gets back to 8s of this stream and checks this is the next key frame after the selected moment:
   |---p-----!n--------|
Here you see "!" is right before the "now" time mark. This means that a player will start playing from the moment of time which is only 1s behind current time.

Another example - a player connects to a source server 1 second before the next key frame. The offset is 8s so there will be no earlier keyframe. However, the nearest key frame arrives just 1 second after the connection, so there will be no huge delay.
   |---------|p-------n!
As you can see, the offset should be less than the size of your GOP, otherwise in previous example a viewer will get a key frame from previous GOP while the next GOP is just about to arrive:

   |--------p!--------n|
So we recommend setting offset to around 80% of expected GOP size.

The offset parameter is optional and it's not enabled by default. So you can specify it if your streaming scenario requires quick display. If you use short GOPs, e.g. 1 second or less, you may just skip it as it's not required in that case.


You can see this and other parameters of our HTML5 player on this player page.


From the media server setup perspective SLDP is just another output protocol from the list of supported ones, which you can see on our live streaming digest page. So feel free to try it in action with our HTML5 web player.

Take a look at the answers for frequent questions to improve your SLDP usage and visit SLDP website and contact us in case of any questions.

Related documentation