January 22, 2014

Changing user agent for Nimble Streamer

One of use cases of Nimble Streamer is re-streaming of HLS, SmoothStreaming and progressive download. This means that Nimble is working as a client for other origin servers. So it's sending User-Agent header to identify itself. Some companies may want to change this identification for security reasons.

Now you may change Nimble Streamer user agent name for accessing origin servers.

General settings are stored in /etc/nimble/nimble.conf. Just add this string in the config file:
user_agent = User-Agent-Name
You may also control server by changing other configuration parameters. Once you make a change please re-start Nimble by running
sudo service nimble restart
Once the service is re-started, Nimble will start requests to origin services via the user agent specified in the config.

January 21, 2014

Adding private checkpoints for Dispersa

Dispersa streams monitoring service uses a distributed checkpoints network for checking customers' media. This covers a majority of use cases for typical streaming media business.

However, there are cases when our external service cannot check your streams.

Internal streaming infrastructure


You may have a streaming server inside of your enterprise network. A good case for making broadcasts or build your company knowledge base with videos and screencasts.

Typically company networks have limited access to the external web so media server is not accessible by our checkpoints.

Limited geographical access


Some streaming media may have distribution limitations due to copyright and licensing terms. So you may use geo-location restriction and you may need to check your streams from within your geographical region. The same applies if you limit your streams to preferred telecom operators.

We extend our checkpoints geography all the time but there may still be points which cannot be reached from our locations.

Make your private checkpoint to cover these cases


Any streaming server which is inaccessible from all of our distributes checkpoints network, needs some other approach to be checked over. We need a checkpoint within your "secure perimeter" which would be able to make periodical check overs. It's possible with help of Nimble Streamer light-weight media server.

You need to follow these 2 simple steps.

1. Install Nimble Streamer using some Linux server - either virtual or dedicated. The installation process is straight-forward so it won't take much time. Nimble instance will appear in your WMSPanel account.

2. Go to Servers page and click on Edit link. In our example we installed "Nimble edge 1" server.

Nimble server setup for Dispersa checkpoint.

Check "Dispersa private checkpoint" check box, then enter check interval and save changes. Notice that interval value must be bigger than 30 seconds.


3. Follow streams monitoring set up instruction and select one or more existing Nimble instances when setting up streams to monitor. Here you can see "Nimble edge 1" as the only available checkpoint. Just check required checkpoints and click on Save.


That's it. Nimble instances will start their periodical check over. You will see the instance name in the list of checkpoints.

Checkpoint monitoring data is saved in streams monitoring history.

You can also take a look at our screencast describing the service:



So now you can use Nimble Streamer for building your own monitoring and disaster prevention system. Contact us if you have some use cases which you'd like to cover.

Q: My streaming network is protected with WMSPanel hotlinking protection. Can Dispersa work here?

Yes, just set up allow list for Dispersa checkpoints IP range.


P.S. Notice that as the Nimble Streamer is properly set up, you may go further and use it for HLS re-streaming or for HLS VOD streaming.

Related documentation


Dispersa stream monitoring, Set up streams availability monitoringNimble HTTP StreamerNimble Streamer overview videoWMSPanel: cloud reporting and control panelStreams monitoring historyDispersa alerts push API

January 17, 2014

How to set up streams availability monitoring

You must have already tried our free stream availability checker. based on WMSPanel and Nimble Streamer. It makes single check over via all existing checkpoints that are geographically distributed accross the globe.

Now, you want to secure your streming and be notified about any outages whenever they happen. That's what we've made the streams availability monitoring as part of our WMSPanel cloud control service.

Here's how it works for you:

  1. You sign up in WMSPanel.
  2. You set up the email where you want to get alerts to.
  3. You specify what streams need to be checked from which of the checkpoints.
  4. Dispersa monitoring will check each of the streams each 5 minutes.
  5. If any of the checkpoints fail to establish streaming connection, it will send alert.
Take a look at our screencast describing the set up process:




Let's see this step-by-step.

Here's the streams monitoring dashboard.

Streams monitoring dashboard.

You click on "Offline notifications set up" and see this page where you can enter emails and test them. It's also used for server downtime notifications feature.

Email set up.

Then click on "Add stream to monitor" in the dashboard to see the following dialog.

Setting up stream to monitor
Here you enter stream name and select checkpoints which will test your stream for availability. You may also specify a private checkpoint to be used in protected or closed network environments.

In addition you may specify whether Dispersa will notify you on any checkpoint's failure or only when all of them fail to check the stream.

Now save changes. You will see the stream added into the table. Right after that Dispersa starts the check over. 

Checking new added stream

The result will be show in the table. You may click on the status to see the detailed report.



Streams check over details.

That's it. Enter the streams you want to check and subscribe for our services if you'd like to check them after the trial is over.

Each stream has its history of check-overs in streams monitoring history. If you'd like to have same statistics within your monitoring or analytic tools, use Dispersa alerts push API to get notified about streams going offline and online.

If you want to control Dispersa streams dynamically, check Dispersa monitoring API.

Q: My streaming network is protected with WMSPanel hotlinking protection. Can Dispersa work here?

Yes, just set up allow list for Dispersa checkpoints IP range.



We plan improving this feature set going forward so please let us know of any suggestions or questions.

Related documentation


Dispersa stream monitoring, Setting up private checkpointsNimble StreamerWMSPanel: cloud reporting and control panelStreams monitoring history, Dispersa alerts push API


January 5, 2014

Improving HLS startup time and latency with Nimble Streamer

One of the issues for HLS streaming is a latency between initial playlist request and start up of playback. Mostly the latency value depends on the chunk size and throughput of viewer's network. Knowing that default chunk size is 10 seconds, no wonder most of players make significant start time for HLS stream. Nimble Streamer now solves this problem for VOD streams by reducing size of start up chunks. Let's see how it works.

Nimble Streamer is capable of re-packaging of MP4 into HLS, i.e. transmuxing MP4 into VOD-mode HLS stream. What we can do on server side is to change chunk size.
  • First chunk is made 3 seconds long. So player gets this chunk and starts playing it immediately.
  • Second chunk is 4 seconds long. Thus while the first chunk is being played, second one is downloaded pretty quickly.
  • Other chunks are 6 seconds long. Now streaming goes on so there's no need to break the stream into small chunks.
This improves HLS VOD playback experience allowing concentrating on further content delivery. Since Nimble Streamer can be used re-streaming HLS, it can be used as a foundation for robust and scalable HLS content delivery.

Subscribe to our blog and social networks to get further updates on Nimble Streamer improvements.

Related documentation


Nimble HTTP StreamerNimble Streamer overview videoCalculating HLS statisticsMP4 transmuxing to HLS VOD streamingStreaming VOD with Nimble StreamerHLS re-streaming set upNimble Streamer HTTP hotlinking protectionWMSPanel Slideshare

HLS statistics for Nimble Streamer

HTTP Live Streaming is a pretty simple transport protocol. However, making correct calculations of statistics may become a hard task. The complete HLS stream consist of a playlist and a group of chunks which deliver the content. So what are the problems and how does Nimble Streamer solve them along with WMSPanel?

The viewer's player opens a playlist. That's not a stream yet, as the player needs to read chunks list to proceed. So it's not counted.

Next, the player can then open several chunks connections in parallel (to improve user experience by avoid buffering) as well as open them consequently. Since Nimble Streamer handles its own sessions, each chunk request get the same session ID hence the ease of handling.

Another problem comes from browser- it opens the link to determine that it's an HLS stream. Then it passes this link to a player which requests it again to start the chunks download. Hence the double request for the playlist. Nimble handles that and does not count playlist requests as a view.

WMSPanel HLS real-time stats in Android browser.
The described case works well for new generated playlist in case of MP4 transmuxing to VOD, MPEG-TS UDP to ABR HLS conversion or in case of edge HLS re-streaming.

If you'd like to collect your own data set based on streaming stats, take a look at Pay-per-view feature set for Nimble Streamer which allows receiving realtime information to your own handler about each and every connection to your media server.

Read more about WMSPanel streaming reporting.

Related documentation


Nimble HTTP StreamerNimble Streamer overview videoTransmuxing RTMP to ABR HLSMPEG-TS UDP conversion to ABR HLS with NimbleMP4 transmuxing to HLS VOD streamingHLS re-streaming set upImproving HLS startup time and latencyWMSPanel Slideshare,

January 3, 2014

Setting Nimble Streamer caching via GUI

Nimble Streamer can be run all by itself and its behavior may be controlled via configs. However, WMSPanel provides controlling and reporting capabilities for Nimble to make the process easier.

As described earlier, Nimble has rich caching feature set: disk cache for VOD streaming and RAM cache for live re-streaming.

Now WMSPanel allows settings up cache size within its server control GUI. All you need is to go to Servers menu, select a server to control and click on Edit to see the form shown below.

Editing Nimble Streamer instance details.

As you see here you may also set up logging level to track Nimble activity. Logs can be found at /var/log/nimble/ directory.

Other configuration options will be added to WMSPanel GUI for Nimble Streamer soon.

Please also learn more about latest VOD cache control features here.

BTW, the sample form which you see above shows one of exiting Nimble Streamer servers used for two use cases:

It also has RAM and CPU level alert set up to send notifications after reaching 20% threshold.

Related documentation


Nimble HTTP StreamerVOD re-streaming cache controlNimble Streamer overview videoMP4 transmuxing to HLS VOD streamingStreaming VOD with Nimble StreamerLoad balancing and failover with Nimble StreamerNimble configs explainedRAM caching for effective re-streamingNimble disk cache usageHTTP pseudo-streaming progressive downloadWMSPanel Slideshare