Popular Searches:
Uploading, APIs, Creating Players, BEML
With the astonishing rise in mobile internet usage since the Apple iPhone was released in late-2007, people have been able to perform more and more of their normal online activities while on-the-go. For Brightcove publishers who wish to take advantage of the situation, there are numerous challenges to overcome, including formatting videos to work properly on the iPhone, and displaying a usable mobile site to users. Fortunately, with Brightcove 3, building a mobile video application to reach your viewers is straightforward. Please read on for a full sample with code to help get you started.
This article presents a sample app that delivers Brightcove video to an iPhone or iPod Touch. Here's a video demonstration of the app:
You can see the app on your iPhone at http://files.brightcove.com/dev/iPhone/index.html. You can also click here to see the functionality of this app, but be aware that it won't be formatted the same way on your desktop browser as it would be on an iPhone.
You can download a zip file of the app. It contains these files:
The video format supported by the iPhone is H.264. Brightcove 3 gives you the ability to upload one video file and store multiple renditions, or variously formatted versions, of the video. Creating a rendition that works on the iPhone is a now a simple process during upload. When you upload a video file using the Brightcove Studio, after opening the file browser and selecting a video, click Edit Settings at the bottom of the window. Choose H.264 as your rendition, as this is the video format supported by the iPhone. The video will now be placed into your Brightcove account as usual, but with additional H.264-encoded versions. Using H.264, you can delivery higher-quality video with less bandwidth than many alternative encodings, which makes it a good choice for mobile or more traditional delivery methods. Read more about H.264.
The approach we're using in this example works with progressive download videos; it won't work with streaming (FMS) videos.
One often overlooked aspect of the mobile web, especially on a device as cutting-edge as the iPhone, is the design. Text and buttons need to be larger to be easily read and tapped, while images should generally be kept on the smaller side to avoid slow-loading pages over a cellular network. You and your design team should review the Apple Developer Connection, which has dozens of pages filled with tips and guidelines on optimizing your content for mobile web applications.
If you take a quick look at the HTML code provided in this example (index.html in the zip file) you'll see that it's a fairly simple page. Of special note are the unique iPhone meta tags, seen below, which set a default viewport (see Apple Developer Connection), allow the page to be run as a web application, set the status bar to black, and provide an icon for when a user bookmarks the site.
<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" /> <meta name="apple-mobile-web-app-capable" content="yes" /> <meta name="apple-mobile-web-app-status-bar-style" content="black" /> <link rel="apple-touch-icon" href="icon.png" />
We then have a header bar, a navigation bar, a content container, and a footer. Within the content container you'll notice that we have three different containers: one for the home page, one for playlists, and one for videos. By doing this we can simply hide or display the containers when we don't need them, and sometimes this allows us to avoid an API call that adds unnecessarily to load times.
If you've done any work with the Brightcove API up to this point you probably won't see anything too shocking in the JavaScript (main.js in the zip file). When a user selects a video section, such as "Channels", we make a call to the viewPlaylists() function. We display a loading icon, put together our API command, and fire off a call to Brightcove with our request. After receiving the data we handle our navigation items to show the currently displayed page, show the correct content container while hiding the others, and populate our container with the playlists.
You may notice that the Brightcove API also returned all of the Video DTOs for each playlist with our initial call, so when a viewer selects a playlist, we simply refer to the JSON object we received from our API call. We just run through each video and output the data we want to show when the viewer chooses one. Since we want to get the actual video files from the Video DTOs (using the FLVURL field), we need to use the special Media API read token, as described in the Accessing Video Content with the Media API help topic.
As mentioned earlier, by just hiding and showing the content containers we can save ourselves some hassle. Now that the viewer is looking at a list of videos, let's say they want to go back to the "Channels" page. Rather than having to re-send our API call, we can easily hide the video content container and re-display the playlist container; this approach makes for a much quicker, smoother, and more efficient navigation.
Because the iPhone mobile web is still in it's infancy, there are hundreds of undiscovered user interaction techniques. With support for things like CSS animation and transitions, you could slide pages in and out to mimic the normal behavior of the device, and a built-in JavaScript API allows you to track touches and gestures just like the on-deck applications. Using these pieces together you could even allow users to swipe across the screen to change between pages. I suggest you take a good look at any and all available documentation and demos to see what unique experiences you can offer to your mobile users.