Video Player Sample

About

A Video Player Web App

The Video Player Sample is an open web platform video player web app built using the same architecture as the 60 Minutes and RedBull.tv apps in the Chrome Web Store. It can be customized, extended, or just used out of the box and populated with your own content.

Chrome Web Store

While the app was designed to run in all modern browsers, it really shines when setup as an app that is installed through the Chrome Web Store.

Browser Support

In addition to working as an app that can be installed through the Chrome Web Store, the Video Player Web App has been tested in:

Latest Safari

Latest Google Chrome

Firefox 4+

Internet Explorer 7+

Opera 11

This document is intended to provide a brief overview of the applications structure and capabilities, as well as information explaining how to populate, configure, and customize it to fit your needs.

See it in action

Architectural Overview

The following architectural overview covers the main structure of the application code and may be of interest to developers looking to study or extend the application’s functionality. If you’re keen to get started and simply wish to populate it with your own data and customize the appearance, please refer to the subsequent sections in this document.

The Google Video Application is built using the open source Google Closure JavaScript library and is compiled with the Closure Compiler. If you are not familiar with these tools, we recommend that you read the introductions and tutorials on their respective pages, in order to gain an understanding of the tools that underpin the application.

The structure of the application broadly follows the MVC (Model View Controller) pattern, meaning that the data populating the application lives within the model, visual aspects and user interactions are handled by the components in the view, and controllers are used to tell these components how to behave as well as usher data between them.

As mentioned above, the application consists of a series of interactive components, as well as controllers which govern sections of the application and the components nested within them. The controllers and components are embedded in index.html using data attributes. The attributes are recognized by the ControllerInitializer and ComponentInitializer, which then search for controller / component definitions matching the attribute values, before initialising them.

Each component has a context, being the block of HTML nested within the element specifying the component definition in it’s data attribute. The context is passed automatically to the component by the ComponentInitializer via the initialize method and allows the component to operate in the correct sandbox, controlling only the content and user interactions it is concerned with. Components can also expose APIs to allow controllers to govern how they behave and pass data from the models to them.

This process is initiated by the ApplicationController, which performs several tasks as the application starts. These tasks include, in this order:

Loading the configuration JSON file

Loading category and episode data from the location specified in the config file

Registering components via the ComponentInitializer

Registering controllers via the ControllerInitializer

Enabling deep linking and navigation via the History object

As the user navigates the application, tokens are passed to the History object, which stores the paths used to represent sections and subsections within the application. These changes are intercepted and handled by the ApplicationController which then searches all registered controllers for one matching the first segment of the new path. This is referred to internally as the slug and is specified in another data attribute in the HTML.

Once a section controller with the appropriate slug is found, any active controllers are disabled and the target controller enabled, thus handing control to the appropriate part of the application. If there are any addition segments in the path, these are then passed to the active controller, which will then in turn handle any sub tasks related to that data. For example, navigating to the following path /shows/example-category-1/ will activate the shows controller and tell it to do something with the example-category-1 segment. In this case, it would display a grid of all episodes belonging to that category.

For more detailed information concerning specific sections of the applications code, please refer to the code documentation.

Data Structure

The Google Video Application is configured and populated by two JSON (JavaScript Object Notation) files, config.json and data.json respectively; both of which are located in the data directory. The following structural outline explains which aspects of the application can be controlled by these files.

airdate: The air date of the episode, in a format recognized by the JavaScript Date.parse() method

runtime: The duration of the episode in the format HH:MM

video_html: A list of available HTML5 video formats, each specifying a path and a type

video_flash: The path to a video playable by the fallback Flash video player

The Google Video Application comes with several example categories and videos. Please study the existing JSON files for further clarification on how to use them.

Supported Video Formats

The various HTML5 video capable browsers each support different sets of video formats. It is therefore recommended that you provide videos in several formats, in order to support the highest possible amount of browsers and devices.

The Google Video Application supports the following video formats:

MP4: H.254 video with AAC audio

OGG/OGV: Theora video with Vorbis audio

WEBM: VP8 video with Vorbis audio

You need only provide paths to videos in these formats, the application will determine which type is supported by the user’s browser and whether or not the Flash fallback is required.

Setup

Server Setup

The Google Video Application should work well on most server configurations out of the box. However, if you experience problems playing certain video types, you may want to check whether your server is using the correct mime-types. The .htaccess file that comes with the application already defines these mime-types for use with APACHE servers, so in most cases you will not need to worry about setting this up.

Hosting on AppEngine

To host this project on Google's AppEngine, simply create a new AppEngine project that contains the deploy directory and the app.yaml file below.

Chrome Web Store

The Google Video Application was designed to provide additional features when installed through the Chrome
Web Store. For example, it can take advantage of background pages, allowing a script to periodically check whether new videos are available and notify the user via an HTML5 notification. This feature requires that the background.html page (and all linked resources) are hosted on a server which supports HTTPS (Hypertext Transfer Protocol Secure) connections. If you’re unsure whether your host supports HTTPS connections or how you can enable this feature, please contact your hosting administrator.

To learn more about publishing your app in the Chrome Web Store, check out the documentation, or follow the steps in this tutorial.

For an even easier experience, try AppMator, which will create all the necessary files for you in about 30 seconds!

manifest.json

A sample Chrome Web Store manifest file has been included below for your reference

Sample Videos

We've shipped three sample videos (in multiple formats) that you can use to try out this web application. Simply copy the files from /docs/samples/ to /deploy/data/

Customization

The core styles of the Google Video Application can be found within the css directory and control the layout and more generic aspects of the applications appearance. In most cases, you will probably not want to edit these styles and instead focus on customising the applications theme.

All files relating to this aspect of customisation can be found within the themes directory. Here you can change the colours of the application in styles.css and also find the sprites used throughout the application.

With a basic understanding of CSS, you can easily change the application colours. In order to edit the sprites, open the PSD file (sprites.psd) in the assets directory. Be sure to maintain the sprites position and boundaries and once you’re finished, hide the background layer and save the sprites over the existing sprites.png in the themes/os/img directory.

If you wish to develop multiple themes, you can create a duplicate of the os directory and rename it to reflect your project. You can then enable your theme by changing the stylesheet path in the head of index.html. Also be sure to change the path to your sprite sheet in your themes styles.css file.