December 30, 2015

The State of Streaming Protocols - the summary of 2015

WMSPanel team continues analyzing the state of streaming protocols.

Let's review past month and also take a look at the retrospective for the year of 2015.

BTW, also check 2015 summary of our products: Nimble Streamer re-defined, mobile SDK, DVR, MPEG-DASH, HEVC and more.

December metrics calculations are based on 2 billions of views. The stats are collected from 2300+ media servers (Nimble Streamer and Wowza). MPEG-DASH keeps growing, it has 12M+ views. It's now equal to Microsoft SmoothStreaming. HLS has increased to 74% now.

The State of Streaming Protocols December, 2015
You can compare that to November stats below.

The State of Streaming Protocols - November 2015.

You can also compare that to December 2014 statistics

The State of Streaming Protocols December, 2014
A few quick facts about this year looking at this and all other charts from past months:
  • The HLS share was pretty constant through the year balancing around 70% between 69% and 74%.
  • A significant change is the growth of MPEG-DASH which now has 12+ millions of views approaching to 1% share from just a few hundred views (literally 0% share) last year. Nimble Streamer DASH capabilities were transformed into a full-scale feature set so many of our customers made their bet on this technology.
  • MPEG-DASH left HDS behind now competing with SmoothStreaming.
  • Adding RTSP playback support in Nimble Streamer, along with its popularity growth, gave an increase for RTSP share as well.
  • RTMP was continuously going down from 22% to 13%.

This year again we saw the continuous evolution of streaming protocols towards HTTP-based formats. We expect MPEG-DASH to gain more popularity within 2016.

We'll keep analyzing protocols to see the dynamics. Check our updates at FacebookTwitterGoogle+ or LinkedIn.

SRT, RTSP and RTMP publish control setup

Previously our team introduced Publish control framework to allow applying our customers' business logic to incoming streams by defining multi-level authorization.

This article describes publish control setup process from deployment point of view. We'll overview available scenarios and let's go through them step-by-step.

1. Set up publishing

1.1 Setup for RTMP, RTSP and WebRTC

To start implementing multi-level protection with Nimble Streamer you need to use publishing credentials. You specify a unique username and password for a separate application which will be used for accepting published RTSP, RTMP and WebRTC streams.

Publishing applications list.
New publishing application.

1.2 Setup for SRT

The SRT receiver working in Listen mode needs to be set up a bit differently, please check Setting SRT user and password authentication with SRT PASSet article for setup details.

2. Using publish signature

Now we'll start setting up publish control framework. This type of protection requires a publish signature to be added to the connection URI used for RTSP or RTMP streaming from the source.

The signature is based on the following parameters:
  • user identifier (ID);
  • application name and stream name;
  • password which was specified in application;
  • publisher IP address (optional).
You need to specify an application in WMSPanel control UI to operate the incoming streams the publishing users will be grouped in. The application name should be the same as specified on "Start publishing" step. The password which is used in this signature should be specified in the publish control application settings via the UI.

Empty applications list for further publish control.
New publish control app setting.
New app in the list.

To publish to Nimble Streamer, the publisher will use the URL like this:
For RTMP it will be:

For SRT you will define publisher as show in the following example:
ffmpeg -re -i video.mp4 -codec copy -f mpegts pipe:1 | ./srt-live-transmit -v file://con "srt://"
For WebRTC it will be:

Here, a publishsign is the signature for incoming RTSP or RTMP stream.

Check an example of code for generating a signature in our github repo.

The signature is added in URI either manually or via your own application business logic, this is up to a developer to decide on that.

When the user starts publishing RTSP or RTMP stream, the media server will check publish signature and if this signature does not match the calculated signature, then the user stream will not pass.
At this step the publish control is very similar to the hotlinking protection.

3. Using publish authorization handler

You can get further control of the incoming streams during connection time. For this case you need to create a handler application and specify its URL in the control UI in "Control" -> "Publish control" menu.

The handler is an HTTP application which is able to process POST requests and return the response according to your business logic. If you don't specify the handler URL then Publish control framework will not try to call the handler. This is done to allow debugging the signature-checking mechanism described above.

Publish control handler URL setup.
Besides handler URL, you can set up the grouping interval for the incoming streams. The handler is called with some timeout to aggregate several requests in one. This allows avoiding the resources waste in case of frequent calls.

Nimble publish control passes the client signature to the handler. As a response to the request, the handler must return the status and Nimble Streamer acts accordingly to allow or deny the connection, based on the status received from the handler.

The sample code of the handler is available in our github repo. It takes the call from Nimble and returns proper response. The call is a POST request with "Content-type" field of "application/json".

Here's an example of request:
{"PublishAuthRequest":[{"seq":"1", "id":"ID_1", "ip":"","stream":"publish/stream"},{"seq":"2", "id":"ID_2","ip":"","stream":"publish/stream2"}]}
Here you can see the following fields.

  • seq - a sequence number, which is serial number of an entry; it will be used in a response.
  • id - publisher ID within your business logic; each publisher may use several devices while having same user account so this field may be useful for block duplicate streams as example.
  • ip - the IP address of the publisher.
  • stream - the URI of the stream which is being published.

A response will contain statuses of each sequence - either success or fail. Here is an example:
{"PublishAuthResponse":[{"seq":"1", "status":"success"},{"seq":"2", "status":"fail"}]}

You also noticed the "Allow by default" check box in application settings on "Using publish signature" step. If the handler in not available or sequence number is not specified, and this checkbox is turned on, then incoming streams will not be blocked. If it's unchecked then the stream is blocked.

4. Controlling streaming process

With publish control you can manipulate RTSP and RTMP streams not only at connection time, but also during the streaming process as well when the user is already connected and streaming. To use this capability, you need to create a controller app which will request Nimble with any frequency to identify which users still publish their streams. If you need to stop certain streaming session then this controller calls Nimble, specifies the session key and this stream will be blocked immediately.

4.1 Working with Nimble API

All operations described below are made via Nimble Streamer control API. Please refer to the reference to see how it can be used. First of all, please check how to enable API. You may also want to make authorized requests.

When API is enabled, you can start working with it from your controller application. There are two steps to deny unwanted sessions from publishing. First one is to get list of sessions and the second one is to send list of blocked sessions.

4.2 Request sessions from Nimble

To get info about all current published streams you need to call the following method via GET request from your controller app:
Here is how Nimble Streamer responds with sessions IDs.
{"PublishControlStatus":[{"key":"1", "id":"ID_1", "ip":"","stream":"publish/stream"}, {"key":"2", "id":"ID_2", "ip":"","stream":"publish/stream2"}]}
Here are the response fields:
  • key - session key.
  • id - publisher ID within your business logic.
  • ip - the IP address of the publisher.
  • stream - the URI of the stream which is being published.
With that information you can now make decisions about denying some streams.

4.3 Block designated sessions

Now you need to call Nimble API with list of blocked sessions. It's a POST request to the following URI:
The body of this message will contain the list of denied sessions, like this:
{"PublishControlDenyRequest":["1", "2"]}
Here, 1 and 2 are the session key. The response is from Nimble would be:
Now those sessions are blocked.

Notice that all mentioned code samples are available in our github repo.

Overall, the described methods allows obtaining full control over the RTSP and RTMP streams publication process for your infrastructure. This allows building streaming solutions with any business logic.

If you need to change the incoming streams' content parameters, like change the bitrate, use our Live Transcoder for Nimble Streamer to transform. It has high performance and low resource usage.
Please contact our helpdesk if you have any questions regarding the described functionality.

Related documentation

December 25, 2015

H.265 HEVC VOD transmuxing for MPEG-DASH

Nimble Streamer has a wide feature set for VOD streaming for HLS and MPEG-DASH. These formats use H.264/AVC as their default codec. As media streaming technologies evolve over time, a new H.265/HEVC codec was introduced a few years ago. This is a more efficient codec, especially for 4K and upcoming 8K streaming as they require huge bandwidth consumption hence the need for a codec with better compression.

Our team made the first step towards HEVC and today we introduce VOD transmuxing to MPEG-DASH from MP4 encoded with H.265. Our company is a member of DASH Industry Forum so we collaborate with other members to promote this standard.

Transmuxing for H.265 setup is made the same way as it's done for MP4 transmuxing for H.264. Other features are also supported, such as transmuxing from remote HTTP storage and adaptive bitrate support via SMIL.

Read Nimble Streamer HEVC digest page to see full set of HEVC-related features.

Contact us to share your thoughts.

Related documentation

Nimble StreamerMPEG-DASH feature set, HLS VOD streaming, HLS live streaming, Hotlink protection and paywall for MPEG-DASH

December 9, 2015

Mobile SDK for RTMP broadcasting

Our company continuously improves our mobile products.

Currently they include:

  • Larix Broadcaster Android and iOS to stream media from apps to any media server. It's available as part of Larix mobile SDK usage.
  • Publish control framework for Nimble Streamer which provides flexible authentication and control of incoming streams from cameras, mobile devices and encoders.

Until this moment the major supported media protocol was RTSP which is an open standard for broadcasting.

Now we introduce RTMP support for streaming from Android devices. Mobile SDK for Android and Larix Broadcaster for Android are now able to provide published RTMP stream for any media destination which is capable of receiving data via this protocol.

Check Larix Broadcaster on Google Play to start.

Get it on Google Play

Feel free to contact us regarding mobile broadcasting SDK purchase and usage.

Related documentation

December 3, 2015

Media server for Raspberry Pi

Nimble Streamer, the high performance media server with low resources usage is now available for Raspbian, the OS for Raspberry Pi and Orange Pi hardware platforms.

It's also available for ARM64 platforms such as Odroid.

It allows turning this hardware into an efficient streaming device for live and VOD content.

Read this installation instruction with a set of live streaming scenarios setup guide.