Private Live

Normal

doug.jpg

twitter-brands.svg

Doug Twitter

Doug Sillars

Tutorials

We were recently asked in our website chat:

large_screenshot-2021-03-12-at-12-58-53.png

medium_screenshot-2021-03-12-at-12-58-53.png

small_screenshot-2021-03-12-at-12-58-53.png

thumbnail_screenshot-2021-03-12-at-12-58-53.png

screenshot-2021-03-12-at-12-58-53.png

I love hard questions. Befiore I come up with my answer, let's walk through a few definitions to describe what we are attempting to do.

## Live streaming

When you livestream a video with api.video, we take your live video input and turn it into multiple output streams (of different sizes) on the fly.  If your upload stream is 1080p, we will deliver 240p, 260p, 480p, 720p and 1080p streams to your viewers.

If your users are on a smaller screen (like a phone) - they’ll get a smaller resolution video.  If they are on a slower connection - we’ll serve the biggest video that will play in their network conditions.

## Watermarking

Adding a watermark requires ‘burning’ text into the video.  If you use our sandbox, you’ve seen what a watermark *could* look like:


medium_screenshot-2021-03-11-at-14-22-05.png

small_screenshot-2021-03-11-at-14-22-05.png

thumbnail_screenshot-2021-03-11-at-14-22-05.png

screenshot-2021-03-11-at-14-22-05.png

In our sandbox, we watermark each video to show that it is being delivered from the sandbox.

### What the ask was:

Burn the user’s name into the video. For example, if I were watching their highly sensitive video, it might look like:


medium_screenshot-2021-03-11-at-14-23-07.png

small_screenshot-2021-03-11-at-14-23-07.png

thumbnail_screenshot-2021-03-11-at-14-23-07.png

screenshot-2021-03-11-at-14-23-07.png

The idea here is to prevent leakage of the information. If anyone takes a screenshot, or they share the video stream - it is clear that the culprit was Doug, not Cedric, Anne-Sophie or Erikka.

### Why we cannot do this

If we create a unique stream for each user, and the video is 1080p, we’d have to encode 5 streams *per viewer*. Since we can host live streams with hundreds of thousands of viewers, it is not feasible (or cost effective for the account holder) to encode 100k unique videos.

## But...

It turns out, there is a pretty good workaround that satisfies the requirements of our user.

First, we’ll use a [private livestream](https://api.video/blog/product-updates/new-beta-feature-private-livestreams). Private livestreams work just like a regular livestream, but our player URL has an added token on the url:

https://embed.api.video/live/li5rw3I105fgajJEpfvr59AK?token=1d5a3684-c653-4f2a-a9cb-0ae25c00fe66

If the token is removed, the live stream will not play.  Each token can be used exactly once. If your viewer starts watching your event and they grab the URL from the source code and share with their friends - all views past count 1 will get an error message.

So that takes care of the live stream being shared with people who should not have access.

### Screenshots

The video cannot be shared, but what if the video is showing off the latest top secret product from your company?  You want to show it to your selected audience, but photo leaks of the product would be just as disastrous to your company.  So, we’ll add watermarks.

As we stated above, watermarks cannot be ‘burned’ into the video.  But, we can overlay the video with CSS. Here’s the HTML:

```
<html>
<head>
</head>

<body>

<div class="container">
    <iframe id= "video"src="https://embed.api.video/vod/vi2nVamC6JpFFNXEJrV5kI1J" width="100%" height="50%" frameborder="0" scrolling="no" allowfullscreen="true"></iframe>
    <div class="overlay">
        <p>This video is being watched by Doug.. This video is being watched by Doug.. This video is being watched by Doug.. This video is being watched by Doug.. This video is being watched by Doug.. This video is being watched by Doug.. This video is being watched by Doug.. This video is being watched by Doug.. This video is being watched by Doug.. This video is being watched by Doug..</p>
    </div>
</div>
</body>
</html>
```

There is a div with an iframe holding our video (in this case, it is a VOD that is not private -strictly for demo purposes, but you could add your private livestream in the src tag).  Then we have a paragraph of text that we will overlay on the video.

In the head of the HTML, add this style:

```
<style>
	.container { position:relative; }
	.container video {
	    position:relative;
	    z-index:0;
	}
	.overlay {
		display:inline;
	    position:absolute;
		color: orange;
		font-size:100;
		opacity: 0.8;
		height: 100%;
		top:0;
		bottom: 25%;
	    left:5%;
	    z-index:1;
		pointer-events:none;
		overflow: hidden;
	}

	
	</style>

```
This places the overlay on top of the iframe, makes the text big, orange and slightly see through.


small_screenshot-2021-03-11-at-14-55-52.png

thumbnail_screenshot-2021-03-11-at-14-55-52.png

screenshot-2021-03-11-at-14-55-52.png

## Private video with a custom overlay

Now you have a custom live stream that cannot be shared. The watermark added to the video is unique for each viewer, which should prevent screenshot photos from the stream (or if there *are* leaks, you'll know who it was).


## Security

Sharing the video:  With our private tokens, sharing the live video is not possible.

Removing the watermark: There ARE workarounds that a technically savvy user might use to disable the CSS overlay. But for the vast majority of your users, this is unlikely to be an issue.  As in all issues of security, your team will have to weigh this possibility and decide if it is sufficiently secure to prevent leakage of your content.

## Conclusion

Private live streams are a great way to prevent the sharing of our sensitive videos. For an additional layer of security, you can add an overlay with CSS to identify each viewer’s screen - thus preventing screenshots being released from the presentation. Give it a try: [sign up](https://my.api.video) for your free account today!

medium_800px-cottonwoodparkfromfence.jpg

small_800px-cottonwoodparkfromfence.jpg

thumbnail_800px-cottonwoodparkfromfence.jpg

800px-cottonwoodparkfromfence.jpg

Secure live streams with unique overlay

Product updates

One of our most popular video on demand features is the ability to turn a video ‘private,' where each url to the video has a one time token to prevent sharing.  We have been asked many times about when the 'private' feature would be available for live streaming. We are very excited to release this as a new feature today!

When you set a video to private, the video link has a one use token connected to it. This token can be used exactly once (in a single web session). This means that the video cannot be shared, and any subsequent access of the url will throw an error. This also means that each time the video is shown, a new token must be requested from api.video via the [Get video](https://docs.api.video/reference/get-video) endpoint.

If you use the api.video player, this all works automatically. If you use a different player, we have a walkthrough of how you must handle the headers.


## Private Live streaming

Starting today, we now have a public attribute for all live streams. Setting this to 

```
"public": false
```

will add a token to each url for viewing.  With private live streams, you can be sure that your live video is not being shared outside your expected audience - perfect for live concert streaming, or classes.

Of course, just like the video on demand feature, you’ll need a new URL for the live video for each viewer.  When you call the [Get Livestream](https://docs.api.video/reference/get_live-streams-livestreamid) endpoint, each live for the m3u8, the player and the iframe will have the token attribute appended.

```
{
	"liveStreamId": "123",
	"createdAt": "2021-02-15T10:30:49+00:00",
	"updatedAt": "2021-02-15T10:30:49+00:00",
	"streamKey": "123",
	"name": "Dougs staging private livestream",
	"public": false,
	"record": false,
	"broadcasting": false,
	"assets": {
		"iframe": "<iframe src=\"https://embed.api.video/live/li4SB0HXeul4ITH5DXJFGPxT?token=4851b6b0-3c8a-4f15-8298-c2db754fa6ac\" width=\"100%\" height=\"100%\" frameborder=\"0\" scrolling=\"no\" allowfullscreen=\"true\"></iframe>",
		"player": "https://embed.api.video/live/li4SB0HXeul4ITH5DXJFGPxT?token=4851b6b0-3c8a-4f15-8298-c2db754fa6ac",
		"hls": "https://live.api.staging/private/4851b6b0-3c8a-4f15-8298-c2db754fa6ac/li4SB0HXeul4ITH5DXJFGPxT.m3u8",
		"thumbnail": "https://live.api.staging/private/4851b6b0-3c8a-4f15-8298-c2db754fa6ac/li4SB0HXeul4ITH5DXJFGPxT/thumbnail.jpg"
	}
}


```

## See it in action

### Why URL tokens?

Our video tokens are completely server side, removing the need for developers to do any security development (unless you are integrating with a 3rd party player).  The app makes an API call to the api.video server, receives the token, and can simply pass the value to their users.  

Once the token is used, api.video removes the token from being able to be used again.  As long as the user keeps their browser open, they can watch the video, but it cannot be shared, and if a new session is started, the user will need a new token.

### Saved private live streams

One of the great features of our live streams is the ability to have it available as recorded Video on Demand after the stream is completed. To enable this, the “record: true” setting must be enabled before the stream starts.

If your stream is set to private and set to record, all of the recorded videos will also be set to private - and will require the equivalent [private token](https://api.video/blog/product-updates/video-access-management-how-to-create-deliver-and-manage-private-videos-and-what/) for each view.

To make the example video above public, I had to update the video's setting to "public": true.


## Current Limitations

As we test and tweak private live streams, we want to keep the audiences lower. Please limit all private live streams to audiences of 3,000 viewers or less. For larger audiences - you can use a public live stream.

Later this year, we’ll be able to remove this cap, and allow for unlimited size of viewers for your private live stream.

[Give it a try](https://dashboard.api.video/register) - we'd love to see what you've built - share a link in our [forum](https://community.api.video)

small_258221048310c8d7478d1k.jpg

thumbnail_258221048310c8d7478d1k.jpg

258221048310c8d7478d1k.jpg

Private live streams

Private Videos

JavaScript

api.video offers a number of simple APIs to create and share video.  To protect videos from being shared, we offer the concept of private videos - where the ```public``` token for the video is set to ```false```.

These [private videos](https://api.video/blog/tutorials/tutorial-private-videos) have a URL token that can be used just once, and cannot be shared. To authenticate the token, we insert a custom header that must also be validated with the URL token.

If you use the api.video player - there is no development required - we do all the lifting of adding the authentication header for you.

If you are using a different player, you need to recieve this header from cdn.api.video and insert this header on each subsequent request.  To learn how, read on!

## Retrieving the header

For each unique view of a private video, you must generate a unique URL token.  It will look something like this:

>https://embed.api.video/vod/vitkytkieTnEvUjKE0VQpd2?token=c7cc5f68-1c98-49a0-a1c3-406e95d95228

Using Chrome DevTools, we can see what happens when we request this url:





large_picture-of-requests-in-chrome-devtools.png

medium_picture-of-requests-in-chrome-devtools.png

small_picture-of-requests-in-chrome-devtools.png

thumbnail_picture-of-requests-in-chrome-devtools.png

picture-of-requests-in-chrome-devtools.png

The 4th request is to cdn.api.video for the player.json.  The first request to this domain for a private video (either for the .mp4, the player.json, or the manifest.m3u8) will have a custom header in the response (```X-Token-Session```).


medium_x-token-session-in-headers.png

small_x-token-session-in-headers.png

thumbnail_x-token-session-in-headers.png

x-token-session-in-headers.png


This header and value must be sent on every subsequent request to cdn.api.video to ensure playback.

If you use the api.video player, each subsequent request has this header added  automatically.  For example, here is the request for the video thumbnail.jpg (in Safari, with a different session token):

request for the video thumbnail.jpg (in Safari)

large_request-for-the-video-thumbnail-jpg-in-safari.png

medium_request-for-the-video-thumbnail-jpg-in-safari.png

small_request-for-the-video-thumbnail-jpg-in-safari.png

thumbnail_request-for-the-video-thumbnail-jpg-in-safari.png

request-for-the-video-thumbnail-jpg-in-safari.png

At the bottom of the header list is the ```X-Token-Session```. 

## Using a different player

With a different video player, the code to insert this custom header must be added.  So lets walk through the steps to add a new request header in your code.

### Getting the session header

To retrieve the session header, simply request the first file from api.video (typically this is the m3u8 manifest file). It will look something like:

```
https://cdn.api.video/vod/vitkytkieTnEvUjKE0VQpd2/token/8e19097c-8310-4ce3-acba-206378119bc5/hls/manifest.m3u8
```

If you request this file from your player (or you can test just by loading this url in Safari), you'll receive the response with a lot of headers:

```
Timing-Allow-Origin: *
Cache-Control: no-store, no-store
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Content-Length: 590
Via: 1.1 PSfgblPAR2xf192:2 (W), 1.1 PSygldLON4zd14:8 (W), 1.1 PSygldLON2ew56:2 (W)
X-XSS-Protection: 1; mode=block, 1; mode=block
Date: Fri, 23 Oct 2020 10:02:57 GMT
Access-Control-Expose-Headers: Content-Type, Content-Length, Content-Range, X-Token-Session, Vary, Origin
X-Frame-Options: SAMEORIGIN, SAMEORIGIN
Access-Control-Allow-Credentials: true
Content-Type: application/vnd.apple.mpegurl
ETag: "5e8f75e8-24e"
X-Content-Type-Options: nosniff, nosniff
Last-Modified: Thu, 09 Apr 2020 19:22:16 GMT
x-proxy-cache: HIT
Server: PWS/8.3.1.0.8
x-ws-request-id: 5f92aa50_PSygldLON2ew56_14724-24181
x-token-session: 284a505f-d556-4de5-9498-c68260927551
x-px: ms PSygldLON2ew56LHR,ms PSygldLON4zd14LHR,ms PSfgblPAR2xf192CDG(origin)
```

Now we have the x-token-session for the playback of the video, and we must include this in each subsequent request.

### Minimal working example

The following piece of code shows how to retrieve the source file of a private video from a token value (error handling has been omitted for readability reasons).


## Adding the token to your header


Depending on the type of resource to retrieve, adding the X-Token-Session header may not be as straightforward as in the example above.

Below are some tips that you might find useful.

### Using MediaSource capabilities

If you manage the video tag yourself, you can use the [MediaSource interface](https://developer.mozilla.org/fr/docs/Web/API/MediaSource) to add headers to video files related requests.

### Using URL.createObjectURL() method

[URL.createObjectURL](https://developer.mozilla.org/fr/docs/Web/API/URL/createObjectURL) might be useful for some kinds of assets. For instance, you could display a video poster using an img tag with the following code:


### Using a service worker

[Service workers](https://developer.mozilla.org/fr/docs/Web/API/Service_Worker_API) can be used to intercept and modify any request made by your application and thus it gives you the ability to add headers. 


### Using video.js based players

If your player is based on [video.js player framework](https://videojs.com/), you can redefine the beforeRequest method on the xhr object of videojs.Hls . This will give you the ability to add the header on any video request. 


If you have any questions about this tutorial or would like to learn more about api.video please join our [community forum](https://community.api.video/). 

large_inserting-custom-headers.jpg

medium_inserting-custom-headers.jpg

small_inserting-custom-headers.jpg

thumbnail_inserting-custom-headers.jpg

inserting-custom-headers.jpg

Inserting custom headers

Featured article

# api.video blog

Blog

Follow the api.video Blog to explore tutorials, video use cases, and learn about on-demand and live-streaming video updates.