The State of Streaming Protocols - July 2014

WMSPanel is a SaaS which handles statistics of hundreds of media servers from hundreds of customers of various sizes from 59 countries around the globe. So we can feel the pulse of media streaming and have some general slice of the industry.

The most interesting metric from heterogeneous set of servers is the transmission protocol used for media delivery to viewers. So we'd like to share what picture we have for media protocols today for June and July of 2014. It is based on metrics of 970 servers running Wowza Streaming Engine (versions 2.x through 4.x), Nimble Streamer or Windows Media Services on board.

For a given time we've processed the stats about 1.4+ billion views on the servers of our clients.

The State of Streaming Protocols: June-July 2014.

More than a half - 796 millions of views, or ~56% - is handled by HTTP Live Streaming (HLS). Nowadays it's a de-facto standard to bring media to multiple devices so no wonder it has the largest share.

Realtime Messaging Protocol (RTMP) handles a quarter - 379M+, or 26% of views. It's the best protocol for real-time streaming so it's very popular.

RTSP, another real-time protocol, handled nearly 221M views with 15% share.

Other sorts of protocols like progressive download, HTTP Dynamic Streaming (HDS), Microsoft SmoothStreaming and MPEG-DASH handle the rest which is 27M+ views, or 3% share.

So this is quite an expressive snapshot so we'll keep updating our audience about the state of media protocols.


This report is brought to you by WMSPanel team.

In-depth statistics for advanced reporting

WMSPanel provides excellent reporting for media servers - this is one of the major reasons for our customer to like our services. We've been continuously improving the statistics feature set and today we'd like to announce new reporting framework.

We call it in-depth statistics reporting, or simply deep stats.

Per-stream and per-file reports

Deep stats allow collecting a set of daily statistics for each media which you stream:

• each individual stream if you're making live streaming;
• each individual file if you make video on demand.

You may enable this reporting for any slice in your account. Every stream or file has its daily statistics for the a dates' range. Maximum range is defined per data slice.

Metrics

In the report for each file or stream you may see the most important information:

• Connections total and per-protocol amount.
• Outgoing and incoming traffic amount.
• Timing and duration periods with connections amount.
• Devices and players two-dimensions reports.

Pull RTMP for ABR HLS transmuxing by Nimble Streamer

Nimble Streamer currently supports several methods of live streaming

Besides accepting published RTMP stream, Nimble can also actively take media from RTMP source, or simply "pull the RTMP stream". As an output, Nimble provides both single-bitrate and multiple-bitrate ABR HLS.

Let's see the set up process. It's easily done via WMSPanel web interface.

First you may take a look at video tutorial about RTMP setup.

It shows basic scenarios with RTMP processing.

1. Install Nimble Streamer

Follow this easy to use instruction to install and register Nimble Streamer instance in WMSPanel for further setup.

2. Define RTMP settings

Now you need to describe how Nimble will take data from RTMP source.

Go to Nimble Streamer / Live streams settings menu. Global tab has service-wise default Chunk duration for all outgoing HLS streams. It also has Push login and password for applied to all incoming RTMP publishing by default.

These settings can be overlapped by individual applications settings. Click on Applications tab to see list of individual apps.

Click on Add application settings to see a dialog for adding new app setting.

For RTMP pull settings you may need and app name and individual chunk duration.

The next tab you may need is Live pull settings. It allows defining live streams from multiple media sources.

Click Add RTMP URL to define new media source.

Here you need to enter URL of RTMP stream and then application and stream name which you'd like to use for outgoing HLS stream.

Additionally you may specify fallback URLs which will be picked up if your primary stream goes down. This will allow improve the robustness of your streaming infrastructure as Nimble will start using fallback streams immediately so your viewers won't see the difference. Also you can use advanced RTMP pull settings to specify incoming RTMP streams. Please read the Processing RTMP and RTSP pull streams per request article for details.

WMSPanel also provides multiple edit capabilities. You may edit RTMP pull sources as a text setting to able to do things like:

• adding big amount of streams;
• making backup and restore of settings;
• transition of settings between servers.

Just click on Multiple edit button to use the dialog as shown below. Here, a "dr_urls" is a field containing fallback links mentioned above. "url", "application" and "stream" are the fields available in the "Add URLs" dialog.

3. Viewing outgoing streams

Once the incoming streams accepted by Nimble, you will see the outgoing stream available in Outgoing streams page. Click on Outgoing link or Outgoing section on the streaming scheme picture.

List of HLS streams transmuxed from RTMP.

Here you can see result streams available for your viewers. You can see its basic parameters of video and audio stream as well as bandwidth and resolution. To use the outgoing stream, click on URL for Player to see dialog showing several players to view the stream, the URLs to insert into client's players and sample code for several popular players..

4. Adaptive bitrate streams

If you have several streaming sources you can combine them into ABR streams.
Read this article for more details regarding ABR setup and usage.

Even more

The rtmp_instant_pull_remove parameter allows immediately disconnect from pulled RTMP source indicates that stream is stopped/not available anymore.

RTMP to HLS transmuxing is part of live streaming feature set and may be used as the baseline for many combinations of streaming infrastructures.

If you need to secure your RTMP streams, you can also use SSL for RTMP transmission.

When transmuxing incoming RTMP streams, you can use Nimble Advertizer for server-side ads insertion. It provides a framework for inserting pre-roll and mid-roll ads into live streams for further output via RTMP, SLDP and Icecast with custom business logic and per-user ads.
Visit Advertizer web page to find out more.

If you need to change content parameters, like change the bitrate, use our Live Transcoder for Nimble Streamer to transform. It has high performance and low resource usage.

You may set RTMP republishing via Nimble Streamer so you can pull RTMP and then push it further into your Nimble-based network.

If you'd like to use RTMP for playback in Nimble, use RTMP playback streaming feature set.

You may also consider using RTMP streaming API to control this behavior remotely.


RTMP may be recorded for further playback via HLS and MPEG-DASH using the DVR feature set. Read this article for setup details.

Related documentation

Live Streaming features of Nimble Streamer, Live Transcoder for Nimble Streamer, RTMP feature set, RTMP republishing via Nimble, RTMP pulled streams fallback, Pay-per-view for Nimble Streamer, Transmuxing RTMP to Icecast and Shoutcast, Transmuxing Icecast to HLS and MPEG2TS, Nimble Streamer API reference, WMSPanel API reference,

Using RTMP publishers with URL authentication

Currently Nimble Streamer supports RTMP-to-HLS transmuxing having RTMP stream published from any type of encoder as an input. If an RTMP source has multiple bitrates, WMSPanel provides very easy to use UI for composing ABR HLS streams from RTMP.

Of course there is a need for authenticating the incoming streams by defining some user and password, so Nimble Streamer provides this capability as well. Now there are several ways of authenticating a publishing user.

One way is to use credentials within RTMP stream. This is what encoders like FMLE do. This is what Nimble Streamer supports by default. It's described in this article.

Another approach is to pass user and password directly in URL, this is how some encoders implement authentication. This is sometimes called setting RTMP publisher without authentication support.

Nimble Streamer can authenticate this kind of published streams. Let's see how this is done.

1. Nimble Streamer set up

Follow the steps described in this article. When you're in the "3. Start publishing" step, use the setting described below.

2. Open Broadcaster set up

We'll use Open Broadcaster to demonstrate this approach.

The URL with Nimble login and password key will look like this:

rtmp://127.0.0.1:1935/application_name?rtmpauth=push_login:push_password/stream_name

Where push_login and push_password are credentials which you defined during RTMP application set up in WMSPanel at step 1. rtmpauth is a parameter which carries the credentials.

In Open Broadcaster, go to Settings / Stream
Choose
Streaming Type: Custom Streaming Server

Then fill the URL (or FMS URL):
rtmp://_YOUR_SERVER_:1935/_APP_NAME_?rtmpauth=_LOGIN_:_PASSWORD_/

Stream key (or Play Path / Stream key):
_STREAM_NAME_

For example, your URL (or FMS URL) will be the following:
rtmp://127.0.0.1:1935/live_application?rtmpauth=push_login:push_password
And Stream key (or Play Path/Stream key):
live_stream

You may also set RTMP republishing via Nimble Streamer so you can get published RTMP and then push it further into your streaming network. To make it work with 3rdparty streaming source, you may also consider WMSPanel server tasks remote management via web console for convenient control of server-side commands. Launch any command, like ffmpeg process, with no need to log in via SSH, just an easy-to-use web interface.

You may also consider using RTMP streaming API to control it remotely.

If you face any issues setting up Nimble Streamer, contact us directly or drop a message in our forum.

Related documentation

Nimble Streamer, RTMP streaming via Nimble Streamer, Nimble Advertizer,