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.
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 "demo nimble" server.
Nimble server setup for Dispersa checkpoint
Check "Dispersa private checkpoint" check box, then enter check interval and save changes.
"Dispersa check interval" defines time period for check-overs. This value must be bigger than 30 seconds.
When Dispersa cannot reach the stream, it waits for the next check-over and if the stream is still not available, it initiates the offline notification for the customer.
If you want Dispersa to run notification immediately after stream failure, please check "Dispersa instant notification" checkbox.
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 "demo nimble" 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.
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?
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.
You set up the email where you want to get alerts to.
You specify what streams need to be checked from which of the checkpoints.
Dispersa monitoring will check each of the streams each 5 minutes.
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.
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.
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.
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.
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.
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:
