Blog Archives: February 2012
HTML5 Takes the Lead on Android Devices
by Pablo Schklowsky on February 28, 2012
Even before Adobe's announcement back in November that it would cease supporting Flash on Android devices, it was becoming clear to us at LongTail Video that the JW Player would need to shift its focus on Android devices towards HTML5 mode. We took the first step with the release of the 5.9 player, which now embeds itself in HTML5 mode on all Android devices by default, since our testing has shown that Android is fully capable of playing HTML5 video. But there are several reasons why HTML5 should be the delivery mode of choice on Android, with or without Flash. This blog post will attempt to address a few of them.
Limited Future Support for Flash
This one should be obvious, so we'll get it out of the way. After the current generation of Android devices running Froyo (2.2), Gingerbread (2.3), Honeycomb (3.x) and Ice Cream Sandwich (4.0) are either phased out or upgraded to future Android versions, Flash will no longer be supported in the browser.
Video Player Behavior on Mobile Devices
It is difficult to put forth a general rule for how video players should behave on mobile platforms. In fact, the term "mobile" is itself too general in this context, since viewing a web page containing video is a very different experience depending on whether you are viewing on a smartphone with limited screen real estate, versus watching on a tablet with more room for your fingers to interact with the content.
If you load the JW Player on an Android smartphone in Flash mode, you will get the same version of the player you would have gotten had you loaded it on a desktop browser. However, everything will be scaled to the size of your phone's screen, including all of the button controls. Not only would the buttons be hard to press, but they wouldn't really make sense in the context of watching video on a phone. Conversely, the player's HTML5 mode relies on the phone's own built-in video controls, which are optimized for the screen size. Additionally, HTML5 video will always play in full-screen mode on Android smartphones, which is a much better experience.
Viewing video in a browser on a tablet isn't as cut-and-dry of an issue. The screen is larger, so it is possible to have a usable video playing inside of the page content. This can be done in both Flash and HTML5 modes, so the decision of which to use comes down to performance (despite its reputation, Flash doesn't perform that poorly on most Android devices when it comes to video) and usability (the built-in HTML5 controls are optimized for touchscreens, while the Flash controls would need to be modified to work well on touch devices).
Lastly, we feel that it is important to provide a consistent experience across all mobile devices, not just Android devices. Switching to HTML5 playback for Android means that users on both Android and iOS devices will see the same things:
- Fullscreen-only playback (on phones)
- No overlays on top of the video player while a video is playing
- Built-in touch screen controls
Flash Embedding on Mobile Browsers
One issue we've noticed with Flash for Android is that it "steals" interaction events from the browser. For example, if you're scrolling down a page using the one-finger swipe gesture, and your finger happens to brush over a Flash element on the page, Flash will interpret this as a mouse click. In the case of the JW Player, the player will begin to play, when what you actually wanted to do was scroll down the page. Using native HTML5 elements eliminates this sort of behavior, since those elements distinguish between different types of gestures.
HTTP Live Streaming (HLS)
Beginning with Ice Cream Sandwich, Android devices will support HTTP Live Streaming (HLS), which has become the de facto standard for streaming video over HTTP. This is the same format which is used to stream video content to iOS devices. Unfortunately, HLS is not supported natively in the Flash player, making this another reason to favor HTML5 over Flash on Android. For an explanation of what HLS is and why it's important, check out our blog post on the subject.
Android Support in the JW Player Going Forward
For all of the reasons described above, we feel that it is necessary to focus our Android development efforts on HTML5 and not Flash. Flash mode will still be used as a failover on Android devices which support it; for example, if your player configuration specifies an RTMP stream (which can't be played in HTML5 mode), the Flash player will still be used. And if you disagree with our decision, you can still specify Flash as your primary renderer by setting the modes block in your player configuration. But we think you'll find that for Android, HTML5 is the best way to go.
HTML5 Video Ads: Coming To a Mobile Device Near You
by Pablo Schklowsky on February 21, 2012
As HTML5 grows its share of the online video market, web video publishers are beginning to look for ways to monetize videos being played outside of the traditional Flash advertising methods. But when someone watches a video in HTML5 mode, what should that experience be like? What's possible, given the current state of the tech?
HTML5: Desktop vs. Mobile
Before we begin talking about the challenges that face HTML5 video ads, it's valuable to acknowledge that video in HTML5 can behave very differently on the desktop compared to the same HTML code running on mobile devices. Here are some of the primary differences:
| HTML5 Desktop | HTML5 Smartphone | HTML5 Tablet | |
|---|---|---|---|
| Clickable Overlays | Yes | No | Depends* |
| Clickable Video | Yes | No | Depends* |
| Companion Ads | Yes | Not visible | Yes |
| Fullscreen mode | Optional | Always | Optional |
| Customizable controls | Yes | No | Yes |
| Available Bandwidth (probable) | LAN/WAN | 3G/4G/WAN | 3G/4G/WAN |
* Platform-specific
As you can see from the table above, some concepts that advertisers take for granted, such as video ads which cause a web page to be displayed when clicked, are not possible on smartphones. For example, on most mobile devices, once an HTML5 video begins playing, whether it's an ad or not, the phone will enter fullscreen video playback mode. In this mode, the user has full control over the playing video, including the ability to seek to the end of it.
Technical Challenges
As the major ad networks are beginning to offer support for HTML5 video ads, they face several important challenges.
Video Codec Incompatibility (WebM vs. MP4)
One issue which HTML5 video publishers are already familiar with is that to support all platforms, video must be encoded into multiple formats — WebM (or Ogg Theora) for Firefox, and H.264 for everything else. Second, someone (whether the browser, ad network, video player, or publisher) will need to select the appropriate format and display it to the user. This can be difficult to implement in an ad scenario, especially if ad networks don't account for the user's browser when generating an ad response.
Crossdomain Issues
An additional technical concern is that loading external assets (a VAST XML response from an ad server, for example) brings with it certain restrictions in JavaScript. These restrictions need to be worked around on the server hosting those assets.
<Video> Tag Access
Depending on the implementation, most ad networks require direct access to the player's <video> tag in order to play an ad in HTML5. This makes sense, considering that in iOS, each distinct <video> tag placed on a page needs to be clicked by the user in order for the video to be played. If the ad were to be played in a new <video> tag which was placed on top of the player, the user would need to click "play" twice - once for the ad and another time to watch the main video. This presents some interesting problems. While the ad is playing, the player needs to treat the events flowing from the <video> tag differently than if the main video were playing. After the ad has played, the video tag needs to be restored to its original state (the video playing, its position, etc).
Industry Roundup
Considering the relative newness of HTML5 video (and the challenges listed above), it's unsurprising that not many video ad networks have implemented full HTML5 support yet. That being said, there are a few ad networks who have made some progress on this front:
- Google recently released HTML5 support in their Interactive Media Ads (IMA) product. This implementation allows publishers to set up VAST ads, with certain limitations based on device compatibility. The JW Player's Google IMA Plugin includes beta support for HTML5 mode.
- YuMe has been steadily improving their HTML5 support, which is now supported in the JW Player's HTML5 mode via the YuMe plugin.
- Most other video ad networks (Tremor, SpotXchange, BrightRoll, and others) have either announced, or are currently implementing support for mobile devices, which will mean HTML5-compatible ad media.
Future Considerations
As in Flash, as more publishers attempt to handle more sophisticated scenarios, new techniques must be devised to handle them. Dynamic bitrate switching, for example, allows publishers make on-the-fly optimizations for video ads based on screen resolution and available bandwidth. Apple HLS (HTTP Live Streaming) is on its way to becoming the standard streaming format on mobile devices — with competition coming in the form of MPEG DASH, which was ratified as an ISO standard last week. Both HLS and DASH are based around the idea of a manifest file, which keeps track of smaller chunks of video that can be stitched together into a single seamless video. To insert an ad into this stream can be as simple as adding the ad chunks inside of the manifest file at the appropriate times, a technique known as dynamic ad insertion. A more general optmization we'll be moving towards is ad delivery which is optimized for variable-bandwidth environments, as many mobile users are viewing content over slower wireless networks.
In short, we're still a long way from having a turnkey video advertising solution for all HTML5 viewers, but we're closer than ever before to achieving that goal.
Using Closed Captions for Online Video
by Meagan Palatino on February 13, 2012
Web video accessibility is a broad term that refers to making videos usable for all types of viewers. Traditionally, it refers to those with impairments, but more recently the definition has broadened. At LongTail Video, we feel strongly about creating the means of equal access to online video content. By building products that support features such as multi-language video captions, we aim to increase viewer accessibility. Though there are many pieces to making a video fully accessible, in this post we focus the discussion on closed captions.
Understanding Video Captions
Video captions are very similar to subtitles. The major difference is that captions describe all of the relevant audio detected in the video, whereas subtitles focus solely on the words spoken in the film. For example, if a phone is ringing in the background a caption will display something like, "the phone is ringing", and a subtitle will display nothing. Captions are "closed" when a user can toggle the captions on/off during video playback. Captions are "open" when they are burned directly into the video, which means they are displayed 100% of the time. Making sure your captions are closed is important - it allows you to support all types of users with the same piece of media, increasing both accessibility & inclusiveness.
The Current State of Video Captions
Captions have conventionally existed for television, but only more recently have been introduced into online video. Although The World Wide Web consortium (W3C) has established a set of guidelines known as Web Content Accessibility Guidelines that provide a standardized and definitive set of rules for how to develop accessible online content, online video accessibility federal regulations are still in their infancy.
Since 2010, American accessibility advocates have urged Congress to modify an existing bill that would mandate captions for any online video that has also appeared on TV. Just last month, the Federal Communications Commission (FCC) released their final rules on closed captioning for IP-delivered video programming. Though only a small step towards a more universal regulation, it applies to all full-length video television programming in the United States, previously distributed with closed captions.
As closed-captioning of online video programming emerges, speed of adoption is key. Whitehouse.gov is an early adopter who uses the JW Player with our Captions Plugin to display their cataloged live broadcasting footage.
Hulu's CTO, Eric Feng quotes that “users send us feedback about closed captions more often than almost any other feature, so what started as a small side project has turned into a very important part of our user experience...”.
Video Captioning Tools
In our own product development at LongTail Video, we see similar requests, and have recently pushed two product updates for online video captioning:
- Bits on the Run Video Captioning - we now allow users to upload captions in the SRT and DFXP formats to the Bits on the Run Dashboard. Users can then publish their videos with closed captions for accessibility and Section 508 compliance. In addition, videos can now be published with multiple subtitle tracks, for viewers language selection.
- JW Player Captions Plugin for HTML5 - we recently updated our Captions Plugin to support both Flash and HTML5 mode. This means closed captions will now appear in both the Flash and HTML5 rendering mode for videos embedded with the Captions Plugin.
Aligning with the trends in industry, the tools in which closed captions are created have improved as well. Services such as Subtitle Workshop and Jubler are offline tools used to edit text-based subtitles, or in our case, closed captions. Online services that we recommend are Universal Subtitle and our partner, dotSUB.
Added Benefits of Video Captioning
What video publishers may not yet realize is that there is more to captioning videos than simply increasing accessibility among the hearing-impaired. In fact, there are quite a few side benefits such as:
- Mobile video - when users watch mobile video, sound is not always available, or loud enough.
- Language barriers - for non-native-language viewers, closed captions make it easier to follow the video.
- Search engine indexing - as quoted by Google: “When you start adding text to all of your videos, search is aided tremendously.” Textual descriptions of your video footage increase the accuracy of the content indexing.
- In-video search - with your text indexed, it becomes easy to implement an in-video search which allows a user to jump directly to a particular section within the video. Check out Hulu's implementation of their captions search feature.
As video captioning enters the HTML5 market, and standards are developed around the , captions will become even easier to publish.
With big names in video like Hulu and YouTube (where captions are included on all English-language videos uploaded after April 2010), putting emphasis on closed captions, we can be certain that the future will indeed be captioned. We encourage you, as a video publisher, to start experimenting with video captioning and create a workflow where closed captioning is a regular part of your video publishing process.
JW Player 5.9: HTML5 Now Default on Android
by Pablo Schklowsky on February 02, 2012
As we continue to bring HTML5 support in the JW Player closer to parity with Flash mode, we've focused the 5.9 release on a variety of HTML5 stability and user experience updates:
HTML5 is now the default playback mode on Android Devices
In early November, Adobe announced it would stop developing its Flash Player for Android devices. As a result we've decided to focus our energies on optimizing HTML5 support on Android rather on a legacy platform.
Cleaner User Interface (Especially on iOS devices)
We've taken a number of steps to clean up the way the player looks and behaves, focusing on iOS. Although they're subtle, we think you'll appreciate them. Among the improvements are:
- The preview image now fades in when player loads
- Video is not displayed until it is sized correctly and ready to play
- The buffering icon appears on the iPad while video is loading
Saved Volume in HTML5
One feature from Flash mode that you told us you wanted to see in HTML5 was the player's ability to keep track of the last volume level selected by the user. Now, if a user reloads a page, or goes to a different page on your site, the player will be set up with the same volume (or mute state) as the last time they set it. (Note: this won't work on iOS, since websites are not allowed to set the volume of those devices)
Download the JW Player 5.9
You can download the JW Player 5.9 for Flash and HTML5 here. As always, we would love to hear your feedback on the release. Just post your comments directly to this blog.
Check out our release notes for this version. For a complete list of the tickets addressed in JW Player 5.9, please visit our developer site.