High-level Steps and Server Architecture for XDR
Was this article helpful?
For security, you need a server to communicate with Ooyala's servers, rather than directly from your client application.
This topic provides 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.
|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:
||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: Getting the Playback Position Using the Backlot REST API|
|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|