July 31, 2019

Constant bitrate and mux rate in UDP streaming

Nimble Streamer has wide feature set for MPEG2TS streaming. This includes full UDP support to allow Nimble Streamer receive and send content via that protocol.

Streaming without bitrate setup

When you stream from Nimble Streamer via UDP, a variable bitrate is used for output by default. You can find all details of UDP streaming setup in this article.

However, in some cases of using DVB/ATSC and other hardware, a lot of ETR101290, CC and PCR errors appear on a regular basis making it hard to use it.

Take a look at this Wireshark session which logged an output of UDP stream.

You can see large spikes which cause problematic behavior on sensitive hardware.

Streaming with mux rate

The first step to mitigate this is to specify exact mux rate for outgoing stream to set the upper limit. To specify mux rate parameters, click on "Mux rate" checkbox in UDP settings as shown below.

Here you can define Mux rate field value with the bitrate you'd like to have. Notice that it should be 20% to 30% bigger than the maximum bandwidth of your original content. Other mux rate tuning fields like Mux delay and Max mux delay can be specified as well.

Now you can re-start your stream to see how it affected the output. First we looked at the stream using Wireshark with 1 second interval.

It looks much better, however if we select 100ms interval, the picture is much less smooth.

Even though an average bitrate is near the target value, you see the spikes which will still affect many types of hardware.

Streaming with constant bitrate

To keep the bitrate on the same level, Nimble Streamer allows setting constant bitrate (CBR). Nimble calculates the exact time interval between packets using MPEG-TS packet size and required bitrate, then sends those packets out strictly at designated time slots. With CBR technique, the packets are kept and processed via the CBR buffer.

CBR behavior is enabled by Max CBR buffer field. It defines the maximum total duration of packets in CBR buffer for further processing. If the incoming data overflows the Max CBR buffer, the stream will be reset.

When the stream has been started and the incoming data starts arriving, Nimble Streamer stores the packets into CBR buffer. Start CBR buffer parameter defines the duration of packets which Nimble collects before starting to send them out.
E.g. if you set this to 1000ms and start the stream, Nimble will keep getting data and putting packets into buffer, and after the total duration of packets in the buffer reaches 1000ms, Nimble will start sending the packets with calculated intervals.

As long as data keeps arriving, the packets will be placed in the buffer for further sending.

If the CBR buffer runs out of packets (due to some incoming stream problems), Nimble Streamer will then wait for incoming data to fill the CBR buffer for the duration set in Start CBR buffer before starting to send the data out again. So Start CBR buffer value is used in 2 cases - when the stream has just been started and when the stream has had some problems.

Notice that the bigger Start CBR buffer you set, the bigger the output latency you will have. If you set it to some low value or just keep it blank, then you may face some glitches in Nimble output, just because it will depend on your incoming stream's conditions.

The numbers may differ according to your input streams. If your source is an RTMP stream and your network conditions are good, you can use 1000ms Start CBR buffer and 10000ms in Max CBR buffer.

If you use HLS as an input, those numbers need to be larger as it's a chunk-based protocol. E.g. for a stream with standard 10-seconds chunks the start buffer needs to be 20000 and max buffer can be 60000.

With these settings, once we start the input RTMP stream, the 100ms chart in Wireshark looks like this.

Some rare spikes still present once in a while due to system network deviations but the line is generally flat on the target bitrate.

Notice that CBR works only when Nimble Streamer is installed on Linux or MacOS because Windows doesn't allow working with precise intervals required for this technique without using complex and risky methods.

PCR metrics

Overall, according to StreamGuru, when it comes to UDP streaming, Nimble Streamer has PCR accuracy of 100%. While hardware receivers accept up to 500ns PCR drift, Nimble Streamer produces PCR with 0ns drift. Also, PCR interval is <20 ms while 40ms is acceptable by most hardware.

If you have any questions about working with UDP streaming via Nimble Streamer, please contact us.

Related documentation

July 28, 2019

Handling session IP change in Nimble Streamer

Nimble Streamer uses sessions to track users' stats as it's important to see how the content is consumed. It's used in every end-user connection unless you use HTTP origin feature to remove the session identifier.

Every session is based on user IP to be able to distinct them from one another. Normally if a session starts with some IP, it keeps using that IP until the connection is closed. If the original connection IP changes, Nimble Streamer will close the connection because IP change most probably means that someone else uses your session ID which is not good from security standpoint. The viewers with closed connection will get response code 403.

However in some cases the IP change doesn't mean anything bad. For example, if your Android users use Lite mode (also known as Data Saver), Google will use its own proxy servers to accelerate the data usage. Also, your users may use other trusted proxies for their own legit purposes.

For cases like these you may use a few features of Nimble Streamer.

Disable IP check

First of all you may disable session IP check. This can be done using this parameter
restrict_session_ip = false
in nimble.conf. Please read configuration reference page for details on parameters' setup and usage.

Once you disable it, your streams' direct links may be used by several viewers so you should use this approach only in case your viewers use trusted proxy servers.

Tune hotlink protection

If you use hotlink protection from WMSAuth paywall feature set and your viewers use proxies as described above, they will get error 403 and you'll find "cannot find hash match" in Nimble logs. That will happen even if you disable session IP check.

So the next thing you should do after disabling restrict_session_ip, is to use different headers for obtaining end-user IP in WMSAuth code for your web page. This can be X_FORWARDED_FOR header or others, depending on your server and proxy software. Read this article regarding proxy usage to learn more about headers' usage.

Let us know if you experience any issues with the described features.

Related documentation

Nimble Streamer configuration referenceWMSAuth paywall, Using paywall with proxy servers,

July 25, 2019

Streaming Media European Readers' Choice Awards 2019

Streaming Media Europe magazine has started a vote for European Readers' Choice Awards 2019.
At the moment the voting is closed, if you are a voter, you receive an email asking them to to confirm the votes - please confirm it in order for it to be counted!

Please also have a couple of minutes to participate in Readers' Choice Awards 2019!

July 24, 2019

RTMP re-publishing control API in Nimble Streamer

Nimble Steamer has its own native status and control API which can be used for interacting directly with server instance rather than using WMSPanel control API. This native API can be convenient in case some  action needs to be applied without any delay.

There's a wide RTMP feature set in Nimble Streamer which covers the vast majority of aspects for live streaming. Re-publishing use case if very popular for building streaming infrastructure with origins and edges so our customers have been asking us for native API methods to work with it.

Now you can use new methods to do he following:

  • Get list of re-publishing rules;
  • Get details of selected re-publishing rule;
  • Create new rule;
  • Delete existing rule;
  • Get status of all current re-publishing rules.
You can visit native API reference page to find all details about these methods.

Notice that re-publishing setting defined by "create" and "delete" API calls are not persistent and they are reset after Nimble Streamer re-load. If you'd like to keep them, you should use WMSPanel control API.

Related documentation

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
Then re-start Nimble Streamer instance. This reference page describes how you can work with Nimble configuration in general.

2. Adjusting transcoding scenario

You can use 2 different options to enable metadata forwarding, each having its specific use case.

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.

2.a Add new parameter

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.

This approach allows taking metadata from any input live stream available in Nimble Streamer.

2.b Forwarding of input metadata

You can forward whatever metadata is available in the processed stream. Just check the "Forward Icecast metadata" boxes in both decoder and encoder elements.


This approach allows using forwarding as part of failover and hotswap feature set. As a downside, this case doesn't "remember" the use metadata which was present before the switch to this scenario or stream.

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.

RTMP Icecast metadata

RTMP protocol is able to carry Icecast metadata and Nimble Streamer can put such RTMP metadata into Icecast streams. However, if you'd like to pass that metadata through Live Transcoder, you need to follow these instructions for proper setup.

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

Related documentation