Using Amazon CloudFront for SLDP delivery

Live streaming is growing these days and a lot of its use cases require sub-second delay between image capture and its display on user's device.
That includes online chatting, betting and bidding, gaming, security and surveillance - all of them demand real-time picture to make the immediate response.

With the decline of Flash and RTMP as the main way to view live streams, the industry has been looking for new ways to deliver the media close to real-time.

Softvelum has developed SLDP, a last-mile delivery protocol for end-user devices to cover real-time demand. It's key features are:

• Up to two-seconds delay between origin and player.
• Multiple codecs support: it can deliver whatever your end-user platform can play, e.g. H.264, VP8, VP9, H.265/HEVC.
• Adaptive bitrate support for delivering multiple resolutions and qualities.

Nimble Streamer software media server has full support for SLDP and its features. You can read this article to check how Nimble Streamer may take incoming live streams and produce SLDP based on that input.

SLDP playback is supported by SLDP Player. On Android and iOS, it's a native mobile application, while browser payback is covered by HTML5 JavaScript player working in any MSE- and MMS-enabled browser. All three players can be customized via respective SDKs.

Amazon CloudFront setup

SLDP is a streaming protocol based on WebSockets so it can be delivered via both HTTP and HTTPS on top of TCP.  This makes SLDP pervasive across any networks, including CDNs which support WebSockets.

Recently Amazon CloudFront announced full support for WebSockets. This allows AWS users to use all benefits of this delivery network to get all benefits of SLDP live streaming. If you're not yet familiar with AWS CloudFront, please check this page to get started.
CloudFront WebSockets setup is easy and seamless - you can complete it within a few minutes. In our example below we assume you will use ultimatemediastreaming.com domain for accessing your media streams. We'll add it into distribution settings and then use for further playback.

Notice that CloudFront does not cache WebSockets traffic. It serves only as a network for an optimal delivery.

Go to your AWS Management Console and find CloudFront in AWS services.

Find CloudFront service

You will be redirected to CloudFront Distributions control page.

CloudFront Distributions list

Here you need to click on Create Distribution button to proceed. You will be brought to Step 1 to select your delivery method for your content.

Click on Get started for Web delivery method.

You will need Web method so just click on Get started button. You will go to Step 2 to enter details.

Enter your domain.

This page has a lot of delivery parameters. However, with SLDP you don't need any of that except for Origin Domain Name field. Here you need to enter the domain name which you will map output stream to. In our example it's "ultimatemediastreaming.com" as mentioned previously. Your Origin ID will be generated automatically. You may also specify custom ports of origin server if you need to.

Now scroll down to the bottom of the page.

Create distribution.

Click on Create Distribution button to complete the process. You will then be taken back to distributions list.

Distribution is ready.

CloudFront will take some time to propagate setting across their network, but it won't take a few seconds. Once it's done, copy the Domain Name field value. In our example it's d1qarwymuxges8.cloudfront.net.

SLDP playback

Now CloudFront will take all requests from your viewers and take then to your Nimble Streamer instance.

So now all you need is to set up SLDP output from Nimble Streamer in case you haven't done this yet. Read more about how you can take input from various protocols with Open Broadcaster Studio, Larix Broadcaster and Haivision encoders as examples.

Once you have your SLDP ready, its full playback URL will be like

ws://x.x.x.x/liva_app/live_stream

Here "x.x.x.x" is your IP address and you can replace app name and stream name with your values. Then you map your IP to your origin domain name used in CloudFront settings. This will be like

ws://ultimatemediastreaming.com/live_app/live_stream

Since you've created a distribution in CloudFront, your stream will be available using these final URLs:

ws://d1qarwymuxges8.cloudfront.net/live_app/live_stream 

wss://d1qarwymuxges8.cloudfront.net/live_app/live_stream

The "ws://" prefix is for HTTP and "wss://" is for HTTPS.
You can use these URLs in any of your SLDP players. Your stream will be seamlessly delivered via CloudFront CDN.

Further steps

Now when you've set up low latency transmission, you can try fine-tuning it.

Key frame interval is the first option you could try, it affects the start-up time for a stream as well as switch time for adaptive bitrate stream. The less key frame interval is, the sooner a player will start the playback. Key frame interval is defined in encoder. Here's an example of how key frame interval and alignment can be set in Nimble Live Transcoder.

If you use our free HTML5 SLDP player parameters you may try playing with offset parameter to see how it works in your conditions with your key frame interval. Read this article for more details.

You may also find our SLDP FAQ useful. It clarifies some questions that our customers face when they try SLDP.

If you have further questions regarding SLDP or any other Softvelum technology, please contact us.

Related documentation

SLDP protocol, Nimble Streamer, SLDP setup in Nimble Streamer, Getting started with CloudFront

Playback session authorization in Nimble Streamer

Nimble Streamer paywall features provide a lot of ways of controlling the end-user connection including hotlink protection and pay-per-view which give advanced capabilities but require to sign the stream playback URL on your web page. Other features like geo-location and IP-range block, User-Agent and Referrer fields block require to be pre-configured via WMSPanel.

To give more flexibility, Nimble Streamer now supports sessions authorization via external handler to decide which of the connecting users may continue receiving the stream. The workflow is simple:

1. Player client software connects to Nimble Streamer instance via any stream URL.
2. Nimble Streamer keeps the connection and reaches the external handler, sending all details of this new session.
3. Handler returns response to define further behavior of Nimble Streamer.

Each response has its code in header and body:

• Code 200 response means the stream can be played by this client.
• Code 302 makes Nimble Streamer to redirect the client to a specified URL.
• Code 403 means that this user session is forbidden.

The supported protocols are as follows.

• Live streaming: HLS, MPEG-DASH, WebRTC WHEP, SLDP, Icecast and MPEG-TS.
• VOD streaming: HLS, MPEG-DASH and Progressive download.
• Cache-aware re-streaming: HLS, MPEG-DASH, HDS, SmoothStreaming and Progressive download.

Here's how you can use this.

Enable feature

To enable this playback authentication feature, you need to click Control -> API setup top menu. Then you may either go to Global push API tab to define setting for all sever or to Servers push API tab to define per-server setting.

Opening either of those you can scroll down to Auth handler URL section.

Auth handler URL field sets up the URL for your handler web application.

Protected apps is a list of applications to be protected with the handler. You can add or remove apps using removal icon and "Add protected app" link. If you don't specify exact names then all applications will be protected.

Concurrency defines a number of simultaneous requests to handler to perform at a time.

Allow by default defines if clients should be allowed in case authorization handler becomes unavailable.

Message for handler

Your handler needs to be a web application available via specified URL.

The following JSON message is sent by Nimble Streamer to this handler in POST request body:

{"host":"<host>", "url":"<stream URL>","ip":"<client IP>","user-agent": <User-Agent header> , "referer": <Referer header>, "session_id": <Nimble session ID> , "session_type": <protocol name>}

You can see the meaning of most fields' from the line above. The session_type field value may be one of the following: "HLS", "DASH", "HDS", "SMOOTH", "PD", "ICECAST", "MPEGTS" and "SLDP".

Response from handler

The handler needs to return a JSON with one of the following bodies.

Allow connection:

{"return_code":200}

This means that current client may start receiving the stream in this session.

Redirection:

{"return_code":302,"redirect_location":"http://127.0.0.1:8081/content/blocked.mp4/playlist.m3u8"}

This response body will make Nimble start streaming another stream instead of the one requested initially, i.e. this is a redirection. This is useful if you'd like to show some stub for un-authorized client or if a requested stream is not yet available.

Forbidden:

{"return_code":403}

This response means this stream is forbidden for this particular client session.

Example

Check an example of playback authorization handler which checks URL and prevents playback of chunklist.m3u8 and redirects to playlist.m3u8.

Another approach: set sessions via native direct API

You can also get sessions data and delete un-wanted connection using direct native HTTP API of Nimble Streamer. Read this article for more details.

Stay tuned for updates and let us know if you have any questions on this feature set.

Related documentation

Nimble Streamer paywall features, SLDP low latency streaming, Live streaming features, VOD features

DVR MP4 thumbnails in Nimble Streamer

Nimble Streamer software media server has it DVR feature set which covers the majority of use cases for streams recording and playback.

DVR setup is described in this article and you're probably already familiar with it. Now, to get snapshots of DVR stream, you may use direct URL described below.

Notice that thumbnails are generated as .mp4 files containing a single keyframe. This allows inserting thumbnail in any modern browser using <video> element.

If you'd like to generate JPG thumbnails, please read this article.

The latest thumbnail can be obtained using the following URL:

http://<server>/<app>/<stream>/dvr_thumbnail.mp4

If you'd like to get specific time spot, add epoch time:

http://<server>/<app>/<stream>/dvr_thumbnail_<utc>.mp4

E.g. http://serverip/live/stream/dvr_thumbnail_1542708934.mp4

This feature is enabled by default and if you'd like to disable it, use this parameter in Nimble Streamer config file:

dvr_thumbnails_enabled = false

MP4 output was chosen over PNG or JPG images due to resources usage. MP4 frame can be extracted and inserted into MP4 container with relatively small amount of CPU and RAM. Still image capture requires frame decoding and encoding into proper format which needs extra resources. Our customers like Nimble Streamer primarily because of its high performance and we'd like to keep it that way.

Take a look at this video tutorial to see MP4 thumbnails in action and get familiar with DVR most useful features.

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

You may also find useful the API call for DVR archive export to MP4.

If you have any questions on this or other features, let us know.

Related documentation

Nimble Streamer, Live streaming scenarios, DVR feature set, DVR setup for Nimble Streamer, 

White Paper: Tools for tailor-made streaming

We're excited to announce our latest white paper published at Broadband TV News news web site.

It's called Softvelum: Tools for tailor-made streaming and you can download it by filling out the form on its webpage.


Let us know of your thoughts on this article, tell us what else you'd like to read about.