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:
rtsp://192.168.1.1:554/publish/stream?publishsign=aWQ9SURfMSZzaWduPW95Zi9YVHBLM0c3QkQ4SmpwVnF1VHc9PSZpcD0xMjcuMC4wLjE=
For RTMP it will be:
rtmp://192.168.5.5:1935/publish?publishsign=aWQ9SURfMSZzaWduPW95Zi9YVHBLM0c3QkQ4SmpwVnF1VHc9PSZpcD0xMjcuMC4wLjE=/stream

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://127.0.0.1:2020?streamid=/live/srtstream?publishsign=aWQ9SURfMSZzaWduPVQ3SzVlMkMySlRxRExmSTdybVdibVE9PSZpcD0xMjcuMC4wLjE="
For WebRTC it will be:
https://your_host/live/whip?publishsign=aWQ9SURfMSZzaWduPW95Zi9YVHBLM0c3QkQ4SmpwVnF1VHc9PSZpcD0xMjcuMC4wLjE=


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":"192.168.1.1","stream":"publish/stream"},{"seq":"2", "id":"ID_2","ip":"192.168.1.2","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:
/manage/publish_control/status
Here is how Nimble Streamer responds with sessions IDs.
{"PublishControlStatus":[{"key":"1", "id":"ID_1", "ip":"192.168.1.1","stream":"publish/stream"}, {"key":"2", "id":"ID_2", "ip":"192.168.1.2","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:
/manage/publish_control/deny
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:
{"PublishControlDenyResponse":{"status":"success"}
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.





November 30, 2015

November 2015 updates

In November, our team continued to make features and improvements.

Before diving into tech update, take a look at Selected Integrators webpage which shows a list of the companies that use our solutions for their customers, integrating our technologies into sophisticated streaming workflows. We recommend contacting these companies if you need help deploying or setting up our products in your environment.

A new version of Larix Broadcaster for iOS is now available in AppStore. Several significant improvements were made. Larix Broadcaster is based on mobile broadcasting library and its source is included in our mobile SDK.

RTSP republishing was added into Nimble Streamer in addition to existing RTSP feature set which already includes transmuxing of incoming streams and RTSP playback.

Nimble Streamer DVR feature set was significantly improved with a few new features:


Speaking of WMSPanel API, it now has multiple streams real-time status API method for those customers who have multiple streams to be tracked simultaneously.

To see some other interesting information, take a look at The State of Streaming Protocols which
shows the growth of MPEG-DASH which overruns HDS, and increase of RTSP share after adding RTSP playback and re-streaming into Nimble Streamer.


Follow us at Facebook, Twitter, Google+ or LinkedIn to get news and updates of our products and services.

The State of Streaming Protocols - November 2015

WMSPanel team continues analyzing the state of streaming protocols.

The metrics calculations are based on nearly 2.1 billion views. The stats are collected from 2200+ media servers (Nimble Streamer and Wowza).

MPEG-DASH keeps growing, it had 8M+ views. It overruns Adobe HDS and it's getting closer to Microsoft SmoothStreaming. RTSP playback and re-streaming feature set gave a slight increase for this protocol with ~8% for now. HLS share is around 70% now.

The State of Streaming Protocols - November 2015.

You can compare that to October stats below.

November 19, 2015

RTSP republishing in Nimble Streamer

RTSP feature set is a popular among Nimble Streamer users that are performing in live streaming, especially directly from cameras. There are cases when the live stream needs to be delivered to edge or other origin servers in order to perform load balancing and build robust infrastructure.

For this case we have streams republishing support. It previously had RTMP support, and now it allows republishing RTSP.
If you have RTMP, RTSP or MPEG-TS incoming stream, you may publish it as RTMP or RTSP to any location that supports those two protocols.

Please refer to "RTMP and RTSP republishing via Nimble Streamer" article for set up details.

Contact us if you have any questions related to this or similar functionality.

November 14, 2015

DVR time fragments requests for EPG in Nimble Streamer

We've recently introduced the DVR feature set in Nimble Streamer which allows recording RTMP, RTSP, MPEG-TS, Icecast and SHOUTcast incoming streams for further playback.

One of the most anticipated scenarios of our customers is the ability to allow the playback the fragment in a specific time range. This is used for various use cases, especially in Electronic Program Guide (EPG) type of applications.

Nimble Streamer now supports time ranges for DVR playback. No special setup is needed. Follow general setup instruction to make settings and then use specially formed URL to get the content.

If your regular HLS DVR stream URL is
http://your.domain.name/live/stream/playlist_dvr.m3u8
then your range URL would be like
http://your.domain.name/live/stream/playlist_dvr_range-<UTC-start>-<duration>.m3u8
where "UTC-start" is the fragment start time as UTC epoch time and "duration" is the length of the fragment in seconds.

The same applies to MPEG-DASH DVR. If your regular URL is
http://your.domain.name/live/stream/manifest_dvr.mpd
then your range URL would be like
http://your.domain.name/live/stream/manifest_dvr_range-<UTC-start>-<duration>.mpd

Examples:
http://your.domain.name/live/stream/playlist_dvr_range-1447069728-120.m3u8

http://your.domain.name/live/stream/manifest_dvr_range-1447069728-120.mpd 

It starts at given time and lasts for 2 minutes.

If you need to set up only the start time and allow continuous playback from that point, use "now" value for that, e.g.:
http://your.domain.name/live/stream/playlist_dvr_range-1447069728-now.m3u8

fMP4 container


The URLs above will work for default MPEG2TS container. If you'd like use fMP4 container for DVR playback, you'll need to use "fmp4" suffix like this:
http://192.168.0.1:8081/live/music/playlist_fmp4_dvr_range-1447069728-120.m3u8
Adding that suffix will create DVR stream with fMP4 container.
Both MPEG2TS and fMP4 DVR streams can be played simultaneously. So you can provide your users with appropriate URLs depending on their device type.

Playback offset


When a player opens a playlist of a DVR which is still currently being recorded, most players will start the playback from some of the last chunks. This is because DVR stream is handled as "live" while it's in recording.

You can recommend players to start the playback from a certain time position by using #EXT-X-START:TIME-OFFSET=<time> tag in DVR chunk list.

Nimble Streamer allows specifying zero offset to define that tag. Use this URL specification:
http://your.domain.name/live/stream/playlist_dvr_range-<UTC-start>-<duration>_offset-0.m3u8
to insert #EXT-X-START:TIME-OFFSET=0 tag. This will recommend a player to start its playback from the beginning of the chunklist. Here's an example:
http://your.domain.name/live/stream/playlist_dvr_range-1447069728-now_offset-0.m3u8

More DVR


Also, check time-shifted playback and thumbnails generation for Nimble DVR.
You may also control DVR via API in order to automate your streaming infrastructure. If you'd like to export DVR into MP4, you can check this instruction.

Take a look at this video tutorial to get familiar with DVR most useful features.


Read other documentation articles for more details and full description of available options.

If you have any feedback or feature requests for DVR, just let us know about it.

Related documentation


DVR timeline browsing and playbackDVR feature setNimble Streamer, Live streaming feature set, DASH streaming,

November 10, 2015

DVR control API in WMSPanel

We've recently introduced the DVR feature set in Nimble Streamer which allows recording RTMP, RTSP and MPEG-TS incoming streams for further playback.

As you know, WMSPanel service has its own API for getting stats and controlling media server behavior.

So now we introduce API for controlling DVR:


This covers all basic operations over video recording in Nimble Streamer.

Contact us if you have any questions or feedback about our API.

Related documentation


Nimble Streamer, HLS live streaming, DASH streaming, DVR feature setWMSPanel API,

Introducing selected integrators

Our team has a number of products that help people build their streaming infrastructure. Some of them need efforts to deploy and implement, such as Nimble Streamer installation, setup and usage, paywall capabilities or mobile broadcasting.

There are companies that have been using and deploying our technologies for some time already. We've created a separate page presenting the list of those partners.

Feel free to contact them directly if you need advanced services while deploying our products.

Contact us if you'd like to join the list of our selected integrators.

October 31, 2015

The State of Streaming Protocols - October 2015

WMSPanel team continues analyzing the state of streaming protocols.

The metrics calculations are based on nearly 2 billion views. The stats are collected from 2100+ media servers (including our Nimble StreamerWowza and Flussonic).

HLS share still grows and it's 74% now.

The State of Streaming Protocols - October 2015.

You can compare that to September stats below.

October 28, 2015

Video recording (DVR) in Nimble Streamer

Streams recording is one of the essential use cases for live streaming. It's important to be able to view stream after the transmission is over, or switch between parts of the show during the transmission.

Nimble Streamer has an excellent capabilities for handling live streams and transmuxing them from RTSP, RTMP, SRT, MPEG-TS, Icecast and SHOUTcast to any supported format like HLS, MPEG-DASH, RTMP, SRT, SLDP, RTSP and MPEG-TS. So the next step we always wanted to make is to create streams recording, also known as Digital Video Recording, or DVR.

Nimble Streamer DVR current features:
For HLS DVR playback you may have your content be packaged in both MPEG2TS and fragmented MP4 (fMP4) containers simultaneously - see the last section of this article for details.

Nimble Streamer DVR allows recording and playing both HEVC (H.265) and AVC (H.264) video content with AAC, MP3 and AC3 audio. Other codecs are not supported.

Nimble Streamer also provides DRM feature set for Widevine, Playready and FairPlay content encryption. When a viewer connects to a stream within an application protected by the DRM, its output will be encrypted with respective DRM engine.

Let's see how you can start using Nimble Streamer DVR in your environment.

Take a look at this video tutorial to get familiar with the most useful features.



Read documentation below for more details and full description of available options.

1. Streaming scenarios setup


This article assumes that you've already installed Nimble Streamer. If not, then use this installation instruction to get an instance on your server or desktop. If you have old version of Nimble, then just easily upgrade it.

Check the following articles as examples of setup:

With all these scenarios being up and running you can start setting up DVR.

2. DVR setup


Go to "Nimble Streamer" -> "Live streams settings" menu to open the setup page. Then click on "DVR" tab to open its settings.

DVR settings tab
Here you can see list of setting. In our example we've set up something, otherwise you would see an empty list. Click on "Add DVR setting" button to start the setup.

DVR setup dialog

Here are the parameters you can define.

  • Application is the name of the application which is used during the live streaming. Whatever application name you use in live stream, it must be specified here. 
  • Stream name can be used to recording of some specific stream. If it's not specified, all streams will be recorded, each one separately within recording path. 
  • Recording path is the location of the storage which you'd like to use. It needs to be a file system location. If you don't specify it, the default cache path of Nimble Streamer will be used. 
  • Loop recording duration is the maximum time window that keeps the content. E.g. if you set this to 1 hour, start streaming and your stream lasts for 1 hour and 10 minutes, then first 10 minutes of recording will be erased to keep the last 10 minutes. This duration mostly depends on your storage capacity. If you don't specify the duration then Nimble will keep recording until it has space at the specified location.
  • Maximum size works the same way as Loop recording duration, but it uses archive size as a trigger to start erasing old recordings. It's specified in megabytes.
  • Min free space enables DVR cleanup when minimum free space on DVR storage has reached the specified limit. E.g. with 90% of available space, Nimble will cleanup archive(s) maintaining recorded duration to avoid filling the storage (same cleanup method used as for "Loop recording duration"/"Maximum size" criteria). It works only for "being recorded" DVR archives having active live stream.
  • Clean up after enables automatic deletion of "too old" content, e.g. older than 24/48/etc hours even for DVR archives that do not have "live stream" running. Nimble will periodically check if there is "too old" recording based on number of hours set and then delete it.
  • Read-only mode allows using pre-recorded archives as well as performing scheduled recording. This mode allows pausing the recording process while the archive will be still accessible for playback. Read this article for more details on operating DVR this way.
In the example above we used Larix Broadcaster mobile application to push RTSP stream into demo Nimble instance and we've set up its recording accordingly. We specified only the application name because it was up to the streamer to define a stream name.

Advanced settings include the following parameters.
  • Segment duration is the duration of the chunk being used for media storage. 
  • Thread name and priority are used for splitting recording process among several threads.
Other options include Drop invalid segments, Keep protocol timestamps and Check segment sizes on load, please read Handling timing errors article to get full details about them.

Keep SCTE-35 markers option allows recording SCTE-35 markers from incoming stream into DVR. Once HLS DVR is played, those markers are streamed along with the content.

Keep ID3 metadata allows recording ID3 tags into DVR if your source has them, whether it's Icecast or pulled HLS.


Adding from streams list

You may also easily set up recording from existing incoming and outgoing streams lists. Being in the respective lists, just click on recording button to be redirected to previously described DVR setup dialog.


ABR HLS streams

To have a DVR for ABR HLS stream, just define DVR for single bitrate streams as usual and then create an ABR stream based on those streams. After that you'll be able to play that stream as other DVR streams, check the following section for playback details.

3. DVR recording and playback


The recording process starts as soon as Nimble Streamer starts getting the incoming stream. Each stream is recorded into its own recording path. If only an application is defined then a sub-directory after stream name will be added. If the stream was specified then its path will be used.

Each recording session will be appended into stream location. So you can start, stop and resume incoming stream several times and Nimble Streamer will write the content as if it would be a single session. Obviously, the playback will be played as a single outgoing stream.

To view the existing DVR streams, go to "Nimble Streamer" -> "DVR streams" menu to open DVR streams list as shown below.

List of DVR streams.

As you can see we had 2 publishers, each having separate stream name. So every stream was recorded separately. For each one you can see its server and name, recording path and current recording size, total duration and some media parameters. You also have an option to remove un-used streams recordings as well.

Now for every stream, you can click on a question mark to open sample dialog.

DVR sample playback.
Here you can copy the outgoing DVR stream URL for further usage in your player or application. It also allows viewing the DVR stream in selected players to see what was actually recorded before giving the link outside.

Basically if you have a live stream name like
http://yourhost/live/stream/playlist.m3u8
then your DVR stream URL will be
http://yourhost/live/stream/playlist_dvr.m3u8
ABR live streams work the same way. For ABR stream name like
http://yourhost/live_abr/stream/playlist.m3u8
the DVR stream URL will be
http://yourhost/live_abr/stream/playlist_dvr.m3u8
You may use it in any HLS-capable players.

MPEG-DASH


The same applies to MPEG-DASH except it doesn't support ABR. Your stream like
http://yourhost/live/stream/manifest.mpd
will be available as
http://yourhost/live/stream/manifest_dvr.mpd

fMP4 container for HLS


The HLS URLs described above will have their content packaged in MPEG2TS container. However you can use fMP4 container for DVR playback, you'll just need to use "fmp4" suffix like this:
http://192.168.0.1:8081/live/music/playlist_fmp4_dvr.m3u8
Adding that suffix will create DVR stream with fMP4 container.

Both MPEG2TS and fMP4 DVR streams can be played simultaneously. So you can provide your users with playlist_dvr.m3u8 and playlist_fmp4_dvr.m3u8 URLs depending on their device type.

fMP4 container will work the same way as MPEG2TS for all DVR-related features like selecting range or time shift.

Removing DVR archives


Each recorded stream has its own archive. That archive is not mapped to a DVR setting so if you delete DVR setting from the DVR settings page, the archive files won't be deleted. Only the setting will disappear from the panel.

If you need to delete archives, you need to do it manually using DVR stream page. Notice that if you don't stop the DVR setting and will try to remove the archive, it will appear again because the setting will have the same destination for recording.
So in order to delete archive files, switch the stream to Read-only mode, and then delete files from DVR Streams page.
 
If you removed the DVR setting but kept the recorded streams archives, you may create the DVR setting again for the same stream. In this case Nimble will detect the old files on a hard drive and show it as one archive e.g. duration in the panel and on the timeline.

If you Pause DVR settings for the specific stream, you won't have its DVR streams shown on the DVR Streams page, as this is considered a stopped DVR setting, which makes Nimble 'forget' the DVR recorded stream until it is resumed.

Troubleshooting


Video/audio timing. Sometimes when MPEG-TS stream is used as a media source, it may have some glitches either in video or audio. This is caused by third-party encoders which set incorrect time stamps assigned to media fragments. Check timing errors handling article to learn more details about fixing this kind of issues.

Audio glitches. If you use HLS DVR output with MPEG-TS containers and have audio glitches or audio is missing, you need to enable interleaving compensation for the target application. Click on Nimble Streamer -> Live streams settings top menu, choose the application which you record your DVR for, then check Enable interleaving compensation option and set Min delay time must be set to "0".

MPEG-TS or HLS pull source. If you use pulled MPEG-TS or HLS as a source for your live stream, you need to make the following DVR setting adjustment. Go to DVR setup dialog for your DVR stream, click on Advanced settings... item and check Keep protocol timestamps check box. This will prevent possible issues with source timestamps.

DVR API

Please notice that you may also control DVR via API in order to automate your streaming infrastructure.

If you'd like to export DVR into MP4, you can use this API call or use this instruction for other option.


Related documentation


October 26, 2015

RTSP playback support in Nimble Streamer

Early this year our team introduced RTSP transmuxing support for Nimble Streamer which allowed to take RTSP streams and produce HLS, DASH and MPEG-TS outgoing streams.

As our customers requested, now we introduce RTSP TCP interleaved playback in Nimble Streamer which means the stream can both be played and pulled from the Nimble instance for further processing. To make this output, the Nimble Streamer instance may take the input of RTSP, RTMP and MPEG-TS protocols.

1. Install Nimble Streamer


Use this installation instruction to get Nimble on your server or desktop. The procedure is easy and straight-forward so having any popular 64-bit Linux, Windows or MacOS will allow you to get it working.

2. Make general settings


Since you've completed WMSPanel account sign up at the previous step, you can log into the system and go to "Nimble Streamer" -> "Live stream settings" menu.

The first tab you need is called "Global". Here you need to select output protocols which you will use for playback at selected server. In the following example we see HLS, RTSP and MPEG-DASH.

Selecting protocols for playback.

October 21, 2015

Larix Broadcaster mobile streaming from iOS to Nimble Streamer

Do you want to broadcast live video from mobile device to your own audience all over the world? The viewers might be your clients, colleagues, friends, family or everybody else you want to show the current moment of your live. Sure, that should be simple. Just point your mobile device and push the button.

In this article we are going to show how to create video streaming from iOS mobile device via Larix Broadcaster. Larix Broadcaster is a free mobile application which can stream live video and/or audio to media server via RTSP protocol. In this example, we'll use Nimble Streamer because it's a freeware powerful media server with rich feature set.


You can visit Larix Broadcaster web page for full Larix feature set description.
Please also visit Larix documentation reference to see more articles about app setup.

To launch the live steaming from a mobile device via Larix Broadcaster you need to perform several steps:
  1. Install Larix Broadcaster on your mobile device;
  2. Install Nimble Streamer and make necessary settings;
  3. Specify published URL in Larix Broadcaster;
  4. Open output stream from the media server and check that everything works fine.

1. Install Larix Broadcaster application


Open AppStore in your mobile device, search for Larix Broadcaster and proceed with installing it. Or just use this direct link.

When you launch Larix Broadcaster you will see preview window with "Settings" gear icon and and other buttons.

2. Install and set up Nimble Streamer


Nimble Streamer can be installed on all popular Linux distributions and Windows. For more details about Nimble Streamer installation please see this page. You need to sign up WMSPanel account before starting the installation.

Go to wmspanel.com and press the "Sign Up" link in the top right corner.

Specify your e-mail address in the appeared dialog and then press "Sign Up" button. Follow the instructions from the received e-mail message to complete the registration.

Go to https://wmspanel.com/nimble/install web page and follow installation and registration instructions.

Now let's proceed to Nimble Streamer setup.

Log in to WMSPanel and go to "Nimble Streamer" -> "Live stream settings" menu. Check the HLS and RTMP checkboxes in "General" tab and then press the "Save" button. You may specify Push login and Push password to protect you connection with mobile device. This login and password will be used in Larix Broadcaster settings.




Go to "Interfaces" tab and press "Add RTSP interface" button.


Specify the port number in appeared dialog. Also, this port number will be used in Larix Broadcaster settings. Select your Nimble Streamer instance and press the "Save" button.




In order to make your outgoing stream be available for RTMP playback, add RTMP port as well. That is usually 1935.

If you'd like to avoid publishing from un-authorized sources, you need to set up login and password which you may then use in this app. Go to Global tab to set up server-wide credentials or create application-specific credentials. Refer to this article for basic workflow setup.

So the basic Nimble Streamer configuration to work with Larix Broadcaster is completed. Proceed to configure mobile application.

3. Configure Larix Broadcaster app

For more information about streaming setup, visit Larix documentation reference hich includes video tuutorials.

Specify the IP-address of your media server, Port and Path. If you have specified Push login and Push password then RTSP URL should look like
rtsp://192.168.5.5:1937/live/stream
For RTMP it will be
rtmp://192.168.5.5:1937/live/stream
I user and password fields, enter push_login and push_password


Now return to mobile application preview screen. Make sure that your mobile device has network connection and press "Broadcast" big red button.

4. Check the streaming


Now get back to WMSPanel. Go to "Nimble Streamer" -> "Live streams" menu and click on the number under the "Outgoing streams" column.

Then click on the Question sign in the stream name row.

The video playback from mobile device starts automatically in the appeared dialog. By default the most popular streaming protocol (HLS) is used for video playback. HLS is supported by the most modern mobile devices. If you need to playback video with minimum possible latency, you may use RTMP protocol. To configure minimum latency please read the "Nimble Streamer performance tuning" article.

Also you can play streaming URL with system player (e.g. VLC).

You can now broadcast live video and/or audio from your iPhone and iPad via Larix Broadcaster to your web page, YouTube live or any other CDN.

Larix premium SDK


If you'd like to create similar iOS app capable of media streaming, you can use our mobile broadcasting library and SDK which is the core of Larix Broadcaster. You will get Larix source code and a library for further UI customization.

Some frequent questions regarding Larix Broadcaster ap and SDK are answered in our FAQ.

Visit our documentation reference page for more Larix setup information.
Also, take a look at our Mobile to mobile snapshot which shows the example of using Softvelum products for building mobile streaming and playback network.


Please contact us if you have any questions.

Related documentation


Transmux RTSP to HLS, RTMP, DASH and more via Nimble Streamer

October 12, 2015

SRT, RTMP and RTSP publish control framework overview

For the past few years, mobile devices were showing significant improvements for video creation capabilities hence the popularity of video live streaming solutions - from mobile broadcasting applications to complex all-in-one solutions. If you create a streaming solution yourself, you need to be able to control the publication process for the protocol which you choose to work with, e.g. for RTSP or RTMP.

SRTRTSPRTMP and WebRTC incoming streams were supported in Nimble Streamer for a while already among other protocols. Nimble supports SRT, RTSP, RTMP and WebRTC streaming authentication server-wise as well as for specific applications. So if a customer needed to separate publishing permissions between his users, he needed to create separate application for each individual publisher. But when you broadcast from mobile devices, you probably will need some better way to make sure each publisher has separate permission to publish.

Our customers have been using WMSAuth Paywall functionality to secure the outgoing streaming for a long time. Now to secure the incoming streams, we introduce the Publish control framework which allows performing multi-level authorization.

So now Nimble Streamer allows controlling the publication for RTSP, RTMP and SRT in Listen mode receiver both when establishing connection time and during the streaming process. It has various options so let's see what we have, step by step.


The following scenarios authentication are available.

"Zero option" is if you don't need any protection for incoming streams, then you can just specify only port number for RTMP and RTSP, and define SRT listener. Any publishers can push any streams to your server through the specified port so we do not recommend it. WebRTC requires authentication though.

1. Use publishing credentials

The first scenario is to create a separate application in Nimble Streamer settings for each user with unique username and password to get authorized streams from different authorized users. This mechanism is unsuitable for the large number of users and does not allow to block users during streaming process because the authorization takes place only at the time of connection of the user.

2. Use per-stream publish signature.

In order to allow multiple users to publish streams to the media server and to have the flexibility to control streams, you need to use our Publish control framework.

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

To publish to Nimble Streamer, the publisher will use the URL like this:
rtsp://192.168.5.5:554/live/stream?publishsign=aWQ9SURfMSZzaWduPW95Zi9YVHBLM0c3QkQ4SmpwVnF1VHc9PSZpcD0xMjcuMC4wLjE=
For RTMP this will be
rtmp://192.168.5.5:1935/live?publishsign=aWQ9SURfMSZzaWduPW95Zi9YVHBLM0c3QkQ4SmpwVnF1VHc9PSZpcD0xMjcuMC4wLjE=/stream
For SRT receiver in Listen mode you will define streamid as show in the following example, read Setting SRT user and password authentication with SRT PASSet article for setup details of proper streamid.
ffmpeg -re -i video.mp4 -codec copy -f mpegts pipe:1 | ./srt-live-transmit -v file://con "srt://127.0.0.1:2020?streamid=/live/srtstream?publishsign=aWQ9SURfMSZzaWduPVQ3SzVlMkMySlRxRExmSTdybVdibVE9PSZpcD0xMjcuMC4wLjE="
For WebRTC the WHIP signaling URL will be
https://your_host/live/whip?publishsign=aWQ9SURfMSZzaWduPW95Zi9YVHBLM0c3QkQ4SmpwVnF1VHc9PSZpcD0xMjcuMC4wLjE=


Here, a publishsign is the signature for incoming stream.

When the user is going to publish 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. Use connection handler to manage connection process.

To get full control for the incoming streams, you need to create a handler application and specify its URL in the control UI.

The handler is an HTTP application which is able to process POST requests and return the response according to the business logic of the customer. 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.
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.

Publish control passes the client signature (publishsign) 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.

4. Use publication controller during streaming

With publish control framework you can manipulate SRT, 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 perform this, each streaming session is assigned with its own key. You can create publish controller app which can request Nimble with any frequency to identify which users still publish their streams.
If you need to stop certain streaming session then your controller calls Nimble, specifies the session ID and this stream will be blocked immediately.


Using publish control framework you can implement any level of incoming streams security from basic level authorization to advanced business logic solution.

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.



Next step is the setup


The next article describes step-by-step publish control set up with examples of source code, requests and responses.




Also check playback authorization feature set which allows controlling playback connections via external handler similar to what is used in publish control.

Related documentation


RTSP streaming via Nimble Streamer, RTMP feature set in NimbleNimble Streamer paywall feature set, Larix BroadcasterSRT Publisher Assistance Security Set, WebRTC support in Nimble

September 30, 2015

The State of Streaming Protocols - September 2015

WMSPanel team continues analyzing the state of streaming protocols.

The metrics calculations are based on 1.8 billion views. The stats are collected from 2100+ media servers (including our Nimble StreamerWowza and Flussonic).

HLS share grows again and it's 71% now.

The State of Streaming Protocols - September 2015.

You can compare that to August stats below and also check September 2014 stats as well to see how things changed over the last year.

September 24, 2015

Setting up VidiU transcoder to work with Nimble Streamer

Our customers quite often use Teradek VidiU transcoder and ask us how to setup it to work with Nimble Streamer. In this article we are going to show how to configure it.

Teradek VidiU is a portable standalone streaming media encoder on the go that can be mounted on top of cameras. VidiU provides instant transmission of live video signal encoded as H.264 video - to a content delivery network (CDN) of choice. This low cost encoder eliminates the need for expensive encoders and equipment to delivers HD quality video online.

If you have one, please start from Teradek VidiU Quick Start Guide and proceed step-by-step to chapter 5: "Connect to VidiU with a web browser". Leave your Teradek settings window opened, we will return to it after configuring Nimble Streamer.

Nimble Streamer settings


First you need to create Application for your Teradek VidiU stream and configure RTMP interface for Nimble Streamer.
Log in to WMSPanel.com, go to "Nimble Streamer" -> "Live streams settings" -> "Applications" and click on "Add Application settings" button.


Specify Application name, Push login and Push password (e.g. VidiU, test, test). Check the check boxes for outgoing protocols (e.g. HLS, RTMP and DASH). Click on "Save" button.



Then go to "Interfaces" tab and click the "Add RTMP Interface" button.


Specify port number for RTMP interface (by default 1935) and click the "Save" button.



Verify that RTMP port 1935 on your server is opened and is not blocked by firewall.

Teradek VidiU settings

Now you need to switch to your Teradek VidiU device settings.
Open web browser with your VidiU settings page. Click on the "Settings" button.


Then click on "Broadcast" icon on settings page.


In the appeared dialog window specify your RTMP server URL (e.g. 192.168.5.5:1935/VidiU) and Stream (e.g. live_stream). Then click on "Advanced RTMP Settings" dropdown menu and specify Username and Password for your Nimble Application (e.g. test, test). Click on the "Save As a Profile" button. Then click on "Settings" button.


Click on the "Done" button in the next window.



Click the green broadcast icon and confirm that the stream status changes from green Ready to red Live. This will confirm that VidiU was able to connect to your Nimble Streamer.


Your broadcast icon should become red.


And after a few second you will see your stream.


Then if you go to "Nimble Streamer" -> "Live streams" you can see your user live stream in outgoing streams:



If you click on question mark sign button you will see the content of this stream with HLS, DASH and RTMP URLs and web player code snippet to embed this video on your web page.

The media URL should be as following:
http://192.168.5.5:8081/VidiU/live_stream/playlist.m3u8
http://192.168.5.5:8081/VidiU/live_stream/manifest.mpd
rtmp://192.168.5.5:1935/VidiU/live_stream