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.

Also notice that HLS DVR streams can be added to SLDP HTML5 Player for rewinding low latency streams. Read this article for details.

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.

Also notice that HLS DVR streams can be added to SLDP HTML5 Player for rewinding low latency streams. Read this article for details.

Related documentation

July 27, 2017

VP8 and VP9 support in SLDP HTML5 player

Our customers keep adding our new real-time low latency protocol SLDP into their streaming workflows as it allows sub-second delay for live streaming delivery. Some basic usage of SLDP protocol is described in this article which describes typical usage scenarios.

People ask us about adding new capabilities into SLDP technology. One of them is adding VP8 and VP9 codecs - those are open and royalty free video coding formats developed by Google. Nimble Streamer Live Transcoder now supports these protocols transcoding in addition to already supported VP8/VP9 transmuxing feature set.

SLDP is codec-agnostic protocol so in order to have full support for VP8/VP9 from source to the viewer, we only needed to add it into our HTML5 player.

So today we'd like to announce that VP8 and VP9 support was added into SLDP HTML5 web player. This type of playback fully depends on platform support, so it can be currently played in Chrome, Firefox and Opera and possibly in Microsoft browsers over time.

You can use SLDP for streaming in various bitrate modes. First you can stream single-bitrate VP8/VP9 if you know your target audience can play it.

Another option is to create ABR group to include streams encoded with both H.264 and VP8/VP9. In this case our SLDP HTML5 player will choose stream with H.264 codec if target browser or platform doesn't support VP8/VP9 playback. That would give you capabilities for flexible delivery of your content to multiple platforms.

We'll be adding other codecs support per our customers' requests so please contact us to get help or suggest new features.

July 24, 2017

Publishing stream to Periscope

RTMP republishing is widely used by Nimble Streamer users to deliver live streams to various types of destinations, including other media servers, CDNs, YouTube or Twitch.

Periscope live streaming platform also takes RTMP streams as input so our customers use that as a target too. As Periscope requires some additional stream setup, we've created a dialog in our UI to cover that use case.

As a source for your stream you can use any delivery method supported by Nimble Streamer.


Once the input stream is taken by Nimble, you can perform a setup for publishing it to Periscope.

July 18, 2017

Transcoding VP8 and VP9 in Nimble Streamer

VP8 and VP9 are open and royalty free video coding formats developed by Google. Nimble Streamer Live Transcoder now supports these protocols transcoding in addition to already supported VP8/VP9 transmuxing feature set.

Live Transcoder allows performing both decoding and encoding.

To receive VP8 and VP9 for transcoding, Nimble Streamer allows processing RTSP from published and pulled sources. The result stream can be delivered using RTSP and SLDP protocols.

Decoding


The following methods are currently supported for decoding VP8/VP9 content for further transformation:
  • Software decoder
  • Intel® Quick Sync technology for hardware decoding. VP8 is supported on Windows and Linux, VP9 is supported only on Windows. 
  • NVidia® NVENC hardware decoding for Windows and Linux.
You can specify the decoding method in decoder block in any transcoding scenario just like you specify it for other codecs.

Encoding


Currently the encoding is performed only via software encoder. To use it for VP8 and VP9, open encoder block in your transcoding scenario and select "libvpx" from dropdown menu 

Setting encoder for VP9 and VP8.

You will then be able to select Codec and specify other parameters listed below.


libvpx VP8/VP9 encoder parameters


quality

Quality Deadline

  • best - use the Best Qulity Deadline;
  • good - use the Good Qulity Deadline;
  • rt(default) -use the Real Time Qulity Deadline;

threads

Number of threads that will be allocated to the encode process

profile

Sets the encoder profile. Supported value: 1. Values 1-3 will be supported in the future versions of Transcoder.

lag_in_frames

Defines an upper limit on the number of frames into the future that the encoder can look. Values range: 0 to 25.

bitrate/b

Bitrate in kbps.

rc_mode

Rate control mode.

  • vbr- variable bitrate mode
  • cbr -  constant bitrate mode
  • cq -  constrained quality mode
  • q - constant quality mode


cq_level

Constrained Quality Level, in CQ mode the encoder will try to encode normal frames (all frames apart from key frames, golden frames and alternative reference frames) at a quantizer / quality level of cq_level. Values range: 0 to 63.

min_q

Minimum (Best Quality) Quantizer.

max_q

Maximum (Worst Quality) Quantizer.

buf_sz

Decoder Buffer Size indicates the amount of data that may be buffered by the decoding application. Note that this value is expressed in units of time (milliseconds). For example, a value of 5000 indicates that the client will buffer (at least) 5000ms worth of encoded data.

buf_initial_sz

Decoder Buffer Initial Size indicates the amount of data that will be buffered by the
decoding application prior to beginning playback. This value is expressed in units of time (milliseconds).

buf_optimal_sz

Decoder Buffer Optimal Size indicates the amount of data that the encoder should try to maintain in the decoder's buffer. This value is expressed in units  of time (milliseconds).

undershoot_pct

Rate control adaptation undershoot control. This value, expressed as a percentage of the target bitrate, controls the maximum allowed adaptation speed of the codec. This factor controls the maximum amount of bits that can be subtracted from the target bitrate in order to compensate for prior overshoot.
Values range: 0 to 1000

overshoot_pct

Rate control adaptation overshoot control. This value, expressed as a percentage of the target bitrate, controls the maximum allowed adaptation speed of the codec.
This factor controls the maximum amount of bits that can be added to the target bitrate in order to compensate for prior undershoot. Values range: 0 to 1000.

kf_mode

Keyframe placement mode. This value indicates whether the encoder should place keyframes at a fixed interval, or determine the optimal placement automatically.
Values: auto/disabled

kf_min_dist

Keyframe minimum interval. This value, expressed as a number of frames, prevents the encoder from placing a keyframe nearer than kf_min_dist to the previous keyframe.
At least kf_min_dist frames non-keyframes will be coded before the next keyframe. Set kf_min_dist equal to kf_max_dist for a fixed interval.

kf_max_dist

Keyframe maximum interval. This value, expressed as a number of frames, forces the encoder to code a keyframe if one has not been coded in the last kf_max_dist frames.
A value of 0 implies all frames will be keyframes. Set kf_min_dist equal to kf_max_dist for a fixed interval.

drop_frame

The drop frame parameter specifies a buffer fullness threshold at which the encoder starts to drop frames as a percentage of the optimal value specified by buf_optimal_sz. If it is set to 0 then dropping of frames is disabled.
Values range: 0 to 100.

resize_allowed

Enable/disable spatial resampling, if supported by the codec.

resize_up, resize_down

The resize up and down parameters are high and low buffer fullness "watermark" levels at which we start to consider changing down to a smaller internal image size, if the buffer is being run down, or back up to a larger size if the buffer is filling up again. The numbers represent a percentage of buf_optimal_sz.
Values range: 0 to 100

error_resilient

Enable error resilient modes indicates to the encoder which features it should enable to take measures for streaming over lossy or noisy links.

  • 0 - disabled
  • 1 - Improve resiliency against losses of whole frames
  • 2 - The frame partitions are independently decodable by the bool decoder, meaning that partitions can be decoded even though earlier partitions have been lost. Note that intra prediction is still done over the partition boundary.
  • 3 - Both features

auto_alt_ref

Codec control function to enable automatic set and use alf frames.

  • 0 - disable
  • 1 - enable

sharpness

Codec control function to set sharpness.

static_tresh

Codec control function to set the threshold for MBs treated static.

arnr_max_frames

Codec control function to set the max no of frames to create arf.

arnr_strength

Codec control function to set the filter strength for the arf.

tune

Optimize output for PSNR or SSIM quality measurement.
Values: psnr/ssim(default)

max_intra_bitrate_pct

Codec control function to set Max data rate for Intra frames.

cq_level

Constrained Quality Level, in CQ mode the encoder will try to encode normal frames (all frames apart from key frames, golden frames and alternative reference frames) at a quantizer / quality level of cq_level. Values range: 0 to 63.

libvpx VP8-specific parameters


speed

Codec control function to set encoder internal speed settings.
Values range: -16 to 16

token_parts

Codec control function to set the number of token partitions.

screen_content_mode

Codec control function to set encoder screen content mode.

  • 0 - off;
  • 1 - On;
  • 2 - On with more aggressive rate control;


noise_sensitivity

control function to set noise sensitivity

  • 0 - off;
  • 1 - OnYOnly;
  • 2 - OnYUV;
  • 3 - OnYUVAggressive;
  • 4 - Adaptive;


gf_cbr_boost

Boost percentage for Golden Frame in CBR mode.


libvpx VP9-specific parameters


speed

Codec control function to set encoder internal speed settings.
Values range: -8 to 8

max_inter_bitrate_pct

Codec control function to set max data rate for Inter frames.

gf_cbr_boost

Boost percentage for Golden Frame in CBR mode.

lossless

Lossless encoding mode.

  • 0 - lossy coding mode ;
  • 1 - lossless coding mode;


tile_cols

Number of tile columns

  • 0 - 1 tile column ;
  • 1 - 2 tile columns;
  • 2 - 4 tile columns;
  • n - 2**n tile columns;

tile_rows

Number of tile rows

  • 0 - 1 tile row ;
  • 1 - 2 tile rows;
  • 2 - 4 tile rows;

aq_mode

Adaptive quantization mode.

frame_boost

Periodic Q boost.

  • 0 = off ;
  • 1 = on;

noise_sensitivity

Noise sensitivity.

  • 0: off
  • 1: On(YOnly)

tune_content

Content type

  • default - Regular video content (Default);
  • screen - Screen capture content;

min_gf_interval

Minimum interval between GF/ARF frames

max_gf_interval

Maximum interval between GF/ARF frames

level

Target level

  • 255: off (default);
  • 0: only keep level stats;
  • 10: target for level 1.0;
  • 11: target for level 1.1;
  • ...
  • 62: target for level 6.2

row_mt

Row level multi-threading

  • 0 : off;
  • 1 : on;

alt_ref_aq

Special mode for altref adaptive quantization

  • 0 - disable
  • 1 - enable


Easy control


Live Transcoder has easy to use Web UI which provides drag-n-drop workflow editor to apply transcoding scenarios across various servers in a few clicks.
With FFmpeg filters you can transform content in various ways, e.g. change the video resize, make graphic overlays, picture-in-picture, key frames alignments, audio re-sampling etc.
Take a look at our videos to see Transcoder UI in action.


Feel free to visit Live Transcoder webpage for other transcoding features description and contact us if you have any question.

Related documentation


Live Transcoder for Nimble StreamerBuild streaming infrastructureTranscoder web UI previewLive Streaming featuresBuild streaming infrastructure,

July 7, 2017

Vote for Softvelum

The Streaming Media European Readers' Choice Awards 2017 voting has been started to get industry opinions on the best solutions on the market. Last year we were selected as the finalist for best streaming innovation for Nimble Streamer. Let's see what we get this year.


Our company is presented in 4 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. Best Streaming Innovation: Nimble Live Transcoder
  2. Mobile Video App or Solution: Larix Broadcaster
  3. Server Hardware/Software: Nimble Streamer
  4. Transcoding Solution: Nimble Live Transcoder

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

2. Confirm your vote


Voting closes on August 1st, and at that point, all voters will receive an email asking them to to confirm their votes; only these confirmed votes will be counted.

The finalists will be announced on 15 August, and the winners will be announced in the Autumn issue of the European edition of Streaming Media magazine.


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