Quantcast
Channel: Softvelum news: Nimble Streamer, Larix Broadcaster and more
Viewing all 436 articles
Browse latest View live
↧

Streaming VOD from remote HTTP storage via Nimble Streamer

July 22, 2015, 1:19 am
$
0
0
Many broadcasting companies use remote media storage as a convenient way of organizing video-on-demand (VOD) streaming infrastructure. The main advantage of dedicated storage is having all files located in single repository, instead of maintaining multiple copies across all edge servers, and save costs on multiple large hard disk drives. The second advantage is ability to organize centralized backup and failure recovery and convenience of managing content, such as adding, removing or replacing media files. This is why storages like Amazon S3 are extremely popular.

Remote storage support is now available in Nimble Streamer. It works with any server, that supports file access via HTTP protocol. Nimble Streamer support HLS and DASH transmuxing of remotely stored media content. Advanced caching techniques allows Nimble to effectively stream files, those size exceeds available file system capacity.

Streaming remotely stored Media

Nimble Streamer is extremely lightweight and powerful. You can use any cheap virtual machine to stream thousands of files. All you need to do is specify link to your media on remote server via WMSPanel web interface.

Install Nimble Streamer

Please, see how to install Nimble Streamer for your operating system. Or read this blog article to see the example of installation Nimble Streamer on Ubuntu virtual machine.

Set up streaming routes

For local files (available in file system), please check section "Set up streaming routes" in How to stream VOD with Nimble Streamer article from our blog. 
For media files stored remotely, you can perform the following steps:

1. Check that your media is available from remote Storage via HTTP (just try to simply download any media file). In this step you should have a media URL like this http://s3-us-west-1.amazonaws.com/wmspanel/bunny.mp4 (you can use any available remote storage).

2. Navigate to "Nimble Streamer" -> "Edit Nimble Routes" menu section of WMSPanel web interface and click "Add VOD streaming route" link.

3. In the appeared dialog specify path, that is requested by your viewers via public URL and path, that requested content is taken from. Select "http://" in dropdown list and enter path to your remote files location.

4. Optionally, specify the AWS access key id and AWS secret access key if your media files are protected by Amazon.

5. Click "OK" button.

Remote HTTP storage set up for VOD
Your new route will appear in Nimble routes list.

Now if you request http://localhost:8081/s3/bunny.mp4/playlist.m3u8, then Nimble Streamer takes file http://s3-us-west-1.amazonaws.com/wmspanel/bunny.mp4, transmuxes it, and performs HLS streaming.

Test VOD streaming

Now you can test VOD streaming on a desktop and on a mobile device using HTML5 player and JWPlayer. Check "Test streaming media via multiple devices" section of How to stream VOD with Nimble Streamer article.

That's it.

Now you've set up a media server that can stream MP4 video files stored on remote HTTP Storage via HLS and MPEG-DASH protocols.

Take a look at Nimble Streamer performance tuning basics to see examples of live streaming resources usage and also learn about basic approaches to best performance.

In addition to single unit efficiency, you may create robust delivery networks by using load balancing techniques for spreading the load between several Nimble instances.

You can use "vod_cache_timeout" and "vod_cache_min_storage_time" parameters available in Nimble Streamer settings to define maximum and minimum cache lifetime periods.


Related documentation

Nimble Streamer, MP4 transmuxing to HLS VOD streaming, Create ABR VOD HLS with SMIL, HLS re-streaming set up, HLS, DASH and Icecast streaming load balancing, MPEG-DASH streaming via Nimble
↧
Search

Advanced MPEG-TS delivery over UDP via Nimble Streamer

July 26, 2015, 9:03 pm
$
0
0
There is wide range of tasks associated with streaming of media content in MPEG-TS over UDP in corporate networks. Nimble Streamer is capable of transmitting stream to multicast network, DVR Storage, transcoder or presentation monitor.

MPEG-TS over UDP multicast via Nimble Streamer

In some cases it is necessary to transmit multiple programs in a single MPEG-TS stream. This activity is often related to private networks (hotel, enterprise), when using a hardware decoder that supports only MPEG-TS as input.

Packing multiple RTMP, RTSP or MPEG-TS streams to single MPEG-TS UDP stream.

The distinction of Nimble Streamer is the ability to transmux up to 256 RTMP, RTSP and MPEG-TS streams into single multi-program MPEG-TS UDP stream. For each incoming stream the unique PMT PID, Video PID and Audio PID values are assigned. You can take RTMP, RTSP and MPEG-TS streams from any sources, transmux them into a single UDP MPEG-TS stream and transmit via multicast.

To use this functionality in your workflow you need to install and configure Nimble Streamer.

How to install Nimble Streamer


Use this instruction to install Nimble Streamer on your operating system. Or read this article to see the example of installation Nimble Streamer on Ubuntu virtual machine.

Setting up


Login to WMSPanel, go to "Nimble Streamer" -> "Live streams settings".

First of all, you should specify Nimble Streamer incoming RTMP, RTSP and MPEG-TS streams. Go to the "Interfaces" tab on the left side (see screenshot below).


Click on «Add RTMP Interface».


In the window that appears, enter IP-address of an interface that Nimble has direct access to (for example, 127.0.0.1) and port number (default port for RTMP is 1935, but you can specify any free port number). To process stream on any available IP-address - leave the "IP Address" field blank. You can also change the default port, but you have to ensure that RTMP source publishes stream to this port.

If you want to add RTSP network interface click on «Add RTSP Interface» button.


Settings for RTSP are defined similarly to RTMP.

Once the settings are specified for all incoming RTMP and RTSP interfaces, they all appear in the list:


Go to the "UDP streaming" tab to set up outgoing UDP stream.


Push the «Add UDP setting» button and specify


IP (127.0.0.1 in this case) and Port (e.g. 2015) for UDP stream. Next you need to specify incoming streams to transmux to MPEG-TS UDP (in this case interface prompts you to select from a list of incoming streams and automatically assigns PMT PID, Video PID and Audio PID to each stream). To add more streams you need to click on the "Add source" link in the "UDP SETTING" dialog.


Parameters PMT PID, Video PID and Audio PID are set automatically for each stream. It is possible to assign these numbers manually, but you must be aware of allowed values. If any stream stops broadcasting, it is excluded from outgoing UDP stream, while the remaining stream numbers stay the same. If you add another incoming stream to existing streams, it will also get appropriate PIDs automatically. So, this feature keeps you worry-free about the whole UDP streaming gets terminated when one or more incoming streams are removed or added.

As it was mentioned before, web interface allows to add up to 256 source streams for further transmuxing into single outgoing MPEG-TS UDP stream. Pragmatic constraints depend on media server performance and bandwidth.

How to test it


You should already have one or several RTMP, RTSP or MPEG-TS streams. For example, you have three streams: stream_low, stream_mid, stream_high.

As these streams are set up, they can be combined into singe outgoing MPEG-TS UDP stream in the "UDP streaming" tab.


Resulting UDP stream appears in the list.


To test UDP streaming open "MPEGTS In" tab ("MPEGTS In" -> "Add UDP stream") and specify


your UDP stream as a source.


After adding incoming UDP stream, it should appear in the list:


First you see yellow "pending" box, and then after few seconds it becomes green (online).


In the "MPEGTS Out" tab ("MPEGTS Out" -> "Add outgoing stream")


you can choose separate streams by Video PID and Audio PID from your MPEG-TS UDP stream for further streaming.
  

You can combine Audio PID and Video PID from different PMT PID. 
Resulting streams will be displayed in the list.
   

After a few seconds all streams become green (synced).

Now if you go to "Nimble Streamer" -> "Live streams" -> "Outgoing streams", you can see, that all your streams are online.


That's it.


For more information about setting up incoming and outgoing MPEG-TS streams, please refer to "Transmux MPEG-TS into HLS, RTMP, MPEG-DASH and more via Nimble Streamer" article.

If you have any questions about installing and configuring Nimble Streamer, please contact us. You are also welcome to suggest any improvements or ask any questions, we're opened for collaboration. You can also read and post at WMSPanel company forum to find use cases and answers from other users and companies.

Related documentation


Продвинутая доставка MPEG-TS по UDP при помощи Nimble Streamer,

Nimble Streamer, MPEG2TS processing via Nimble, Transmux MPEG-TS into HLS, RTMP, MPEG-DASH and more via Nimble Streamer, RTMP streaming via Nimble, WMSPanel paywall, HLS live streaming, DASH streaming
↧
↧

Adding preconfigured Nimble Streamer server to WMSPanel

July 28, 2015, 11:08 pm
$
0
0
Adding of an existing preconfigured Nimble Streamer server to WMSPanel account

Sometimes it happens, that our customers temporarily discontinue using WMSPanel service for whatever reasons. Or they forget to subscribe to the service for too long after their trial period has ended. In such cases, the customer's account with all settings and statistics data is considered abandoned and is removed automatically.

With all that, all servers continue working regardless of WMSPanel service. Nimble Streamer is a freeware, so it can be used without restriction. Current Nimble Streamer settings are stored in local configuration file. 

When customers return to continue using WMSPanel, they want to add all of their already set up and running Nimble Streamer instances to the service. But that shouldn't be done straightforward via nimble_regutil, because simple registration would lead to total resetting of target server. From now on WMSPanel has dedicated interface for that purpose.

In order to do that, you can perform the following steps:
1. Log in to WMSPanel.
2. Go to the "Servers" tab.
3. Press the "add existing server" link located at the bottom of the web page.


You need to paste the content of your rules.conf file in the appeared dialog. You can find this file in the following directories (depending on your operating system):

Linux: /etc/nimble/rules.conf;
MacOS: /usr/local/nimble/conf/rules.conf;
Windows: C:\Program files\nimble\conf\rules.conf.


Make a backup of your rules.conf file. Then open the file in any editor. Copy its content and paste it in the appropriate field of the "Restore from config" dialog. Then press "Check config" button. If your config file isn't fully correct the dialog displays relevant warnings.


You can either press "Save" and add your preconfigured Nimble Streamer to WMSPanel service with existing errors or press "Back" and try to fix your config file. If your have any questions or you need help to configure your Nimble Streamer, please contact us.


Click on "Save" button if you see that your config file is confirmed as valid. Your media server settings are stored within WMSPanel service. The list of activation commands will appear in new pop-up window after saving.


The recovered server will also appear in the "Servers" page at the same time, but it will be displayed as inactive (red).


To activate your Nimble Streamer instance in WMSPanel you should run appropriate command (see the screenshot above) in your server's console.

You will be asked for your WMSPanel login and password during the activation process.You should restart Nimble Streamer after that. The media server becomes active (green) after restart.


Your server is up and running now. You can continue your streaming activities. Now you are able to take full advantage of using WMSPanel service, such as rich set of statistics, server management, flexibility of streaming configuration and WMSPanel team support.

That's it.


If your have any questions or you need help to configure your Nimble Streamer, please contact us.
You can also visit WMSPanel company forum to find use cases and answers from other users and companies.

Related documentation


Добавление локально настроенного сервера в WMSPanel,

Nimble Streamer installation, Nimble Streamer configuration description, Nimble streaming config, Repair Nimble configs after HW failures


↧

Mobile broadcasting library

July 31, 2015, 7:43 am
$
0
0
WMSPanel team is pleased to announce new product for Android mobile platform, called Mobile broadcasting library (MBL).

Live broadcasting from Android device

At the moment, our WMSPanel service processes data from thousands of different media servers those are doing hundreds of thousands of streams and our Nimble Streamer media server handles billions of connections monthly. We experience a constantly growing demand for new features from our customers who are interested in mobile streaming solutions.

Mobile streaming share increases rapidly, because modern devices are able to provide pretty high quality video and audio content, and, what is important, are broadly used. However, building just streaming application isn't main objective. What really comes to the fore is ability to apply company's business logic to mobile streaming within existing infrastructure or build such infrastructure in easy and common way.

For example, one important concern is security and legality of content delivered from mobile. First of all, streaming application should be able to perform authentication to media servers receiving and processing stream. After the stream is processed and distributed, it can also be important to protect resulting streams from hot-linking. On the other hand, streaming infrastructure should be able to block specific application instance from publishing to media servers in case delivered content is considered offensive or conflicts with company's policies. Next concern is video distribution across available platforms and devices. Then media servers control and reporting. And there is more to come.

So, MBL is not a standalone streaming library, it's intended to be a part of complex streaming solution, provided by WMSPanel.
To be specific, WMSPanel has several well-known products for streaming industry:
  1. WMSPanel statistics and media server management. It is cloud-based streaming control and reporting service.
  2. Nimble Streamer. Fast and powerful streaming server application. According to official reports, only registered Nimble Streamers process billions of connections each month and this number is constantly increasing.
  3. Dispersa. Distributed streams availability verification system. Currently, it processes several thousands of streams.
  4. Paywall streaming protection and monetization framework.

Mobile broadcasting library provides necessary API for broadcasting live video and audio content from mobile device to a media server, which supports RTSP publishing of interleaved H.264/AAC stream over TCP. Basic and Digest RTSP  authentication methods are supported and used depending on capabilities of target media server. MBL was successfully tested with Nimble Streamer, Wowza Streaming Engine and Flussonic Media Server. Minimum supported Android version is 4.1 (Jelly Bean).

Video and audio encoding is performed via Android camera API. Video is encoded in H.264, audio is encoded in AAC format. All streaming related processing is performed via MBL.

The library contains sample Android application, which basically consists of camera selection dialog and stream preview dialog. Sample application is capable of publishing live video and audio to specified RTSP URL. Technically, MBL provides ability to publish to any number of servers (URLs) simultaneously, i.e. that number is only constrained by network bandwidth.

Mobile broadcasting library is a proprietary software and it is distributed per subscription model. Once you make a subscription, you receive a full-time support and all of our updates with new features and enhancements.

Coming soon


Mobile broadcasting library for iOS mobile platform, which allows to easily develop broadcasting applications for IPhone and IPad, is going to be realeased soon. Stay tuned!

Related documentation


WMSPanel, Nimble Streamer, Hotlink protection for Nimble Streamer, Paywall for Nimble Streamer, Paywall FAQ, Dispersa streams monitoring, Monitoring alerts API, RTSP streaming via Nimble, Transmux RTSP to HLS, RTMP, DASH and more via Nimble Streamer, RTSP streaming control API

↧

The State of Streaming Protocols - July 2015

July 31, 2015, 6:09 pm
$
0
0
WMSPanel team continues analyzing the state of streaming protocols.

The metrics calculations are based on nearly 1.4 billion views. The stats are collected from 1800+ media servers (including Wowza, Nimble Streamer and Flussonic).

HLS share is at 69% share with slight decrease of RTMP and Icecast numbers. Check the chart below for more.

The State of Streaming Protocols - July 2015
The State of Streaming Protocols - July 2015.

You can compare that to June stats below.



The State of Streaming Protocols - June 2015
The State of Streaming Protocols - June 2015.

This report is brought to you by WMSPanel team. We'll keep analyzing protocols to see the dynamics. Check our updates at Facebook, Twitter, Google+ or LinkedIn.
↧
↧

Prevent files download while streaming VOD

August 3, 2015, 10:52 pm
$
0
0
Broadcasting companies pay considerable attention to protect their content because nobody wants to loose profit. One of the most urgent problems in internet streaming is blocking the ability to download  media files. If media file is streamed via Progressive download protocol then this file can be easily downloaded. To restrict the ability to download media files by most of your users you can use more complex streaming protocols such as HLS or MPEG-DASH. Progressive download streaming should be blocked.

Blocking Progressive download streaming

You need to set up a rule in WMSPanel to protect your media files from downloading.

Setup


First you need to create a rule that deny Progressive download streaming.
We assume that you already have a preconfigured media server that performs Progressive download and HLS streaming.

Set up rules


You need to add your media server in WMSAuth group to set up a rule. Log in to WMSPanel, go to "Control" -> "WMSAuth paywall setup". Press the "ADD WMSAUTH GROUP" link in the upper-right corner of the dialog.


Specify the group name (e.g. PD_restriction) and give a short description for it in the proper fields.


Then press the "Create WMSAuth Group" button. The new dialog which allows to assign one or more media servers should appear in just created WMSAuth group. Select the media server from drop-down list and press "Assign" button.


You should see the message that server is already assigned. If you want to assign more media servers to this WMSAuth group just repeat the steps above. You can start to create rule that helps to aviod simple media file downloading after assigning media servers to your WMSAuth group. Press the "ADD RULE" link in the bottom right corner of the page.


The rule creation dialog should appear. Give a name for your rule (for example "Protect progressive download by password").


If you need to set the Geo-blocking, IP range restriction, limitation of connections or domain name (Virtual host) for the same rule just fill the proper fields (see the screenshot):


The detailed information about these settings can be found in "Restriction solution for geo, IP range and connections" article.
You can specify vHost, application or stream fields using POSIX regular expressions. 

In this case we are going to apply this rule to all possible links, so we leave all the above fields empty.

To set up the Progressive download blocking rule, you need to define the following elements:
  • Password - a secret key that would be known for both web server and media server.
  • Protocols - which of media server supported protocols is this rule applied. You may want to protect particular protocol while other protocols might have another protection scheme.


Just specify a strong enough password and check the Progressive download checkbox (leave all other protocols unchecked). To save the rule press the "Create WMSAuth rule" button.


Now we have created the rule that blocks downloading media files via Progressive download.

Related documentation


Запрет на скачивание файлов при стриминге видео по запросу,

Hot-linking protection and domain locking, Hot-linking protection for Nimble Streamer, Wowza hotlinking re-publishing and re-streaming protection, Paywall features for Nimble Streamer and Wowza




↧

Domain Lock techniques for media streaming

August 10, 2015, 8:42 am
$
0
0
Streaming process is closely related to your website promotion. You need to restrict the ability of copying your media-links for maximizing profits. This limitation is called Domain Lock and allows to keep your content unique. Here are basic techniques you can use for that.


Robust protection can be achieved via the Hotlinking protection. You need to add a media URL signature and this signed URL won't be played on other domains. For more information please check the "Hot-linking protection and domain locking" blog article. However, this type of protection requires to modify your front-end source.

Sometimes abusers act as "man-in-the-middle", requesting web page from viewer's IP address, taking URL from that page and pasting it into its own media player via special applications. In this case you need to use more complex protection (you can check the detailed information about this technique in "Protecting media links from web scraping" article in our blog).

In some cases it is sufficient to play a media file only from specific URL, which contains your domain name. There is a simplified method that doesn't require changing your front-end source and protects your content from viewing from third-party web pages. This method is based on checking the crossdomain.xml file by media player integrated in web page (see the Cross-domain policy and access control in Nimble Streamer blog article for details).

One more way to secure your stream is to use WMSAuth rules which is described below. This method allows to view video which has a specific domain name in the URL. This restricts the domain mapping to your domain and allows to track on which web resources URLs to your content is included.

You can also combine the above methods to create multi-level protection for your content. These methods completely cover more traditional approaches used in other security systems. They assume that you need to add specific domain names to restrict streaming while WMSPanel feature set is more flexible and powerful.

Let's see how Domain Lock can be implemented using WMSAuth rules mentioned above.



You need to create two rules:
1. Allow viewing for your domain;
2. Deny viewing for other domains.

We assume that you already have streams those should be protected.

To set up streaming you could check the following articles:
HTTP Live Streaming (HLS) as live origin;
HTTP Live Streaming (HLS) for Video on Demand;
Streaming VOD from remote HTTP storage via Nimble Streamer.

Set up streaming rules

You need to specify the IP range before setting up the rules. We are going to allow all possible IP addresses for the first rule.

Set up IP range

Go to "Control" -> "WMSAuth paywall setup" and press the "MANAGE CUSTOM IP RANGES" link.



Press the "ADD IP RANGE" link in the appeared dialog.



Give the Name and the Description for your IP range, then press the "Save IP range" button.



Specify the IP address range using CIDR notation. To set all possible IP addresses type 0.0.0.0/0  and press the "Add range" button.



After you add the IP range for all possible IP addresses (0.0.0.0 - 255.255.255.255) you need to add your media server in WMSAuth group and set up the rules.

Adding media server in WMSAuth group

Go to "Control" -> "WMSAuth paywall setup".
Press the "Add WMSAuth group" button in upper-left corner of dialog.



Type the Name of your group (e.g. Domain Lock) and Description in the appeared dialog. Then press the "Greate WMSAuth group" button.



You need to assign one or more servers in the WMSAuth group in the appeared dialog.



Choose your media server in the dropdown list and press the "Assign server" button. You should see a message that server is already assigned. If you want to assign more media servers to this WMSAuth group just repeat the steps above.

Set up allowing rule

Press the "Add rule" button.


First we should create the rule which allows access to media files only for your domain (e.g. example.com). Give a name to the rule (e.g. Allow streaming for example.com).



In the "Virtual Host" field specify the name of your domain (you can use POSIX regular expressions to specify parameters in this field).
Add the IP range which we created at the "Set up IP range" section in allow list. Choose the IP range ("All IP addresses" in our case)  and press the "<<Add" button. Our IP range should appear in "Allow countries and IP ranges" list. Press the "Create WMSAuth rule" button.

Next you should create the rule that deny access for all other domains.

Set up denying rule

Press the "Add rule" button again.



Specify the rule name (e.g. Deny streaming for other domains). Scroll down to the "Links re-publishing protection" section and specify a strong enough password.


Press the "Create WMSAuth rule" button.


That's it!

As a result, we have two rules which allow viewing content only from your domain (example.com in our case) and block this ability for other domains.

Please contact us if you have any problems with installation. You are also welcome to suggest any improvements or ask any questions, we're opened for collaboration.
You can also read and post at WMSPanel company forum to find use cases and answers from other users and companies.

Related documentation


↧

Using SMIL for adaptive bitrate VOD via MPEG-DASH

August 11, 2015, 5:00 am
$
0
0
Nimble Streamer has an excellent MP4 to MPEG-DASH VOD transmuxing feature set. As an addition to this scenario, our customers were asking if we plan supporting multi-bitrate (adaptive bitrate) support for VOD. The de-facto standard for this kind of tasks is the Synchronized Multimedia Integration Language, or SMIL.

Nimble now has SMIL support for MPEG-DASH VOD just as it has for VOD HLS. Let's see how it's set up and how a user may stream ABR VOD.

Nimble Streamer setup


First, you need to install Nimble Streamer if you haven't done it yet.

Now, having the content located in a local directory - e.g. /var/www/video/ - you need to define a streaming route for Nimble Streamer so the user could access the content via HLS or progressive download with appropriate player. Read how to setup VOD streaming using WMSPanel.
You should try playing the uploaded files via HLS before going to the next step to avoid any permissions or other related problems on your server.
You may also use VOD files from remote location as a source.

Creating SMIL file


Now when Nimble is able to stream your single-bitrate files, let's compose sample SMIL file. For this example we assume you have /var/www/video/ directory with bigbuckbunny_450.mp4, bigbuckbunny_750.mp4, bigbuckbunny_1100.mp4 and bigbuckbunny_1500.mp4 files for respective bitrates.

Here's a SMIL for those.
<?xml version="1.0" encoding="UTF-8"?>
<smil title="">
        <body>
                <switch>
                        <video src="bigbuckbunny_450.mp4" systemLanguage="eng">
                                <param name="videoBitrate" value="450000" valuetype="data"></param>
                                <param name="audioBitrate" value="44100" valuetype="data"></param>
                        </video>
                        <video src="bigbuckbunny_750.mp4" systemLanguage="eng">
                                <param name="videoBitrate" value="750000" valuetype="data"></param>
                                <param name="audioBitrate" value="44100" valuetype="data"></param>
                        </video>
                        <video src="bigbuckbunny_1100.mp4" systemLanguage="eng">
                                <param name="videoBitrate" value="1100000" valuetype="data"></param>
                                <param name="audioBitrate" value="44100" valuetype="data"></param>
                        </video>
                        <video src="bigbuckbunny_1500.mp4" systemLanguage="eng">
                                <param name="videoBitrate" value="1500000" valuetype="data"></param>
                                <param name="audioBitrate" value="44100" valuetype="data"></param>
                        </video>
                </switch>
        </body>
</smil>

As an output, you'll get a manifest like this:
<?xml version="1.0" encoding="UTF-8"?>
<MPDxmlns="urn:mpeg:dash:schema:mpd:2011"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"type="static"xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011 DASH-MPD.xsd"profiles="urn:mpeg:dash:profile:isoff-on-demand:2011"mediaPresentationDuration="PT9M56.375S"minBufferTime="PT1.0S">
<Periodid="0"start="PT0.0S">
<AdaptationSetid="0"mimeType="audio/mp4"lang="eng"segmentAlignment="true"startWithSAP="1">
<SegmentTemplatetimescale="48000"media="$RepresentationID$_$Time$.m4s?nimblesessionid=39"initialization="$RepresentationID$.m4a?nimblesessionid=39">
<SegmentTimeline>
<St="0"d="144384"/>
<Sd="192512"/>
<Sd="288768"r="96"/>
<Sd="281600"/>
</SegmentTimeline>
</SegmentTemplate>
<Representationid="bigbuckbunny_1100.mp4/s_0"codecs="mp4a.40.2"audioSamplingRate="48000"bandwidth="134917">
<AudioChannelConfigurationschemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011"value="2"/>
</Representation>
</AdaptationSet>
<AdaptationSetid="1"mimeType="video/mp4"segmentAlignment="true"startWithSAP="1"maxWidth="1080"maxHeight="608">
<SegmentTemplatetimescale="100000"media="$RepresentationID$_$Time$.m4s?nimblesessionid=39"initialization="$RepresentationID$.m4v?nimblesessionid=39">
<SegmentTimeline>
<St="0"d="300000"/>
<Sd="600000"r="97"/>
<Sd="537500"/>
</SegmentTimeline>
</SegmentTemplate>
<Representationid="bigbuckbunny_1100.mp4/v_0"codecs="avc1.4d401e"width="640"height="360"bandwidth="3751397"/>
<Representationid="bigbuckbunny_1500.mp4/v_0"codecs="avc1.4d401f"width="1080"height="608"bandwidth="5522714"/>
<Representationid="bigbuckbunny_450.mp4/v_0"codecs="avc1.4d400c"width="320"height="180"bandwidth="563137"/>
<Representationid="bigbuckbunny_750.mp4/v_0"codecs="avc1.4d4015"width="476"height="268"bandwidth="2390945"/>
</AdaptationSet>
</Period>
</MPD>

There are case when you have severalvideo or audio tracks in your MP4 file. This can also be handled by SMIL in order to give a player and a viewer some choice.

The following SMIL file should be created to enable adaptive bitrate streaming with several audio channels:

<?xml version="1.0" encoding="UTF-8"?>
<smil title="">
    <body>
        <switch>
            <video height="180" src="sample.mp4" systemLanguage="eng" width="320">
                <param name="videoBitrate" value="152000" valuetype="data"></param>
                <param name="audioBitrate" value="126000" valuetype="data"></param>
                <param name="audioIndex" value="0" valuetype="data"></param>
                <param name="videoIndex" value="1" valuetype="data"></param>
            </video>
            <video height="360" src="sample.mp4" systemLanguage="chi" width="640">
                <param name="videoBitrate" value="434000" valuetype="data"></param>
                <param name="audioBitrate" value="88000" valuetype="data"></param>
                <param name="audioIndex" value="1" valuetype="data"></param>
                <param name="videoIndex" value="0" valuetype="data"></param>
            </video>
           <video height="360" src="sample.mp4" systemLanguage="eng" width="640">
                <param name="videoBitrate" value="434000" valuetype="data"></param>
                <param name="audioBitrate" value="126000" valuetype="data"></param>
                <param name="audioIndex" value="0" valuetype="data"></param>
                <param name="videoIndex" value="0" valuetype="data"></param>
            </video>
            <video height="180" src="sample.mp4" systemLanguage="chi" width="320">
                <param name="videoBitrate" value="152000" valuetype="data"></param>
                <param name="audioBitrate" value="88000" valuetype="data"></param>
                <param name="audioIndex" value="1" valuetype="data"></param>
                <param name="videoIndex" value="1" valuetype="data"></param>
            </video>
        </switch>
    </body>
</smil>

And here's the manifest produced by this SMIL:

<?xml version="1.0" encoding="UTF-8"?>
<MPDxmlns="urn:mpeg:dash:schema:mpd:2011"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"type="static"xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011 DASH-MPD.xsd"profiles="urn:mpeg:dash:profile:isoff-on-demand:2011"mediaPresentationDuration="PT1M12.214S"minBufferTime="PT1.0S">
<Periodid="0"start="PT0.0S">
<AdaptationSetid="0"mimeType="audio/mp4"lang="chi"segmentAlignment="true"startWithSAP="1">
<SegmentTemplatetimescale="44100"media="$RepresentationID$_$Time$.m4s?nimblesessionid=41"initialization="$RepresentationID$.m4a?nimblesessionid=41">
<SegmentTimeline>
<St="0"d="133120"/>
<Sd="177152"/>
<Sd="265216"r="9"/>
<Sd="223232"/>
</SegmentTimeline>
</SegmentTemplate>
<Representationid="sample.mp4/s_1"codecs="mp4a.40.2"audioSamplingRate="44100"bandwidth="128603">
<AudioChannelConfigurationschemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011"value="2"/>
</Representation>
</AdaptationSet>
<AdaptationSetid="1"mimeType="audio/mp4"lang="eng"segmentAlignment="true"startWithSAP="1">
<SegmentTemplatetimescale="44100"media="$RepresentationID$_$Time$.m4s?nimblesessionid=41"initialization="$RepresentationID$.m4a?nimblesessionid=41">
<SegmentTimeline>
<St="0"d="133120"/>
<Sd="177152"/>
<Sd="265216"r="9"/>
<Sd="222208"/>
</SegmentTimeline>
</SegmentTemplate>
<Representationid="sample.mp4/s_0"codecs="mp4a.40.2"audioSamplingRate="44100"bandwidth="135088">
<AudioChannelConfigurationschemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011"value="2"/>
</Representation>
</AdaptationSet>
<AdaptationSetid="2"mimeType="video/mp4"segmentAlignment="true"startWithSAP="1"maxWidth="640"maxHeight="360">
<SegmentTemplatetimescale="12800"media="$RepresentationID$_$Time$.m4s?nimblesessionid=41"initialization="$RepresentationID$.m4v?nimblesessionid=41">
<SegmentTimeline>
<St="0"d="45568"/>
<Sd="128000"r="2"/>
<Sd="108032"/>
<Sd="128000"/>
<Sd="171520"/>
<Sd="86528"/>
</SegmentTimeline>
</SegmentTemplate>
<Representationid="sample.mp4/v_0"codecs="avc1.64001e"width="640"height="360"bandwidth="703863"/>
<Representationid="sample.mp4/v_1"codecs="avc1.64000c"width="320"height="180"bandwidth="240590"/>
</AdaptationSet>
</Period>
</MPD>


Now when the SMIL file is ready, you can perform streaming.

Using SMIL for HLS players and devices

You can access VOD stream via URL like this
http://127.0.0.1:8081/vod/smil:sample.smil/manifest.mpd
Just replace "sample.smil" with your file name and local host with your server's public IP address.

You can use DASH-aware players like dash.js or bitdash by bitmovin to get excellent experience of MPEG-DASH playback.

Let us know if you need help setting up this scenario.

Related documentation

↧
Search

Hotlinking protection in case of dynamically changing IP addresses

August 13, 2015, 5:45 pm
$
0
0


Streaming protection is critical for companies selling premium access to their content. In most cases it is enough to use Hotlinking protection to allow viewing your media only for authorized users. This method is very reliable and is used for years, but it could require additional settings procedure.

Quite often a viewer's ISP performs connection via proxy servers chain. In this case it is necessary to extract a client IP from the request headers to a web server to set up the Hotlinking protection (you can check the "Using WMSAuth paywall with CloudFlare and other proxies" blog article for more information about this technique).

In rare cases ISP changes client's IP address on every request to media server. In this situation media server blocks access to stream because signature of media URL is not correct due to different IP addresses. So even authorized users can't access media content.

You can use Pay Per View framework (PPV) to protect your content and in the same time allow to view video for authorized users. Using this framework you could specify any unique user identifier to generate the URL media signature instead of IP address.

In the Hotlinking protection method the URL media signature is generated via the following code:

<?php
$today=gmdate("n/j/Y g:i:s A");
$initial_url="rtsp://ec2-test-ip.compute.amazonaws.com:1935/live";
$video_url="/Stream1";
$ip=$_SERVER['REMOTE_ADDR'];
$key="defaultpassword";
$validminutes=7;
$str2hash=$ip.$key.$today.$validminutes;
$md5raw=md5($str2hash, true);
$base64hash=base64_encode($md5raw);
$urlsignature="server_time=".$today."&hash_value=".$base64hash."&validminutes=$validminutes";
$base64urlsignature=base64_encode($urlsignature);
$signedurlwithvalidinterval=$initial_url."?wmsAuthSign=$base64urlsignature".$video_url;
?>

This signature depends of $ip parameter which is created from viewer IP address. If IP address is randomly changed during the viewer session then media server will block the access to media data because user request will not pass the checking on media server side.

For PPV the only difference in $str2hash parameter is that instead of IP address it use the $id parameter.

<?php
$today=gmdate("n/j/Y g:i:s A");
// URL of media we want to handle with pay-per-view
$initial_url="http://video.wmspanel.com:8081/vod/sample.mp4/playlist.m3u8";
// client ID which is defined based on customer's database of users
$id="5";
// A password entered in WMSAuth rule via web interface
$key="defaultpassword";
// How long the link would be valid for start playback
$validminutes=7;
$str2hash=$id.$key.$today.$validminutes;
$md5raw=md5($str2hash, true);
$base64hash=base64_encode($md5raw);
$urlsignature= 'server_time='.$today.'&hash_value='.$base64hash. '&validminutes='.$validminutes.'&id='.$id;
$base64urlsignature=base64_encode($urlsignature);
$signedurlwithvalidinterval=$initial_url."?wmsAuthSign=$base64urlsignature";
?>

You can use registered user login (or e-mail) as your $id parameter. You also can use a combination of login, platform (web, Android, iOS) and device id. The good example of the $id creation described in "The Paranoid’s Guide to Internet Video Streaming" article. 

You need to create your own PPV handler for use Pay Per View framework functionality. Your media server will synchronize with this handler on periodical base to receive list of ids for which it is necessary to block access to media. For detailed information about configuration of Pay Per View framework and creating your own handler please check the "Pay-per-view for Wowza Media Server" and "Pay-per-view for Nimble Streamer" articles, and also check the Pay Per View framework section on WMSPanel.com.

Note when you use the Hotlinking protection the media server perform the access decision based on IP address. When you use PPV framework your handler makes the decision to block user or not based on its business logic. The media server will send periodical sync requests to your handler and wait for response which contains users' IDs that must be blocked from accessing the media.

PPV handler debugging technology described in the "Debugging WMSPanel push API for pay-per-view and alerts". 

The procedure of implementing you handler takes certain time. To protect your links and allow to authorized users to view your content you could use already configured Hotlinking protection code snippet with some changes. You can replace the $ip to the $id parameter for make URL media signature. Don't forget to add this parameter directly in your URL ('&id='.$id).

In this case your media will be protected from unauthorized copying. If abuser copy you media link signed using the $id parameter, this link will be able to view only for time specified in the $validminutes parameter.  You could perform WMSAuth rule in which Hotlinking protection based on the $id parameter will be applied only for the specific ISP IP range.

Using PPV framework for protect your media URL from copying you also have the ability to collect high-detail per-user view statistics (view time, number of simultaneous connections, bandwidth) and control you streaming in compliance with your business logic.

Related documentation

Hotlinking protection, Pay Per View framework, Pay-per-view for Wowza Media Server, Pay-per-view for Nimble Streamer, Using WMSAuth paywall with CloudFlare and other proxies, The Paranoid’s Guide to Internet Video Streaming, Debugging WMSPanel push API for pay-per-view and alerts, IP ranges restriction, Hotlink protection with stream-based signature








↧
↧

Larix Broadcaster mobile streaming setup and usage

August 23, 2015, 7:43 pm
$
0
0
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 Android based mobile device via Larix Broadcaster. Larix Broadcaster is a free mobile application which can stream live video or/and audio to media server via RTSP protocol. For our example, we will use Nimble Streamer because it is free and powerful media server with rich set of documentation.

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.

Let's go!

Install Larix Broadcaster application


Open Google Play in your mobile device, type Larix Broadcaster into search window and then press the search icon.
Choose Larix Broacaster on the application page and press the "Install" button.
Allow access to your camera and microphone by pressing the "Accept" button. Application will be installed in a few seconds.
When you launch Larix Boadcaster you will see preview window with "Settings" and "Broadcast" buttons.
See the screenshots below.




Install Nimble Streamer


Nimble Streamer can be installed on all popular Linux distributions - Ubuntu, Debian, RadHat and CentOS. For rapid deployment and periodical updates the batch installation is used. There are separate installers for Windows and Mac OS X.

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.

Now install Nimble Streamer (we are going to show the installation procedure for Windows 7, but you can also install it on Linux or Mac OS X, please note that 64-bit OS is required).

Go to https://wmspanel.com/nimble/install web page then click on Windows tab.



Press the "Download Nimble Streamer Installer" button. The setup file will be downloaded to your file system.

Double click on “NimbleStreamerSetup-2.7.2-3-x86_64.exe” file. Press the "Next" button in the appeared dialog. Select the Destination Folder and press the "Install" button.



The dialog will notify you about successful installation in a few seconds.

Then you need to register just installed media server in WMSPanel. For Windows 7, go to "Start" -> "All programs" - > "Nimble Streamer" and run "Register Nimble Streamer" as administrator. You will be asked for your WMSPanel login and password sent to you during sign up.



Your media server will be visible in the WMSPanel immediately after registration (see the
"Servers" tab on wmspanel.com).



Now lets proceed to Nimble Streamer setup.

Setting up transmux RTSP stream to HLS and RTMP


Log in to wmspanel.com and go to "Nimble Streamer" -> "Live stream settings". 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.


Secify the port number in appeared dialog (this port number will be used in Larix Broadcaster settings). Select your media server and press the "Save" button.




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

Configure Larix Broadcaster application


Launch the Larix Broadcaster application on your mobile device and press "Settings..." button.



Select the "Connection #0, URI" in Settings menu.


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://push_login:push_password@192.168.5.5:1937/live/stream). Press "Ok" button to save your settings.




Now return to mobile application and press "Broadcast" button (make sure, that your mobile device has network connection, e,g, wi-fi). 


Check the streaming


Log in to WMSPanel. Go to "Nimble Streamer" -> "Live streams" 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. However it has a quite long latency (about 6 seconds). If you need to playback video with minimum possible latency, please 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 broadcast live video and/or audio from your mobile device via Larix Broadcaster to your web page, YouTube live or any other CDN.

Please contact us if you have any problems with installation.

Related documentation


Установка и запуск приложения для мобильного стриминга Larix Broadcaster

Larix Broadcaster, Mobile Broadcasting Library and SDK, Installing Nimble Streamer,
Transmux RTSP to HLS, RTMP, DASH and more via Nimble Streamer

↧

Live stream broadcasting to YouTube via Nimble Streamer

August 24, 2015, 11:40 pm
$
0
0
Perhaps, everyone knows about YouTube, the third most visited site in the world. As you know YouTube allows to perform live streaming from any source. Nimble Streamer can be used as stream source to YouTube. You can combine social power of YouTube and performance of Nimble Streamer. 



You can use any encoder to create live stream (e.g. Adobe FMLE or FFMPEG). In this article we are going to describe the process of live streaming publishing from Larix Broadcaster mobile app to YouTube via Nimble Streamer. Nimble Streamer perfectly republishes RTSP and RTMP streams to YouTube.


To create live broadcast on YouTube you need to perform the following steps:
1. Set up the YouTube live event;
2. Configure the stream republishing in Nimble Streamer;
3. Install, set up and launch Larix Broadcaster mobile app;
4. Launch your live event on YouTube and check the result.

Set up the YouTube live event


Sign in to the YouTube Video Manager Live Events page and click "New live event".



In the "Basic info" tab of the Info and Settings page, enter the relevant information about the stream (title, description, date/time, location, and so on) into the fields. For Type, select "Custom (more encoding options)" and press the "Create event" button.


In the "Main Camera" tab of the event's "Ingestion Settings" page, under "Choose maximum sustained bitrate of your encoder", select the ingestion option that best represents your network and encoding capabilities (for our example we choose 300 Kbps - 700 Kbps (240p)). We use low bitrate to guarantee streaming in any mobile network.


Under "Select your encoder", select "Other encoders". Then, copy the "Stream Name" and "Primary Server URL" information to some text document. We'll need this information to configure Nimble Streamer. Press the "Save changes" button.


Now we need to perform media server configuration. Do not close YouTube tab, we will return to it later for live stream checking.

Configure the stream republishing in Nimble Streamer


Log in to wmspanel.com and go to "Nimble Streamer" -> "Live stream settings". 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. Press the "Save" button.


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


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


Go to "RTMP republish" and press the "Add" button.


Specify the "Source application" and "Source Stream" parameters in the appeared dialog, they will be used in mobile application settings. In the "Destination address" field provide the value of "Primary Server URL" field from YouTube live event settings. Leave default "Port" value 1935. Type live2 in the "Destination application" field. Specify the value of "Stream Name" field from YouTube setting in the "Destination application" field.


So, the Nimble Streamer configuration is completed. Proceed to configure mobile application.

Install, set up and launch Larix Broadcaster


If Larix Broadcaster not yet installed, then read the "Larix Broadcaster mobile streaming setup and usage" article.
Launch the Larix Broadcaster application on your mobile device and press "Settings..." button.


Select "Video Size" in Settings menu and select 320x240. Specify 30 fps in the FPS menu entry. We use low resolution in our example because not all mobile devices have ability to perform encoding of high resolution video, and channels of cellular companies often do not have a proper condition to transmit high resolution video with 30 fps. YouTube issue warning if frame rate less than 30 fps, because this led to buffering and viewer often stop viewing. Modern mobile devices are able to generate stream with 1280x720 resolution and 30 fps and more.

Go to "Connection #0, URI" menu entry. 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://push_login:push_password@192.168.5.5:1937/live/stream). Press "Ok" button to save your settings.



Now return to mobile application and press "Broadcast" button (make sure, that your mobile device has network connection, e,g, wi-fi).



Now we need to return to YouTube streaming.

Launch the YouTube live event and check the result


Verify that YouTube is receiving and playing the stream. Go to the YouTube "Live Control Room" page for your event and click the "Preview" button to enable the YouTube to process the incoming stream.


When the "Stream Status" is GOOD click the "Start Streaming" button.


Your live streaming should be started on YouTube. To view your live stream click the "View on Watch Page" button.


Now you can verify that live steaming from your mobile device is launched on YouTube.



The quality of live streaming depends of your mobile device computing power and connection speed in your cellular provider network.

Larix Broadcaster is used as example in this article. Any device (DSLR or web-camera) can be used as a source for a live broadcast stream. Such applications as Adobe Flash Media Live Encoder or FFMPEG can be used as an your live video encoder. Nimble Streamer equally well streams and restreams RTMP both to YouTube and to any other CDN from any source of live video.

Related documentation


Трансляция живых потоков на YouTube с помощью Nimble Streamer

YouTube live stream setup, Larix Broadcaster mobile streaming setup and usage, Larix Broadcaster, Mobile Broadcasting Library and SDK, Installing Nimble Streamer, Transmux RTSP to HLS, RTMP, DASH and more via Nimble Streamer

↧

Building RTMP live streaming network via Nimble Streamer

August 26, 2015, 6:36 pm
$
0
0
Broadcasting companies often face with overcoming the bottlenecks of ISPs networks, when streaming online video. In addition to that, this companies need to take care about load balancing between the media servers to improve robustness.


You can create broadcasting network which is consist of origin and several edge servers to overcome those challenges. You can locate your origin server in a large data center and install your edge servers near your viewers. In this case you can create failover broadcasting network which allows to perform load balancing between origin and edge servers. Essentially, you are going to create you own Content Delivery Network (CDN). In this article we are going to show how to do that via Nimble Streamer and RTMP restreaming.

We will use the Adobe FMLE as a source of live video in our example. But you can use any encoder which supports RTMP streaming (e.g. FFMPEG).


To create a network which is described above, we will perform the following steps:
1. Set up streaming from encoder to origin.
2. Set up republishing from origin server to edge.
3. Set up edge server to receive RTMP stream from origin and to transmux it to HLS.

Install Nimble Streamer


We assume that you already have Nimble origin and Nimble edges installed. If not, please read about the process of Nimble Streamer installation in this page.

Setup streaming from encoder


Launch the Adobe FMLE application. Setup the "Device", "Format", "Frame Rate",  "Input Size", "Output Size" parameters. In our example we will use the following values:
Devece: Build-in web camera;
Format: H.264;
Frame Rate: 30.00;
Input Size: 320:240;
Output Size: 320:240.

Specify the "FMS URL" and "Stream" parameters for streaming RTMP to media server. For example,  rtmp://192.168.5.5:2935/origin and livestream. The names origin and livestream will be used later during republishing set up.



Click the "Connect" button and then click "Start" button. The encoder will be started.

Go to Nimble Streamer setup.

Setup origin server


Log in to wmspanel.com. Go to "Nimble Streamer" -> "Live streams settings" In the "Global" tab check the RTMP protocol checkbox and press the "Save" button.



Go to the "Interfaces" tab and click the "Add RTMP interface" button. Specify the port number for incoming RTMP streams in the appeared dialog (e.g. 2935) and click the "Save" button.


Go to "RTMP republish" tab and click the "Add" button. In the "Source application" and "Source stream" of the appeared dialog insert values from your encoder settings (see Setup streaming from encoder section). Specify the IP address of edge server in the "Destination address" field. Specify edge RTMP port number. Specify values for "Destination application" and "Destination stream" fields for edge server. Click the "Ok" button to save changes.



Then you need to define the edge server settings to allow receiving of RTMP stream from you origin server and for transmuxing RTMP to HLS for further streaming to your viewers.

Setup edge server


On the "Nimble Streamer" -> "Live streams settings" page choose your edge server in dropdown list left of "LIVE STREAMS SETTINGS" page name. In the "Global" tab set the HLS and RTMP checkboxes. Click the "Save" button.


Go to "Interfaces" tab and click the "Add RTMP interface" button. Specify the RTMP port number in the appeared field (1935 in our example). Verify that your edge server is chosen. Click the "Save" button.



After few seconds your edge server will provide output streams via HLS and RTMP protocols. To verify, go to "Nimble Streamer" -> "Live streams" and click on the number in "Outgoing streams" column in your edge server row.



The outgoing stream should appear with green "Online" label. Click on question mark sign to see your outgoing stream.



You can see your stream in the opened dialog. Choose proper protocol and player from dropdown lists in order make sure they work fine.



If you need to add more edges just repeat this procedure and specify your new edge "Destination address", "Destination application" and "Destination stream" in the "RTMP republish" tab of your existing origin server.

You can perform additional settings on edge servers to increase it's performance. Please read the "Nimble Streamer performance tuning" article for details.

We described RTMP republishing but Nimble Streamer has more capabilities to create origin-edge networks.

For RTMP you can use pull mode instead of publishing. You can use RTSP protocol in pull and/or publish mode (depends of which of your servers has open IP address). Also you can use MPEG-TS HTTP/UDP. You can combine these protocols, for example transmit stream to origin from camera (mobile device encoder) by RTSP protocol, use RTMP to republish from origin to some edges, and set up pulling MPEG-TS via HTTP for other edges. Then you can stream from you edges to viewers using HLS, MPEG-DASH and RTMP.



Multilevel hierarchy of media server can by used for large geographically destributed broadcasting networks when edge servers of middle layer will be configured as origins for the next edge servers layer.



You can create high performance and robust live video delivery network via Nimble Streamer.

Related documentation


Построение сети живого вещания по RTMP с помощью Nimble Streamer

RTMP capabilities in Nimble Streamer, RTSP in Nimble Streamer, MPEG-TS support,  Nimble Streamer performance tuning, RTMP republishing via Nimble
↧

Achieving low latency for live streaming using Nimble Streamer

August 26, 2015, 11:16 pm
$
0
0
Latency is what one part of media companies doesn't care about while the other part is really concerned with. If you provide a content, which requires real-time interaction or impact wide audience simultaneously, like great sports event broadcast, then latency is important for you. Actually, it isn't related to media companies only. At the moment, almost every human can pick up a mobile device (modern, of course), install streaming application and broadcast himself/herself all over the globe.

In the video world, latency is the amount of time between the moment a frame is captured and the moment that frame is displayed. Low latency is a crucial requirement for many streaming scenarios. For example, surveillance systems require immediate reaction of observer on any restricted action. Remote participation in public auction doesn't make sense if buyer sees the situation happened several seconds before. Popular sports broadcast, video conferencing and remote quadrocopter piloting are also obvious cases.

There is no specific common value that defines "low latency". Instead, what is considered acceptable low latency is defined by a field of application. For example, 600 milliseconds delay is considered acceptable for remote auction participation system, while certain medical instrumentations require latency to be under 30 milliseconds. But of course those systems are completely different from a technical point of view and the medical system approach would be never suited for any distributed communication system.


Video content is passed through several stages of processing from being captured to being displayed for the viewers and each stage makes contribution to the total delay. The main contributors are the stages those require temporal data storage, i.e. buffering. It's imposed whenever processing must wait until some specific amount of data is available. Therefore, to achieve suitable latency for given system, we need to inspect the system's configuration, identify the major contributing stages and find a way to reduce buffering.

In this article we consider a system streaming H.264 1080p30 video content from a camera or encoder to a display over Internet using media server as intermediate. The processing pipeline can be broken down as follows:

1. Video capture


Short step, depending totally on hardware. Can be excluded from consideration, due to low impact on the delay (< 0.5 ms).


2. Encoding (video compression)


Very important step having influence on all consecutive steps. Hardware encoders are preferred over software ones from the latency point of view, because software codecs typically feature latency overheads related to memory transfers and task-level management from the OS. Correctly set up encoder doesn't introduce noticeable delay itself, but defines bit rate attributes of resulting stream. The bit rate is considered of 2 types: variable (VBR) and constant (CBR).

The main advantage of VBR is that it produces a better quality-to-space ratio compared to a CBR for overall data. However, it requires more processing time and impose problems during streaming when the instantaneous bitrate exceeds the data rate of the communications path, thus increasing the decoders's buffer (as it was mentioned earlier, buffering is imposed whenever processing must wait for particular data). That's why CBR is mandatory for real-life low-latency video systems.

There is more to consider about CBR. In fact CBR isn't constant at any level, because H.264 video content consists of frames having different size. So encoder performs bit rate control processing to force producing the same amount of stream data over equal periods of time, called averaging periods. Bit rate control comes at the expense of quality. The less is averaging period and therefore decoder's buffer, the lower is quality of streamed video.

Production encoders provide various  bit rate control capabilities, which are intended to provide CBR with minimum impact on quality. Description of those capabilites is behind the scope of this article, but you may consider some key features to distinguish latency efficient encoders, including sub-frame Rate Control Granularity and Content-Adaptive Rate Control.


3. Streaming to media server over local network


This step contribution consist of local network delay, which depends on configuration and hardware, possible internal buffering of the encoder and streaming protocol overhead. In order to achieve best of this step, encoder should be properly configured to have at most few frames in its buffer, and connected as close as possible to media server. Streaming protocol should be selected depending on encoder and media server capabilities. The recommended protocols having negligible latency overhead are: MPEG2-TS, RTSP or RTMP.


4. Streaming to viewer's device over Internet


That's most interesting step and the biggest contributor for many scenarios. However, using efficient media server, real-time streaming protocol and reliable Internet connection this step can add comparable or even less delay, than the next one. The first contributor within this step is the media server's internal buffering, which is used during transmuxing of the input stream from encoder. The second is media server buffering related to streaming protocol specifics.

If you want to use HTTP-based protocol, such as HLS or MPEG-DASH to deliver video content to a viewer, be ready to significantly increase streaming latency. The reason is that HTTP-based protocols are designed to deliver media content chunked into segments. The segment size may vary depending on the protocol's parameters, but it shouldn't be less than 2 seconds. For example, the Apple HLS implementation has segment size equal to 10 seconds. So, if you use HLS in such configuration, only this step adds more than 10 seconds to your video streaming system's end-to-end latency.

You may suppose, that HLS or MPEG-DASH can be configured to achieve really low latency by reducing the segement size. Yes, that can be done theoretically but in a very specific environment, having almost no restrictions on networking and software capabilities, which is far away from real life. If you want to create low latency video system in real environment, you should use real-time streaming protocols, such as RTMP and RTSP to deliver content to your viewers.

The last part of this step, that can't be configured but must be taken into account is network delay and jitter. The network delay is simply added to the total latency value, while jitter is considered in the decoder's buffer size.


5. Decoding


It's not really obvious, that this step can be the major contributor. To make sure the decoder doesn’t run out of data during playback, the playout buffer must store all the data corresponding to one complete averaging period of stream with respect to network jitter. So, buffer may vary from containing several GOPs down to few frames, depending on encoder and network parameters. Many players consider the default minimum value for playout buffer equal to 1 second and adjust it during the playback. The least possible playout buffer can be achieved using hardware decoders (players) such as Raspberry Pi.


6. Displaying


This step is similar to the first and is mentioned to complete the picture.


To sum up all the above, we have a real life example, which was provided to us by our customer. His company has built a video streaming system, that is used for remote auction participation and horse-race bets conducted in Australia. Bidders can participate from all over the world, but the main stage, having the best streaming performance is located in Macau.

The system's configuration is very simple. Hardware Encoder publishes stream to Nimble Streamer via RTMP protocol over local network. By default, Nimble Streamer buffers some amount of frames in order to provide smooth outgoing stream in case of unstable incoming stream. If encoder is connected over local network, there is no need in buffering. Setting rtmp_buffer_initial_offset = 0 in the Nimble Streamer's config file makes it to serve the most recent frame and therefore provide the lowest possible latency.

The outgoing stream is pulled by Raspberry Pi embedded RTMP player and is displayed on a large presentation screen in Macau. Ping time from the company's location in Australia to Macau is 141 milliseconds. Raspberry Pi RTMP player's buffer is set to 300 milliseconds. And the resulting end-to-end latency of the 1080p30 stream that is displayed in company's Macau location varies in range from 500 milliseconds to 600 milliseconds.

As you can see, a low latency video streaming system is built in a very easy way and has reasonable cost, which consists mostly of hardware expenses. Nimble Streamer is freeware, so you can build your own streaming system, using free or inexpensive products for encoding and playing. It may not have as high perfomance as the described streaming system, but suffice for your case.

Related documenation


Nimble Streamer, Real-Time Messaging Protocol in Nimble Streamer, Building RTMP live streaming network via Nimble Streamer, Larix Broadcaster, Nimble Streamer performance tuning
↧
↧

The State of Streaming Protocols - August 2015

August 31, 2015, 5:29 pm
$
0
0
WMSPanel team continues analyzing the state of streaming protocols.

The metrics calculations are based on nearly 1.5 billion views. The stats are collected from 1900+ media servers (including our Nimble Streamer, Wowza and Flussonic).

The most interesting fact of this month is that MPEG-DASH has bigger views count than SmoothStreaming. This is a result of continuous work of DASH community for improving tools and solutions. Being a member of DASH-IF, our team keeps on improving our MPEG-DASH feature set as well.

Other protocols share is pretty much the same with HLS being a leader with 69%. Check the chart below for more.

The State of Streaming Protocols - August 2015
The State of Streaming Protocols - August 2015.

You can compare that to July stats below.

The State of Streaming Protocols - July 2015
The State of Streaming Protocols - July 2015.

This report is brought to you by WMSPanel team. We'll keep analyzing protocols to see the dynamics. Check our updates at Facebook, Twitter, Google+ or LinkedIn.
↧

Processing RTMP and RTSP pull streams per request

September 7, 2015, 3:30 am
$
0
0
Live streaming of video over Internet gives a high load on the communication channels. To reduce channels load, and to increase robustness of live streaming the load balancing techniques are used (read the "HLS, DASH and Icecast streaming load balancing" article for details).

Configure pull RTMP only for requested streams

During origin and edge servers configuration for RTMP streams you can use 2 types of restreaming:
  1. Publish RTMP stream from an origin (or encoder) to an edge server.
  2. Edge server can pull RTMP streams. You need to specify IP or hostname of origin server (or encoder).
For RTSP protocol the settings are performed using the same techniques.

You can read more detailed information about the creating of your live streaming network in the "Building RTMP live streaming network via Nimble Streamer" article. In current article we are going to show how to decrease network load by setting up RTMP streams pull by request via Nimble Streamer.


Bandwidth optimization


In large networks not all your streams are requested by all users all the time. But all of these streams continue to be pulled from origin server, that is why fee for the traffic is continuously consumed. 
Nimble Streamer allows to optimize usage of bandwidth via setting up RTMP and/or RTSP streams to be pulled only if users request these streams.

For example, large content providers can offer thousands of media URL of live video, but only part of them will be requested by users at certain periods of time.

The same approach is relevant when using CCTV cameras which transmit video streams over RTSP protocol. Usually in this case only about 20-30 cameras are displayed on the monitor, but overall cameras count may be several hundreds (i.e. for the systems like "Safe town").

Setup procedure


You can perform the advanced Live pull settings setup via Nimble Streamer. This setup allows you to pull only those streams which are requested by viewers and also you can configure media server to pull any streams for the certain application.

To perform these settings go to "Nimble Streamer" -> "Live streams settings" -> "Live pull settings" and click the "Add RTMP URL" button.



Specify the pulled  live video URL in the appeared dialog. You can specify fallback URL (optional). Specify the "Output application" and "Output stream" fields, and also specify the "Idle time" value. If the viewer has stopped watching, the stream will be pulled for this period of time. 



This configuration can significantly save the bandwidth if your streams are rarely used. At the same time latency, associated with the resumption of the stream, will not exceed 200 ms. If your streams are constantly demanded, the inclusion of this function will not give the advantages. For more details about live streaming latency please read the "Achieving low latency for live streaming using Nimble Streamer" blog article.

You can setup receiving of any RTMP or RTSP streams by checking the "Dynamic stream name" and specifying only application name in the Primary URL  (i.e. rtmp://remotehost:1935/live). In this case, any stream belonging to the specified application (e.g., live) is pulled from a source and is processed as described above. This allows you to specify the entire set of possible streams, which greatly simplifies the configuration.



After configuring the server first user requesting the video over HLS or RTMP, initiates pull session.

Security settings


However, you should be very careful when using dynamic stream names. The application could have several hundreds of streams (e.g. video cameras), and not all of these streams need to pull from the source.
This creates the risk that users can force media server to pull a huge amount of streams by their actions. It can cause of unnecessary using of bandwidth  and computing resources. In order to prevent the use of such scenario, you can create the WMSAuth rule, which allows to take and to play only those streams that the user is allowed to access. For more information about restricting access by the stream name please read the "Hotlink protection with stream-based signature" article.

Related documentation

Обработка произвольных RTMP и RTSP потоков по запросу
↧
Search

Import MPEGTS streams list from playlist

September 9, 2015, 5:29 am
$
0
0
Nimble Streamer allows transmuxing the incoming MPEGTS streams for further restreaming via RTMP, HLS and MPEG-DASH protocols. Until recently, it was necessary to add MPEGTS streams one by one, which was very inconvenient in case of large number of streams.





Now you can add multiple incoming MPEGTS streams from the playlist via Nimble Streamer.

To perform this settings go to "Nimble Streamer" -> "Live streams settings" -> "MPEGTS in" menu.



Click the "Add streams from playlist" button.  Specify the playlist name in which MPEGTS streams URLs are contained. Then click the "Get streams" button. You can use HTTP, HTTPS and UDP links to playlist with MPEGTS streams.



You will see the dialog in which you can select required streams via setting the checkboxes. Press the "Add selected" to add selected streams as incoming.



Selected streams will be shown in the list.



There are the restrictions for adding streams from the playlists:

  1. Maximum size of playlist should not exceed 32 kb (media server will ignore extra data);
  2. Maximum number of streams in the playlist should not exceed 500.

These limitations will protect your server from overloading.

After adding MPEGTS streams you can transmux them to HLS, RTMP or MPEG-DASH for further streaming.

Related documentation

Импортирование списка потоков MPEGTS из плей-листа

Transmux MPEG-TS into HLS, RTMP, MPEG-DASH and more via Nimble Streamer, Advanced MPEG-TS delivery over UDP via Nimble Streamer,


↧

Processing RTSP pull streams from IP cameras per request

September 16, 2015, 6:28 pm
$
0
0
Today, surveillance cameras are common for security and monitoring. E.g., they are used to ensure the safety of educational institutions: kindergartens, schools, kid's clubs. Many people use cameras to track the progress of construction projects, and to protect the perimeter of protected objects. Often cameras are put in suburban homes, connecting them to the Internet.

Parents, executives of construction companies and owners of country houses should be able to view the video streams from cameras on their mobile devices at any time.



Nimble Streamer allows doing it via transmuxing RTSP stream from the camera to HLS for further viewing on any mobile device. Using of Nimble Streamer helps to reduce load on network channels between cameras and media server, and also helps to protect video streams from unauthorized viewing.

Next we are going to show how to configure that. 

We assume that you already have RTSP stream from your camera, which is available via public IP address. Also we assume that you have already installed Nimble Streamer.

Log in to WMSPanel. Go to "Nimble Streamer" -> "Live streams settings". In the "Global" tab check the checkbox for HLS and then click the "Save" button.



Go to "Live pull settings" tab and click the "Add RTSP URL" button.


Specify your camera stream URL in the appeared dialog. Specify the "Output application" and "Output stream" for outgoing stream. These names will be used to create outgoing stream URL. Set the "Idle time" parameter: if the viewer has stopped watching, the stream will be pulled for this period of time. This configuration can significantly save the bandwidth if your streams are rarely used, read this article for more detailed description. Don't forget to click on the "Save" button.



You can setup receiving of any RTSP streams by checking the "Dynamic stream name" and specifying only application name in the Primary URL (i.e. rtsp://myipcameras.ru:554/live_cameras). In this case, any stream belonging to the specified application (e.g., live_cameras) is pulled from a source and is processed as described above. This allows you to specify the entire set of possible streams, which greatly simplifies the configuration.

Go to "Nimble Streamer" -> "Live streams" -> "Outgoing streams". On this page you can see your outgoing HLS stream. Click on the question mark sign.


You can view the contents of your stream. If you click on the "Show player's code" link, then you get the code snippet to paste on your website.


Then you can paste this code snippet. In case of using JWPlayer, the YOUR_JWPLAYER_SOURCE_PATH parameter from this code snippet should be replaced by your JWPlayer account's "Player library URL".
      You can paste your stream URL in system player (e.g. VLC) in your mobile device.




      In addition to transmuxing RTSP to HLS you can also secure your streams by setting up hotlinking protection. 

      Related documentation 

      Hot-linking protection for Nimble Streamer, Processing RTMP and RTSP pull streams per request, Geo-location and IP range restriction for Nimble Streamer, Transmux RTSP to HLS, RTMP, DASH and more via Nimble Streamer

      ↧
      ↧

      Nimble Streamer deployment automation

      September 23, 2015, 9:47 pm
      $
      0
      0
      WMSPanel is the official UI for Nimble Streamer and it is available under subscription model. Nimble Streamer is the free of charge media server which can run fine on lower-end servers or Virtual Machines.
      Our customers have long and successful story of using automation deployment of Nimble Streamer, e.g. using Amazon Elastic Cloud. Nimble Streamer can be configured independently of WMSPanel specifying all settings via changing configuration files in manual mode.

      However, to add preconfigured Nimble Streamer to WMSPanel for obtaining full statistics it was necessary to add each server in the control panel manually via the import configuration procedure.

      Performing manual manipulations is very inconvenient in case of large number of media servers. That's why Nimble Streamer allows automating the process of adding preconfigured media server to WMSPanel. Now it is enough to execute a single command:
      sudo /usr/bin/nimble_regutil -u admin@account.com -p password --apply-rules-conf
      After that regutil automatically transfers the Nimble Streamer settings from /etc/nimble/rules.conf file to WMSPanel, and saves the authorization settings to the /etc/nimble/nimble.conf file for sending data to the panel, without changing the other settings.

      This capability is specifically useful when you need to organize the broadcast of a single scheduled event and to gather statistics for it (for example, a concert or the final of the National Cup). This scenario can be also used when you create your own CDN.

      After adding in WMSPanel, each server can be configured via Web interface. Each operation of setting up a new streaming scenario can be applied to all servers instances  immediately.

      With the described functionality, Nimble Streamer and WMSPanel users get additional benefits of automatic infrastructure deployment, best resilience and reliability of their streaming processes.
      ↧

      Setting up VidiU transcoder to work with Nimble Streamer

      September 24, 2015, 12:14 am
      $
      0
      0
      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 checkboxes 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 on your server RTMP port 1935 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.


      In the appeared window click on the "Done" button.



      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.


      That's it.

      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
      ↧

      Mobile broadcasting library for iOS platform

      September 29, 2015, 12:14 am
      $
      0
      0
      Nimble Streamer team experiences a constantly growing demand for new features from our customers who are interested in mobile streaming solutions. Modern devices are able to provide high quality video and audio content, and what's important are broadly used. Hence, mobile streaming traffic share increases rapidly. However, building just streaming application isn't the main objective.

      In July 2015, our team has released the Mobile broadcasting library and the sample application for Android - Larix Broadcaster. Now, on numerous requests of our customers, we are announcing the Mobile broadcasting library and the sample application for iOS platform.

      Live broadcasting from iOS device

      Mobile broadcasting library provides necessary API for broadcasting live video and audio content from mobile device to a media server, which supports RTSP publishing of interleaved H.264/AAC stream over TCP. Basic and Digest RTSP  authentication methods are supported and used depending on capabilities of target media server. The library was successfully tested with Nimble Streamer, Wowza Streaming Engine and Flussonic Media Server. Minimum supported iOS version is 8.3.

        Video and audio encoding is performed via iOS camera API. Video is encoded in H.264, audio is encoded in AAC format. All streaming related processing is performed via the library.

        The library is accompanied by Larix Broadcaster application for iOS, which basically consists of stream preview dialog and dialog for setting encoding and streaming  parameters. The application is capable of publishing live video and audio to specified RTSP URL. Technically, the library provides ability to publish to any number of servers (URLs) simultaneously, i.e. that number is only constrained by network bandwidth.

        The broadcasting library is a proprietary software and it is distributed per support subscription model.
        • Once you decide to get a library, you make a subscription. Once you subscribe, you get a library with SDK. As long as you pay for support subscription, you have a full-time support and all of our updates with new features and enhancements.
        • You can pay as long as you need our services. If you stop payments, the library will still work. If you want to get updates or need help from our team, you subscribe again.
        • Separate iOS subscriptions are available for 300 USD per month each.
        • Combined iOS and Android subscription is available for 500 USD per month total.
        • No entrance fee or other license payments are required. 
        SDK user is granted a non-exclusive, non-transferable, limited license for library, without the right to grant sub-licenses. The user is allowed to use the copy of the library for development purposes and distribute it only as part of his/her compiled deliverables. Read full license for all the details.

        Contact our team to subscribe and get the library with SDK.

        So, the library is not a standalone streaming solution, it's intended to be a part of complex streaming infrastructure, provided by WMSPanel products.
        To be specific, our team has several well-known products for streaming industry:
        1. WMSPanel statistics and media server management. It is cloud-based streaming control and reporting service.
        2. Nimble Streamer. Fast and powerful streaming server application. According to official reports, only registered Nimble Streamers process billions of connections each month and this number is constantly increasing.
        3. Dispersa. Distributed streams availability verification system. Currently, it processes several thousands of streams.
        4. Paywall streaming protection and monetization framework.

        Coming soon


        Larix Broadcaster is planned to be released at App Store soon.
        The broadcast library is just the beginning. Stay tuned for other products and services.
        ↧
        Viewing all 436 articles
        Browse latest View live
        Search