July 3, 2019

Passing Icecast metadata in Nimble Live Transcoder

Nimble Streamer has an advanced audio streaming feature set. Live audio streaming covers transmuxing of Icecast pulled and published streams, audio transcoding in Nimble Live Transcoder and ads insertion via Nimble Advertizer.

Metadata is an important part of Icecast usage. We've previously added appending Icecast metadata to live streams and Icecast metadata passthrough tags support. However, by default Live Transcoder doesn't pass metadata through when transforming audio content.

Our long-term customers StreamGuys, who extensively use our audio streaming features, asked if we might add a passthrough of Icecast metadata while using Live Transcoder. Our clients' feedback has always driven our development so we keep adding elements which are helpful to entire audio streamers community.

We're glad to announce that we've improved Live Transcoder to allow setting up metadata passthrough for audio. This feature needs some additional setup so follow the instructions below if you'd like to use it.

1. Set up Nimble configuration


First, this feature needs to be explicitly enabled for the server.

Add this parameter into your nimble.conf file:
icecast_forward_metadata_through_encoder_enabled = true
This article describes how you can work with Nimble configuration in general.

2. Add new parameter in transcoding scenario


We assume you're already familiar with Live Transcoder setup and you already know how to create a transcoding scenario where you need the metadata to pass. You can take a look at Transcoder website and a set of videos to refresh your knowledge.

To make the output stream to have a metadata from some incoming stream, you need to add icecast_metadata_source custom parameter to audio encoder settings.

As the encoder element of transcoder scenario allows receiving content and other data from any decoded stream, with additional filtering on top, you need to specify which stream is used as a source for your metadata.

Specifying exact name

Take a look at an example of encoder setting.


Here you see original content blue decoding element with application name "live" and stream name "origin". For encoder output element you see new app and stream names and also additional "icecast_metadata_source" parameter with "live/origin" value which indicates the exact original stream.

Specifying wildcard stream name

Live Transcoder allows using wildcard stream name for the convenience of setup. Take a look at this example.


Here you can see decoder element has "live" app name and "*" as a stream name. This means decoder has no stream name specified which allows using whatever incoming stream name you have. If you look at encoder settings, you can see "{STREAM}_output" as a stream name, where {STREAM} is a placeholder for any input stream. So in the example above if your input is "live/radio", your output will be "live_radio/radio_output".

This wildcard approach is also used for "icecast_metadata_source" parameter. In our example you see "live/{STREAM}" as a value. This means that if your input source is "live/radio", then "live/radio" will be used as a source of metadata.

You can also simplify the setup process further. If your decoder app name and encoder app name are the same, you can skip the app name in parameter value and keep only {STREAM} as shown below.


In this case the application name is "inherited" from the encoder application ("live" in this case) which is equal to source decoder app name.

3. Apply new setting


Metadata passthrough cannot be applied on-the-fly to a transcoding scenario unlike other parameters. In order to make it work you need to save your scenario and then perform either of these steps:

  • Re-start the input stream
  • Or pause/resume the scenario. Go to scenarios list, click Pause icon, wait for the pause to sync with the transcoder, click on resume icon to start it again.


Once you do any of those 2 options, the metadata will become available in your output.


Let us know if you have any suggestions or questions about our Icecast feature set, we're opened for discussions.

Related documentation


June 30, 2019

2019 Q2 summary

Our team has been working on improvements through Q2 of 2019 so let's see what we've accomplished.

Qosifire

Last quarter we've introduced Qosifire live streaming monitoring service. It allows tracking availability and consistency of HLS, RTMP and Icecast live streams. The HLS support was added this quarter, take a look at this page for more details and also watch this video on our channel showing this feature in action. We've also added debugging capabilities for HLS - you can track DTS/PTS timestamps and see their dynamics real-time. Read this article and watch this video for more details.

If you still haven't tried using Qosifire, read why Qosifire might be useful for you and how you can get started with Qosifire, the step-by-step guide to using our quality monitoring control.


Products snapshots

We've added a couple of new pages in our gallery of Softvelum products snapshots which show how you can use our products for building your streaming infrastructure.

Nimble Streamer and more


Nimble Advertizer, our server side ads insertion framework, now has SCTE-35 markers support. So now ads insertion time point can by defined by absolute and relative time as well as SCTE-35 markers.
Also, Nimble Streamer transmuxing engine now supports passthrough of SCTE-35 markers during live streaming.

The Advertizer now also allows using AAC and MP3 containers for advertisement files during audio-only streaming. Take a look at Advertizer tech spec for more details.

We have some updates for SRT users of Nimble Streamer:
  • SRT packet loss for Sender in Listener mode has been fixed. Read this article for more details and upgrade your SRT package.
  • SRT sender "maxbw" parameter is highly useful for preventing from excessive bandwidth usage during lost packets re-transmission. We recommend using it for all streams on sender side. Read this article for more information.
  • SRT "latency" parameters is also very important for re-transmission control and it should be used with "maxbw". Read this article to find out more.

If SRT technology is part of your streaming infrastructure, please read those articles to be up-to-date with latest improvements.

Nimble Streamer now supports RTMP republishing into Limelight Networks, Inc. Realtime Streaming service, take a look at Realtime Streaming Guide for setup details.

We've also improved RTMP to support HEVC for Nimble Streamer and Larix Broadcaster. This is an experimental non-standard feature available in limited number of players.

Starting from May 1st, Facebook deprecates the usage of RTMP and requires RTMP over SSL (RTMPS). And we've glad to confirm our Nimble Streamer and Larix Broadcaster products have full support for RTMPS.

Streaming to social media becomes more and more popular so we've made a couple of articles about that.
We have also collected all documentation for Larix applications in documentation reference page.

Another big update of Larix Broadcaster for iOS and Android and Larix Screencaster for Android is the release of adaptive bitrate (ABR). ABR (adaptive bitrate) is available in 2 modes:
  • Logarithmic descend - gracefully descend from max bitrate down step by step.
  • Ladder ascend - first cut bitrate by 2/3 and increase it back to normal as much as possible.

You can visit Larix website to find out full feature set.

Last but now least, take a look at The State of Streaming Protocols for Q2 2019 with RTMP declining and HLS going up.


We'll keep you updated on our latest features and improvements. Stay tuned for more updates and follow us at Facebook and Twitter to get latest news and updates of our products and services.

The State of Streaming Protocols - 2019 Q2

Softvelum team continues analyzing the state of streaming protocols. It's based on stats from WMSPanel reporting service which handles data from Wowza Streaming Engine and Nimble Streamer servers - there were 4000+ servers on average this quarter. WMSPanel collected data about more than 14 billion views. Total view time for our server products is 2 billion hours this quarter, or 21+ million view hours per day.

Let's take a look at the chart and numbers of this quarter.

You can see HLS share has increased to 78% with RTMP going down to 7%. People are moving towards de-facto standard of delivery, and they are also shifting from RTMP due to its future decline.

The State of Streaming Protocols - Q2 2019

You may compare that to the picture of Q1 streaming protocols landscape:

The State of Streaming Protocols - Q1 2019 

We'll keep analyzing protocols to see the dynamics. Check our updates at Facebook and Twitter.

If you'd like to use these stats, please refer to this article by original name and URL.

June 21, 2019

Efficient usage of SRT latency and maxbw parameters

We continue educating streaming people on SRT protocol usage. It's a streaming protocol which adapts to the network conditions, helps compensate for jitter and other fluctuations with error recovery mechanism to minimize the packet loss. This leads to the lost packets re-transmission, which increases the bandwidth usage between sender and receiver.

We'll take a look at "latency" parameter which is tightly related to the re-transmission process in general.

The "latency" parameter specifies the delay which is used if the packet reached the destination quickly (and therefore it's way ahead of "time to play"). But when the packet was lost, this gives it an extra time to recover the packet before its "time to play" comes. Original packet delivery takes some round-trip time (RTT), so it will take another RTT to send the correction. And if some issues happen again on its way to receiver, the sender will re-transmit it again and again until it's correctly delivered, spending time during this process.

So too small value of "latency" may cause the denial of re-transmission. Let's suppose you have some RTT from sender to receiver equal 200ms, and your "latency" is set to 300ms. Obviously, the receiver won't be able to get any re-transmission in case of first transmission because the latency "window" will close.

The SRT community recommends setting "latency" as follows:

  • Your default value should be 4 times the RTT of the link. E.g. if you have 200ms RTT, the "latency" parameters should not be less than 800ms.
  • If you'd like to make low latency optimization on good quality networks, this value shouldn't be set less than 2.5 times the RTT.
  • Under any conditions you should never set it lower than default 120ms.
The "latency" value can be set on any side of transmission:
  • sender;
  • receiver;
  • both sides.
The effective latency will be the maximum value of both sides, so if you don't set it on sender (so it'll have default 120ms) and 800ms on receiver, the active value would be 800ms.

We've previously shown how you can control the maximum bandwidth available for transmission over SRT using "maxbw" parameter. As you can see, you need to be aware not only about the bandwidth on your sender, but also latency settings.

So we highly encourage you setting both "latency" and "maxbw" parameters during SRT setup. Otherwise you will face one of these issues:
  • When you set "maxbw" to cover all network problems, the latency can be too low to tolerate the losses.
  • When you set proper "latency" without "maxbw", it will cause exhaustion of bandwidth.

Both configuration options are available for SRT setup in Nimble Streamer. Please refer to SRT setup article to get familiar with the general setup process. Once you complete all required steps, use custom parameter fields to define appropriate entries as shown below.



The "maxbw" is defined in bytes per second, NOT bits per second. So if you'd like to set maximum bandwidth to 2Mbps, you'll have to specify 250000 as your designated value. This is an SRT-specific approach to value definition. The "latency" is defined in milliseconds.

Larix Broadcaster mobile app allows streaming via SRT with defined "maxbw" and "latency" as well.


If you have any questions regarding SRT setup and usage, please feel free to contact our helpdesk so we could advise.

Related documentation


Nimble Streamer SRT feature set, SRT setup in Nimble StreamerHaivision blog: Reliable Low Latency Delivery with SRT+SLDP

June 13, 2019

SCTE-53 markers in Nimble Advertizer

Nimble Advertizer is a server-side ads insertion framework for Nimble Streamer. Its business logic may be defined by both a dynamic handler and a pre-defined config, you can find full tech specification here.

Ads insertion time points within a live stream can be set in 3 ways:
  1. Specify the exact moment of time in GMT.
  2. Time spots relative to the beginning of the viewing session.
  3. According to SCTE-35 markers from the original stream.
The SCTE-35 markers are part of original streams delivered via MPEG-TS and HLS streams which Nimble Streamer is able to accept for input.

Here's a brief summary of how Nimble Streamer handles the markers for ads insertion:

  1. You create a handler app which will tell Nimble how to operate ads. This may also be plain JSON file with static pre-defined setting. Advertizer spec described handler in more details.
  2. Nimble Streamer processes incoming MPEG-TS and HLS streams with SCTE-35 markers to get the original content.
  3. Nimble Advertizer calls your handler app or static config and gets response with ads scenarios.
  4. Advertizer gets files with ads content to process them via Nimble Streamer according to ads scenarios logic defined by handler response.
  5. If the handler response defines that current stream needs to insert ads according to SCTE-35 markers (by using "time-sync":"scte35" field), Nimble inserts the ads into original media right at the time points specified in SCTE-35 marker.
  6. End user connects to Nimble and watches media stream containing original content mixed with advertisements.

You can find example of handler response with marker-based insertion as well as other samples in Advertizer github repo.

You can read all information regarding Advertizer usage on its website.

If you find any issues with SCTE-35 ads insertion, please file us a support ticket so we could help you.

Related documentation


Nimble AdvertizerNimble Streamer live streaming scenarios,



June 11, 2019

Streaming from Larix Broadcaster to YouTube Live

YouTube Live became extremely popular lately and many users of Larix Broadcaster for Android and iOS and Larix Screencaster for Android also started publishing live video there. We get questions about correct setup of Larix products so this brief instruction explains this process.

To proceed with YouTube Live you need to get familiar with service setup using this support page. When you set up YouTube Live transmission, you get these settings:

Primary Server URL: rtmp://a.rtmp.youtube.com/live2
Stream Name: username.1234-5678-abcd-efgh
Larix uses single line for target URL setup so just need to use URL+Key as your connection URL, like this one:
rtmp://a.rtmp.youtube.com/live2/username.1234-5678-abcd-efgh

From Larix UI perspective the setup is performed with the following steps. We assume you've installed Larix using links from this web page.

Open the app and click on gear icon to see the main menu. Go to Connections then click on New connection menu.



It will open a new connection dialog. Enter any descriptive name for a new connection and then insert your connection URL.


Once you save changes, a new connection will appear in connections list. To use this new connection for further streaming, just click on its respective checkbox.


Once you get on the main video preview screen, you can tap on big red circle to start streaming.

This setup is applicable to Larix Broadcaster for both Android and iOS, as well as to Larix Screencaster for Android.

Visit our documentation reference page for more setup information.

If you have questions regarding Larix Broadcaster or other mobile products, please contact us via our helpdesk.

Related documentation


Softvelum mobile solutionsLarix documentation reference pagePublish from Nimble Streamer to YouTube Live,


Streaming from Larix Broadcaster to Facebook Live

Facebook Live became extremely popular lately and many users of Larix Broadcaster for Android and iOS and Larix Screencaster for Android also started publishing live to Facebook. We get questions about correct setup of Larix products so this brief instruction explains this process.

When you set up Facebook Live transmission on Facebook setup page, you get these settings:

URL: rtmps://live-api-s.facebook.com:443/rtmp/
Key: 1310310017654321?s_bl=0&s_sw=0&s_vt=api-s&a=Abw47R4F21234567
Larix uses single line for target URL setup so just need to use URL+Key as your connection URL, like this one:
rtmps://live-api-s.facebook.com:443/rtmp/1310310017654321?s_bl=0&s_sw=0&s_vt=api-s&a=Abw47R4F21234567

Notice rtmps:// prefix and port 443 - Facebook now requires to use RTMP over SSL for live streaming. Our products have full support for it.

From Larix UI perspective the setup is performed with the following steps. We assume you've installed Larix using links from this web page.

Open the app and click on gear icon to see the main menu. Go to Connections then click on New connection menu.



It will open a new connection dialog. Enter any descriptive name for a new connection and then insert your connection URL.


Once you save changes, a new connection will appear in connections list. To use this new connection for further streaming, just click on its respective checkbox.


Once you get on the main video preview screen, you can tap on big red circle to start streaming.

This setup is applicable to Larix Broadcaster for both Android and iOS, as well as to Larix Screencaster for Android.

Visit our documentation reference page for more Larix setup information.

If you have questions regarding Larix Broadcaster or other mobile products, please contact us via our helpdesk.

Related documentation


Softvelum mobile solutionsLarix documentation reference pagePublish from Nimble Streamer to Facebook Live,

June 3, 2019

SRT sender max bandwidth

SRT is a streaming protocol which adapts to the network conditions, helps compensate for jitter, bandwidth fluctuations and has error recovery mechanism to minimize the packet loss.

These excellent features lead to the lost packets re-transmission, which increases the bandwidth between sender and receiver. This is why if the network conditions are bad enough, the re-sent packets may consume all available throughput.

As you cannot control the network environment completely, you should set up the maximum bandwidth available for transmission over SRT for every SRT sender. Even if your network is fine now, it's a good practice to prevent any fluctuations in the future.

This maximum bandwidth limitation is set up using "maxbw" parameter for SRT streaming.
It needs to be set on sender side.

We recommend having maxbw value twice as much as your stream bandwidth, e.g. if you send 1Mbps, your maxbw should be 2Mbps.

We also strongly encourage you to set both "maxbw" and "latency" parameters for streaming via SRT. Please read this article to learn more about this parameter.

Proper configuration option is also available for SRT setup in Nimble Streamer. First, please refer to SRT setup article to get familiar with the general setup process. Once you complete all required steps, use custom parameter fields to define appropriate entry as shown on the figure below.



Please notice that maxbw is defined in bytes per second, NOT bits per second. So if you'd like to set maximum bandwidth to 1 Mbps, you'll have to specify 125000 as your designated value. This is an SRT-specific approach to value definition.


If you have any questions regarding SRT setup and usage, please feel free to contact our helpdesk so we could advise.

Related documentation


Nimble Streamer SRT feature setHaivision blog: Reliable Low Latency Delivery with SRT+SLDP

SRT packet loss is fixed

Softvelum team is an active participant of SRT community and we follow up with all updates as well as contribute to the code base.

Recently the SRT library was updated with a commit which fixes packet loss for the case when SRT Sender is working in Listen mode.

This fix is on the master branch already, and it's on its way to the next SRT package release. Nimble Streamer team made changes to SRT Nimble Streamer package so our customers could make proper update and fix the problem for their streaming scenarios.

So if you use SRT Sender in Listen mode, we highly recommend you to upgrade SRT package.
This will fix the aforementioned problem and will improve your streaming experience.

If you have any questions, please feel free to contact our helpdesk so we could advise.

Related documentation


Nimble Streamer SRT feature set, SRT streaming setup,

May 20, 2019

Support for HEVC over RTMP in Softvelum products

RTMP protocol is widely used for origin delivery, e.g. delivery from encoders to edge servers or delivery between origins and edges. The content codecs defined by the spec are H.264 and VP6.

However the recent increase of H.265/HEVC usage inspired third parties for making changes in RTMP so it could carry this new codec. E.g. ffmpeg has forks with proper support.




Thus Softvelum team has added HEVC support for RTMP into our products:

  • Nimble Streamer supports HEVC via RTMP/RTMPS when it's published into Nimble or pulled by it, in order to transmux into HLS, MPEG-DASH and RTSP;
  • Larix Broadcaster allows publishing via RTMP/RTMPS from mobile devices with Android and iOS.

So if you need to use RTMP instead of RTSPSRT or MPEG-TS for HEVC, you can try this new approach.

Please notice that RTMP support for HEVC is a non-standard experimental feature. In order to use it properly, both sender and receiver sides need to support it.

In case of any questions or issues please contact our helpdesk.


Related documentation


Nimble Streamer, Nimble Streamer supported codecsRTMP support in Nimble Streamer