Blog Archives: August 2011
HD Video Everywhere!
by Jeroen Wijering on 2011-08-24 02:05
These days, HD quality video is no longer an option - it is essentially a requirement. On the other hand, there are still quite a few viewers out there that are unable to play high quality video, due to connection or device constraints. A simple way to fix this is by offering an HD toggle in your player. Viewers that want the full experience select the high quality option, while viewers that don't have the capabilities (or interest) select the low quality option.
With a combination of some thoughtful encoding and the HD plugin for JW Player, creating such a setup is very easy. This post explains how to encode for and embed a player with an HD toggle that works on the desktop, as well as on the Android, iPad and iPhone. We'll even discuss how to support HTML5 everywhere by including a WebM HD toggle.
HD video on Chrome/Windows, the iPhone an Firefox/Mac.
Encoding
First, we have to render two versions of our video: an HD one and a lower quality one. Since the iPad, the latest iPhones and Android flagships - like the HTC Desire and Samsung Galaxy S - all play 720p video, let's use that as the HD version. Full HD (1080p) is still a bit overkill, in my opinion.
For the lower quality version, it's best to stick to settings that older phones such as the iPhone 2G/3G, HTC Legend and Motorola Droid can play. For example, 270p will work fine. At this size, we can also have the video play without stutter over a 3G connection. Plus, even those rusty 5-year old laptops should be able to play the clip.
Here's a quick overview of the main encoding parameters for our video. For more details on the encoding side, check a previous blog post about supporting mobile video on your site.
| HD version | SD version | |
| Container format | MP4 | MP4 |
| Video format | H.264, Main profile | H.264, Baseline profile |
| Video dimensions | 1280x720 pixels | 480x270pixels |
| Video bitrate | about 2000kbps | about 500kbps |
| Audio format | AAC, Low Complexity | AAC, Low Complexity |
| Audio frequency | 44.1 kHz, stereo | 44.1 kHz, stereo |
| Audio bitrate | 96 kbps | 64 kbps |
Embedding
With the two versions of our video encoded, let's move on to embedding. In addition to the two MP4 files, you must also upload jwplayer.min.js and player.swf (available on the JW Player download page), as well as a nice still image (JPG) from your video. Note: we recommended the JPG as the video image - just for good looks. Next, include the player in the <head> of your HTML page:
<script type="text/javascript" src="http://example.com/jwplayer/jwplayer.min.js"></script>
With the player included, move on to place the actual embed code:
<div id="container">HD video coming up!</div>
<script>
var options = {
file: "/assets/video-270p.mp4",
height: 270,
modes: [
{ type: "html5" },
{ type: "flash", "src:/jwplayer/player.swf" }
],
plugins: {
hd: { file: "/assets/video-720p.mp4" }
},
width: 480
};
jwplayer("container").setup(options);
</script>
With this setup, the player is setup into the <div> when the page loads. The 270p video is loaded into the player by default. The HD plugin is used to offer a toggle to the 720p video. This toggle is:
- Displayed as a button in the top-right of the video on desktop browsers. Viewers can click the button to enable and disable the HD version.
- Displayed as two big buttons in the middle of the video on Android and iOS. On their small touch screens, viewers can easily see and click these buttons.
WebM Support
Note the modes block in the above embed code define which playback mode is used first: Flash or HTML5. In this case, HTML5 is used first, because it enables the video to resume after doing an HD toggle. When clicking the HD toggle in Flash, the video will re-play from the beginning.
Unfortunately, not all HTML5 browsers (Firefox / Chrome † ) support the MP4 files we use. The player will therefore fallback to Flash. In order to profit from HTML5 playback in these browsers too, you should do two additional WebM encodes of your original video. You can use the same dimensions and bitrates as for an MP4.
On the embedding side, we add one small check. In between defining the options and setting up the player, we sniff if the browser is able to play WebM video. If so, we swap out the MP4 files for WebM ones:
...
width: 480
};
if(!!document.createElement('video').canPlayType('video/webm')) {
options.file = '/assets/video-270p.webm';
options.plugins.hd.file = '/assets/video-720p.webm';
}
jwplayer("container").setup(options);
</script>
Now you're all set! Glorious HD video in HTML5 mode, on every browser and device that matters. Check out the live example:
example
† Though Chrome announced they would drop MP4 support last year, it is still working in the current version (Chrome 14).
Optimize Your Video for Mobile Playback
by Jeroen Wijering on 2011-08-12 10:24
With the Android and iOS platforms growing like weeds, online publishers are scrambling to mobilize their video players and profit from these additional viewers. Since Apple’s iOS doesn't run Flash, most of these publishers turn to the HTML5 <video> tag for delivering their clips to mobile devices.
While this is a critical first step (better to have your videos play than not), it is also just the start. The mobile user experience (UX) model is vastly different from that of the desktop computer, which means additional work is needed in areas such as interface, streaming and advertising. These UX differences have several implications for video players.
Touch Versus Mouse
The most obvious difference is user input. A mouse controls video players on the desktop, whereas both iOS and Android rely on capacitive screens which users touch with their fingers. Since a fingertip is both bigger and harder to position than a mouse cursor, buttons on mobile video players must be larger than their desktop equivalents.
When using a mouse, there is the so-called "mouse-over" state: the mouse is positioned over a button, but not clicked. Some video players rely on this state to pop up a volume slider or selection menu. This state is not available on touch devices, so mobile players can not rely on it.
On the other hand, touch devices do allow users to control applications by sliding one or more fingers across the screen. This type of interaction (found in features like gestures and multi-touch) is relatively new and still unexplored, but could become widely used over time. Some basic gestures, like sliding over a webpage or playlist to scroll, are already widely accepted and can be used today.
Full-screen Versus Windowed
Another key differentiation is screen size. Mobile screens are 3 or 4 inches in diameter, which is a big difference from 14-inch laptops or 20-inch desktop monitors. Therefore, on both Android and iPhone, videos are always played back in full-screen, instead of inside an HTML page. This means that visual interaction with other parts of the page - including companion ads that pop up - is lost on mobile devices. Publishers should not rely on this advertising model.
In this full-screen mode, both Android and iOS expose only system-provided video controls (pause, seeking). Important online video components such as share buttons and overlay ads are simply not possible. Therefore, any custom controls or graphics are best displayed before the video is started and/or after it has ended.
On-The-Go Versus At-The-Desk
Mobile devices are indeed frequently used on-the-go, meaning their internet connection may be poor and unreliable. The connection speed can change dramatically, even within a single video playback session if a user switches from 3G to WiFi. Therefore, iOS devices support a specific type of video streaming that continuously adapts the video quality to the available bandwidth connection: HTTP Live Streaming. It is highly recommended to use this functionality for mobile video playback.
Unfortunately, Android only supports this type of streaming as of version 3.0. To ensure optimal video quality, players can offer an up-front video quality selection. As Android manufacturers migrate from the 2.x to the 3.x platform, HTTP Live Streaming can, and should, replace this manual quality selector.
One nice additional touch is a "watch later" feature in mobile players. Users who are casually browsing while waiting somewhere can tag a video and forget about it. The publisher can then remind the user about the video at a later point. Publishers can implement “watch later” functionality using cookies, log-ins or one of the emerging services dedicated to this functionality.
Conclusion
In sum, the vast differences between desktops/laptops and mobile devices require a major redesign of existing video players. But things don't stop at the player. The surrounding website needs optimization as well, with less content, less sidebars, less clutter and more focus on the video itself.
Mobilizing your video is not about swapping Flash for HTML5. It is about adapting your content to the device and facilitating a different type of user experience. Mobile video consumption is exploding, but it’s also still evolving, as are the platforms that serve this content to consumers. By going above and beyond the bare minimum now, you’ll be well positioned as mobile continues to explode.
As developers of one of the most widely used online video players, we constantly strive to provide optimal playback experience for our users. As we move towards the future generations of the JW Player, stay tuned for more and more exciting UI and UX improvements.
Follow us on Twitter: 