Having multiple videos on the same page

TLDR: We do not recommend having multiple videos embedded on the same page. Doing so can result in “device incompatible” error message on the player. Keep dedicated pages on your website for each video, or at least make a UX that keeps only one player loaded at a time.

What causes the error

Under the hood, there are big differences between a regular HTML5 video element and another one running with DRM. Playing a DRM encrypted video takes a few extra steps inside the browser and the operating system. It is supposed to decrypt the video while it is getting rendered by the browser. All the while ensuring that the raw video bytes are not available to the user-land at any time.

This process can be complicated because it involves making use of specialised provisions inside the computer. One such component is the trusted execution environment (TEE) on the processor itself. There are such limited and specialised resources in use from both hardware and software levels. The security level requested by the player and the security levels available on the device decides which exact components will be used.

Having multiple videos on the page will mean a number of these resources will get exhausted. Given that our scripts are inside an iframe, the player is unable to know count of other videos on the same page. The browser does not have a clear API about why exactly the DRM APIs failed. All this means, that the error from player is indistinguishable from the error when the device is actually incompatible to play DRM.

Load times vs data conservation

When loading a video player, and before the user has clicked the video, we have two choices.

1. We can either just show a poster image, a play button, and wait for the user to click; or
2. We can also create the video element, do the license verification and load a bit of the starting video in the background.

In the first scenario, the time-to-play-after-click will be huge. It can be anywhere from 2 to 10 seconds before the video starts playing even on a good connection. While in the second scenario, the time-to-play-after-click will be almost zero. The moment click event is captured, the video will start playing.

For the default player, we have decided to go with the second option because we believe that in most cases, especially in an encrypted video, the video will be the primary content of the page and it should have a good experience.

What happens when too many videos

Note that reducing this load time means that the secure key-exchange will happen before the click. This means that a video player loaded on the web page will have an active DRM session. This is one of the limited resources that we had talked about earlier. When another video is loaded on the page, it cannot open an active DRM session and shows an error message about incompatibility.

Getting error even with single video

Some android devices have reported getting stuck when the webpage tries to play multiple videos simultaneously. After such a page is loaded, it seems the internal resources are not automatically released. If this happens, you might see error messages when playing even regular videos on this device. One way to fix this issue is to restart the device. Hence, if a user reports having device compatibility errors, it is useful to ask them to restart their device. If the problem will be coming from having unreleased DRM sessions, then this can fix the problem. Information to identify such behaviour is not available via any APIs from the browser and therefore, it is difficult to track and show the appropriate error message when this happens.

Using Modals if you need to have multiple videos

The following solution require programming skills to implement. If you are not a developer, share this article with a developer to get this implemented.

Instead of loading the video player itself, you can show a poster image of the video, and a simple play button on top. Add a click listener to open a pop-up modal. The video player will be part of the modal contents. When the modal loads in DOM, the player is also loaded.
If you use this method, it is recommended to keep the poster image in your database to make this process easier.

Beware the preloaded-modal libraries

Note that if you use any of the modal libraries, there are two kinds of pop-ups. Some modals will load the modal/pop-up when the page loads. Showing that modal will just toggle the display and/or position properties of the modal to show it. Other kinds of modal will not keep the modal contents in the DOM. When the modal is shown, the DOM is injected into the modal container and it appears on the page. Let’s call this preloaded modals and just-in-time modals.

Preloaded modals can be quick to display because its contents (be it iframe, scripts or images) have been pulled from the network and loaded into the DOM. They were just kept hidden. However, if you have many such modals or the contents of those modals consume significant network resources, such as videos, preloaded modals can drain your users’ network bandwidth and cause the page to slow-down. Therefore, ensure that the modals you are using are NOT preloaded. You can check whether they are preloaded by looking at the browser’s dev-tools (network panel). Note the total bytes transferred after the page is reloaded. If the page is transferring multiple MBs of data just to reload, the popups might be loading their contents in the background.

Recommendations

We wish we could have the above workaround on the player itself to make this easy. However, having such interactive elements via an embed code while ensuring that there are no CSS conflicts can not be applied universally. Our best recommendation therefore is to implement such workarounds yourself, or just keep each video on a dedicated page.