Brightcove Player Sample: Kiosk App

Player example

The player will be playing a video from the array of video objects in an infinite loop.

See the Pen 18186-kiosk-app by Brightcove Learning Services (@rcrooks1969) on CodePen.

Source code

View the complete solution on GitHub.

Using the CodePen

Here are some tips to effectively use the above CodePen:

  • Toggle the actual display of the player by clicking the Result button.
  • Click the HTML/CSS/JS buttons to display ONE of the code types.
  • Later in this document the logic, flow and styling used in the application will be discussed in the Player/HTML configuration, Application flow and Application styling sections. The best way to follow along with the information in those sections is to:
    1. Click the EDIT ON CODEPEN button in the CodePen and have the code available in one browser/browser tab.
    2. In CodePen, adjust what code you want displayed. You can change the width of different code sections within CodePen.
    3. View the Player/HTML configuration, Application flow and/or Application styling sections in another browser/browser tab. You will now be able to follow the code explanations and at the same time view the code.

Development sequence

Here is the recommended development sequence:

  1. Use the In-Page embed player implementation to test the functionality of your player, plugin and CSS (if CSS is needed)
  2. Put the plugin's JavaScript and CSS into separate files for local testing
  3. Deploy the plugin code and CSS to your server once you have worked out any errors
  4. Use Studio to add the plugin and CSS to your player
  5. Replace the In-Page embed player implementation if you determine that the iframe implementation is a better fit (detailed in next section)

For details about these steps, review the Step-by-Step: Plugin Development guide.

iframe or In-Page embed

When developing enhancements for the Brightcove Player you will need to decide if the code is a best fit for the iframe or In-Page embed implementation. The best practice recommendation is to build a plugin for use with an iframe implementation. The advantages of using the iframe player are:

  • No collisions with existing JavaScript and/or CSS
  • Automatically responsive
  • The iframe eases use in social media apps (or whenever the video will need to "travel" into other apps)

Although integrating the In-Page embed player can be more complex, there are times when you will plan your code around that implementation. To generalize, this approach is best when the containing page needs to communicate to the player. Specifically, here are some examples:

  • Code in the containing page needs to listen for and act on player events
  • The player uses styles from the containing page
  • The iframe will cause app logic to fail, like a redirect from the containing page

Even if your final implementation does not use the iframe code, you can still use the In-Page embed code with a plugin for your JavaScript and a separate file for your CSS. This encapsulates your logic so that you can easily use it in multiple players.

API/Plugin resources used

API Methods
play()
catalog.getVideo()
catalog.load()
on()

Get credentials

To use the CMS API you will need proper credentials.

The easiest way to get credentials in most cases is through the Studio Admin API Authentication section (requires admin permissions on your account). See Managing API Authentication Credentials for details. In most cases, you probably just want to get permissions for all CMS API operation:

CMS API Permissions
CMS API Permissions

If the permissions you need are not available in Studio, or if you prefer to get them directly from the OAuth API, use your choice of the Get Client Credentials documents listed below. Whichever option you choose, you will need to ask for the correct operation permissions. The following can be used with cURL or Postman to get all permissions for the CMS API:

	"operations": [
	  "video-cloud/video/all",
	  "video-cloud/playlist/all",
	  "video-cloud/sharing-relationships/all",
	  "video-cloud/notifications/all"
	]

Player/HTML configuration

This section details any special configuration needed during player creation. In addition, other HTML elements that must be added to the page, beyond the in-page embed player implementation code, are described.

Player configuration

No special configuration is required for the Brightcove Player you create for this sample.

Other HTML

No other HTML elements are added to the page.

Application flow

The basic logic behind this application is:

  • Use the CMS API to get a total count of videos in the targeted account.
  • Since it is a best practice to retrieve information for no more than 25 videos at a time (the CMS API does NOT return video objects, but information on the videos), calculate the number of calls needed from the total count.
  • On retrieving the information for 25 videos, extract the IDs and then use the Video Cloud catalog to retrieve the video objects.
  • Once all the video objects are returned, play the first video.
  • When a video ends, play the next video.
  • When the last video plays, start from the beginning of the list again.

More details are added in this description:

  1. Prepare to make the call to the CMS API that returns the count of total videos in the account.
  2. Make the actual request using the CMS API for the count. This step will use a callback function, which means the callback function is passed as a parameter to another, second, function. The callback function is then called inside the second function's logic. In this case the callback function simply extracts the count property from an object returned by the CMS API.
  3. Determine the number of calls needed to the CMS API to retrieve all the videos. This code follows the best practice of asking for 25 videos per call. This is done by dividing the count of all the videos by 25.
  4. Create a do-while loop that iterates for the required number of calls determined in the previous step. This loop must be in the callback function of the request for the video count.
  5. In the loop, prepare to make the call to the CMS API that will return 25 videos from the account.
  6. Still in the loop, make the actual request using the CMS API for the video data. This step will use a callback function, which means the callback function is passed as a parameter to another, second, function. The callback function is then called inside the second function's logic. In this case the callback function will perform these tasks:
    • Extract data to build an array of video IDs for the returned video information.
    • The array of video IDs is then passed as a parameter to another function which retrieves the complete video object for each ID. The returned objects are stored in an array of all video objects. A callback function is used in this step also.
    • Check when all videos are returned (when the number of returned videos matches the previously returned count). When the condition is met, call a function that plays the first video in the array (zeroth element).
  7. Setup an event listener to listen for the ended event. When each video ends play the next video, or if it is the last video in the array, play the first video.

Request the video count from the CMS API

Find the code which is labeled:

	// ### Setup for video count CMS API request ###

The first call to the getCMSAPIData() is for the total count of videos. Note the in the callback function there is another call to the function inside of the do-while loop.

Play next video on end of a video playing

Find the code which is labeled:

	// ### Get next video ###

Uses the on('ended',...) logic to play the next video in the list. Note the currentlyPlayingIndex tracks the videos playing.

Retrieve data with the CMS API

Find the code which is labeled:

	// ### Standard functionality for CSM API call ###

This is standard code discussed in the Learning Guide: Using the REST APIs document.

Extract video IDs and retrieve video objects

Find the code which is labeled:

	// ### Extract video IDs ###

This series of functions takes the returned video information, extracts the IDs, then uses the CMS API to retrieve video objects needed for the player to actually playback the video content.

Application styling

The only CSS sizes the player.

Plugin code

Normally when converting the JavaScript into a Brightcove Player plugin nominal changes are needed. One required change is to replace the standard use of the ready() method with the code that defines a plugin.

Here is the very commonly used start to JavaScript code that will work with the player:

videojs.getPlayer('myPlayerID').ready(function() {
  var myPlayer = this;
  ...
});

You will change the first line to use the standard syntax to start a Brightcove Player plugin:

videojs.registerPlugin('pluginName', function(options) {
  var myPlayer = this;
  ...
});

As mentioned earlier, you can see the plugin's JavaScript code in this document's corresponding GitHub repo: kiosk-app.js.

Using the plugin with a player

Once you have the plugin's CSS and JavaScript files stored in an Internet accessible location, you can use the plugin with a player. In Studio's PLAYERS module you can choose a player, then in the PLUGINS section add the URLs to the CSS and JavaScript files, and also add the Name and Options, if options are needed.

Proxy code

In order to build your own version the sample app on this page, you must create and host your own proxy. (The proxies used by Brightcove Learning Services only accept requests from Brightcove domains.) A sample proxy, very similar to the one we use, but without the checks that block requests from non-Brightcove domains, can be found in this GitHub repository. You will also find basic instructions for using it there, and a more elaborate guide to building apps around the proxy in Using the REST APIs.