High-level Steps and Server Architecture for XDR

For security, you need a server to communicate with Ooyala's servers, rather than directly from your client application.

This section is a high-level architectural overview to implement cross-device resume (XDR). This architecture applies to XDR for both the desktop and the Ooyala Mobile SDKs.

As a viewer watches a video, Ooyala video players continuously record the playhead position of a video being watched. (Custom players also must record this position.) XDR involves securely retrieving this recorded playhead position and resuming the video at that position. This is accomplished through the interworking of several Ooyala components, including two REST-based APIs and standard Player V3 JavaScript or the Ooyala Mobile SDK for iOS or for Android.

A key assumption of this architecture is that you have a customer portal or site that authenticates your viewers by way of login to ensure that they have rights to view your content. Another security concern requires that you have an intermediate server or service between your client and Ooyala's services. The reason is that the REST API request to retrieve playback position must be signed by your Ooyala-provided provider code (sometimes called "pcode"), API key and secret (for details, see Your API Credentials); these must not be embedded in your application itself.
The following are the general steps.
Step Purpose More Documentation
1. Your logged-in, authenticated viewer requests to resume playback of a video by way of a call to your intermediate services. This call should include:
  • The viewer's account identifier (account_id)
  • The embed code (video or asset ID) of the desired content
This is part of your own implementation.
2. Your intermediate service obtains the last recorded playhead position with a signed request to the REST-over-HTTP API https://api.ooyala.com/v2/cross_device_resume, passing in the account_id and the embed code from Step 1.

The response includes the last playhead position for the account for the desired video. Your intermediate server must retain this value for use in Step 4.

Cross-Device Resume: Playback Position
3. The intermediate service formats an Ooyala Player Token (OPT) request string (including the account_id and embed code) to give back to the client application. You do not actually make the request here; you format the request so that it can be made by the viewer's device in Step 5.

Steps 2 and 3 can be done in any sequence.

Constructing the URL Token Request
4. Your intermediate service returns the last playhead position from Step 2 and the formatted OPT string from Step 3 to the viewer's device. This is part of your own implementation.
5. On the device, when the video player is instantiated, it is passed both the playhead position from Step 2 and the OPT string from Step 3. Authorization is validated, and if successful, playback resumes at the passed-in position. Resuming Playback in Your Application

Was this article helpful?