Wowza CPU and RAM usage alert

Wowza customers are always looking for different ways to improve server performance. So they need to be sure that current server set up and tuning are doing fine and do not exceed CPU and RAM limits. So they need a way to be alerted about CPU and RAM status of each Wowza server. WMSPanel has been providing a real-time monitoring of Wowza CPU and RAM, so any moment a system admin may go to server details page and check what's going on.

Now we've made next step and WMSPanel now allows setting up a threshold for CPU and RAM consumption level and notify designated admins emails about resources overrun.

The set up consists of two steps.

Define limits

You need to define the thresholds for alerting an administrator. Click on Servers menu to go to servers list and click on Edit for designated server.

Setting up CPU and RAM limits for alerting Wowza admins.

Here you can select CPU and RAM level from the drop down list. Once the limit is reached, an email notification is launched to the emails which are set up on the second step. These alerts will be sent once an hour in case the consumption is still over the limit.

Set up notifications

In order to receive alerts you need to specify a list of emails that need to be notified. Go to Control / Offline notifications set up menu to see the setup page.

Set up alerts and notifications email addresses.

Here you will add or remove the email addresses and will be able to test them.

That's it. If any of the limits is overrun, the email is sent. It's done once an hour until you fix the problem or increase a threshold.

Contact us if you need any other Wowza monitoring capabilities in addition to CPU/RAM limits and Dispersa streams monitoring feature set.

Related documentation

Wowza multiple servers management, Monitoring Wowza CPU and RAM, Dispersa streams monitoring, Wowza server downtime notification, Server tasks remote management via web UI

Data slices time zone setup

Data slice is the concept which we've been using for years. A data slice collects user data and calculates metrics separately for designated applications or streams. Along with white label custom branding capabilities this allows showing streaming metrics to any number of end users for billing purposes or for improving streaming user experience.

Major metrics set of each data slices are daily-granulated stats which include connections, traffic, bandwidth, time and duration, geo-location, devices and players stats. The majority of this data may be exported via our API.

Commonly these daily stats are split by days using UTC, or GMT+0, time zone. So if any streaming company from U.S., Canada, Brazil or any other American country would make some evening event, it would be split by 2 days which is very inconvenient from user point of view.

Our customers have been asking us to improve data slices and include time zone setting to split data by days more accurately. So now this option is available.

Let's assume we have http://origin.ultimatemediastreaming.com/live/stream/playlist.m3u8 stream and we want a data slice for it calculating stats using GMT-06:00 which is a Central time zone in U.S.

Select Control / Data slices menu or click on Manage link in Data slices sub-menu. You will see data slices management page.

Data slices list.

Click on Create streamed data slice to see the following dialog.

New data slice dialog.

Enter slice name and optional description. Then select time zone from the drop down list.

Data slice details.

You may also uncheck "Show streams real-time and retrospective reports" checkbox to have your new slice be a lite slice.

You will then be redirected to a new slice details where you can define rule for data collection as shown below. This rule covers app name and stream name.

Entering data slice stream details.

Now when you create a slice, the data will start to be collected from the moment of creation. It will be collected in designated tie zone.

You may convert existing slice' time by going to slice detail from slices management page and clicking on Edit link. In this case current day data may be affected by mixed numbers so we recommend making conversion on some non-peak days.

Read more about slice-related features in on the dedicated Slices & Branding page.

Read more about WMSPanel streaming reporting.

Contact us if you need any other updates for data slices concept. We have new improvements coming up for data slices so feel free to follow us on Facebook, Twitter or Google+

Related documentation

Daily statistics, High precision reporting, Data slices for statistics, Streamed slices for Wowza, Billing customers using daily stats, Screencast for daily statistics, Screencast for data slices and white label, Statistics import API

HDS re-streaming support

Nimble Streamer has been handling re-streaming of the most popular HTTP-based protocols since the early days. These protocols were HLS, progressive download and then SmoothStreaming.

Now we introduce re-streaming for HTTP Dynamic Streaming, or HDS. It was created by Adobe for HTTP delivery of adaptive streaming. Nimble Streamer handles it using the same efficient caching system as we use for HLS and SMOOTH.

The main advantages of using Nimble as an edge server for HDS re-streaming are:

• Load balancing of big amounts of incoming connections via light-weight edges.
• Hot-linking protection of HDS streams.
• Variety of statistics reports available for Nimble Streamer.
• Low cost of ownership as Nimble is a freeware.

With these major benefits all you need to start is to sign up to WMSPanel, install Nimble Streamer and specify which HDS requests must be re-streamed to origin and properly cached.

Follow these easy steps.

1. Install Nimble Streamer on your Linux server using this procedure.

2. Go to Nimble Streamer / Edit Nimble Routes menu to open routes page

Here you will see the list of existing routes or just an empty list. In our example you see a route for VOD streaming which is used in our Nimble Streamer demo page.

Nimble Streamer routes list.

3. Click on Add re-streaming route to see the following dialog.

HLS, SmoothStre and HDS re-streaming set up dialog.

So now you need to define which requests are going to be handled and where will Nimble take the original stream from. Let assume your origin HDS stream is located at this URL:

http://yourdomain.com:1935/live/stream/manifest.f4m

We have 4 servers in our pool but we want just one of them to handle the requests. By default Nimble is listening to port 8081 on all available interfaces. You can change it using config file but for this example we'll use default settings (all IPs and ports) and will have Nimble get all incoming requests for /live/* streams and re-stream them form origin location.

Check the following picture to see proper settings for it.

Re-streaming interfaces and paths for HDS re-streaming example.

Now you need to specify which servers will be handling this request. You may apply the setting to any Nimble server available in your account. We will select just one of them.

Selecting Nimble Streamer instance to handle HDS re-streaming.

Now when you click on OK the route is applied to designated Nimble instance. You may access your HDS stream using the following URL:

http://ny2.video.wmspanel.com:8081/live/stream/manifest.f4m

Here you see full domain name, default port and full path identical to what you see at the origin.

If you want robust and scalable re-streaming, you may want to use this how-to article explaining HLS scalable streaming to use it for HDS. The routes set up and DNS settings will be pretty much the same.

Contact our team in case you have some sophisticated streaming scenarios you'd like to cover or if you have any questions regarding Nimble Streamer set up.

Related documentation

Nimble Streamer, The Paranoid’s Guide to Internet Video Streaming, Pay-per-view for Nimble Streamer, Load balancing and failover with Nimble Streamer, Geo-location load balancing with Nimble,

Streaming Media East 2014

Streaming Media East show is over.

It was exciting to meet a lot of new people and to see people we know already. Talking to exiting and future customers, learning more about current streaming media market and its future trends - this is a perfect place to do it.

We've been posting some pictures in our Facebook account so you may see them in this WMSPanel Facebook album.

Here are just a few.

Streaming MP3 and AAC via HLS

Video-on-demand feature set is popular among Nimble Streamer customers. Initially we took MP4 format as the most popular one and made its transmuxing into HLS. So Nimble Streamer can be used as an origin for HLS streams in VOD mode.
Another use case requested by our customers is producing HLS stream from MP3 sound files into HLS in VOD mode. This transmuxing allows reducing traffic overhead for streaming audio comparing to traditional MP4 to HLS transmuxing. This is feasible because HLS allows using ID3 PRIV tag with com.apple.streaming.transportStreamTimestamp PTS time mark and produce HLS chunks with bare MPEG audio frames avoiding MPEG2TS transport overhead.
In addition to that, AAC to HLS VOD is supported.

We've made some prototyping and recently has released its support within Nimble Streamer.

So now you can stream MP3 audio transmuxed into HLS. Having your internet radio archive stored in classical MP3, you can make it available on any HLS-enabled device.

Current implementation supports MPEG 1, MPEG 2, MPEG 2.5 codecs with full set of Layer 1, Layer 2 and Layer 3.

It also supports AAC files transmuxing.

Setting up MP3 for HLS transmuxing

Once you install Nimble Streamer, you need to go to Nimble Streamer / Edit Nimble routes.

There you can click on Add VOD streaming route. There you need to enter the source directory where you store your MP3 archive and specify URL path which you will use for access.

Entering MP3 transmuxing route.

In our example it's /var/www/content/mp3/ directory and /radio/ URL path. You also need to select which servers this route is applied to.

Route is ready.

With this route, and some sample.mp3 file in your directory, your media URL may look like this:

http://ny2.video.wmspanel.com/radio/sample.mp3/playlist.m3u8

Please make sure "nimble" user have a read+execute access to /var/www/content/mp3/ directory.

You see that we've selected 3 servers to get this route for processing so you may address your requests to any of those servers. You may also set up DNS failover to make those 3 servers work as a single streaming pool to improve robustness and improve user's viewing experience.

Let us know if you'd like to cover some other use cases related to MP3 streaming.

Related documentation

Nimble HTTP Streamer, Pay-per-view for Nimble Streamer, MP4 transmuxing to HLS VOD streaming, Transmuxing RTMP to ABR HLS, Streaming VOD with Nimble Streamer, VOD re-streaming cache control, Calculating HLS statistics, HTTP pseudo-streaming progressive download, Progressive download re-streaming, Dispersa streams monitoring

WMSAuth allow list for Dispersa checkpoints

Our customers often use several key features to build their streaming infrastructure. Paywall framework is among most popular as it provides hotlinking protection, geo-location blocking and other limitation scenarios. Many of those features' users also use Dispersa periodical streams monitoring to make sure the streams are online.

If some limitation or restriction is used for customer streaming, Dispersa checkpoints may not be able to access the streams because they are distributed across several countries. You may also add private checkpoint but still it will be denied by hotlinking protection.

To have those Dispersa servers be able to monitor protected streams you may use WMSAuth allow lists. Let's say you created hotlinking protection. You need to go to WMSAuth groups page and click on Manage custom IP ranges. There you need to add IP ranges for several single servers which are used as checkpoints.

Take a look at the screenshot for details:

IP addresses for Dispersa default checkpoints.

The exact IP addresses can be found by running "nslookup video.wmspanel.com" command.

Now when IP range is created go to WMSAuth rule where you restrict unwanted visitors and add new range to allow list as shown in the screenshot below.

Adding Dispersa IP range to allow list.

Now click on Update WMSAuth rule and this will be applied to your servers.

Dispersa monitoring checkpoints will now be able to connect to your protected streams.

If you face any difficulties with this use cases, let us know about it so we could help.

Related documentation

Paywall framework for Wowza and Nimble Streamer, Streams monitoring history, Dispersa alerts push API, Wowza hotlinking protection, Hotlinking protection with stream-based signature, Geo-location streaming limitation, Dispersa periodical streams monitoring, Dispersa checkpoints