Tag: video publishing
The State of HTML5 Video Report - JavaScript, Market Share, Fullscreen, and More...
by Jeroen Wijering on April 19, 2012
In January 2012, we announced the launch of our online resource, The State of HTML5 Video Report. Since its launch, we have had a tremendous response from our community. The page itself has been tweeted over 3,000 times, received 30,000 visits the day of its launch, and is still actively circulating the digital sphere.
Three months after its initial launch, we have updated the report with some very interesting findings. First, you will find a new JavaScript section, dedicated to video scripting using the video tag. Common use cases for this are the rendering of custom controls (like JW Player does) or page interaction with the video timeline (like Popcorn.js does). Second, you will find all existing tests updated with results from the latest browsers and mobile platforms. We highlight some interesting findings below.
Market Share
Compared with our statistics from last quarter, we already see shifts in market share. By market share, we mean the portion of the online market that is controlled by a particular browser / device:
IE 6/7/8 are declining quickly; their market share has gone from approximately 28% to 22% in the last few months. IE9, however, is growing (up to 11% market share from 9%). Chrome & Firefox are growing as well. Both have surpassed the share of IE 6/7/8.
Additionally, Android now has surpassed Opera. In terms of the mobile market, iOS still controls roughly 2x (4%) more than the other platforms, due to its dominance over the tablet market & recent success with the iPhone 4S. Other mobile platforms are virtually nonexistent.
Android 4.0
While Android 4.0 (Ice Cream Sandwich) was released last year, not every device-maker has updated their devices to the latest operating system. Still, some devices (like the Galaxy S2) now run ICS, so we have included it in our test results. Unfortunately, we found Android 4.0 to exist as a mixed bag of new features and new bugs. Some of the more interesting findings were:
- Support for WebM video decoding. It is in software though, so larger or longer videos do not play.
- Support for Apple HLS streaming. Unfortunately, quality switching has not yet been implemented.
- The video tag controls are still buggy. It is still difficult to start a video in HTML5.
- The scripting API is still a bit buggy - no metadata, no errors & no buffering. API for playback and seeking have improved though.
- Videos play inline on mobile phones, which creates an awkward UX. A fullscreen button is available, but it is as equally hard to click as the play button (e.g. they are both tiny).
Fullscreen API
There have been several updates on the state of Fullscreen playback in HTML5, which is pretty exciting for online video. While Chrome & Safari already supported the Fullscreen API, Firefox recently introduced support for it too (view our test page here). Thus, between these three browsers, the majority of the browser market supports fullscreen playback in HTML5. Opera is actively working on fullscreen support; presumably IE10 will introduce beta support as well.
Other interesting developments that you should stay tuned for more information on include Firefox's drop in support for the fullscreen button, and the discussion around fullscreen support in mobile devices, which becomes more relevant now that Android 4.0 plays the video inline.
We hope you take a look at the most recent version of our published report, share with your community, and send us your feedback! Feel free to post your comments directly to this blogpost, or join the discussion on our Facebook page.
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.
Introducing The State of HTML5 Video Report
by Jeroen Wijering on January 26, 2012
Today we announced the public launch of our latest resource, The State of HTML5 Video Report. For two years our JW Player team has researched and monitored the evolution of HTML5 video capabilities so that we could effectively support it. Beyond our own products, we believe that the community at large will benefit from this work. We are extremely pleased to share our detailed research with the community.
We grouped our test results into the few topics we've found to be the most critical. Each section is fleshed out, and to the best of our ability accurately represents the state of HTML5 online video today - complete with our published test pages & results. The topics covered in the report include:
- Market Share of Browsers and Devices
- Media Formats
- Tag Attributes
- Fullscreen Playback
- Adaptive Streaming
- Accessibility
Get full access to the online report here. Each time we update the report, we will post a notification on our Facebook page, as well as on our Twitter account. Be sure to like us on Facebook and follow us on Twitter to stay informed.
Whether you are well-acquainted with HTML5, or just getting started, the content presented in our report is an indispensable resource for tracking the progress of HTML5 video. As HTML5 video progresses, we will update and amend this report to accurately reflect the state of the industry.
We have already received such a great response from our community, and as always appreciate the support. In addition to the applause, we have also received valuable feedback from other HTML5 experts, and intend to edit the report where necessary.
The JW Player team will be participating in discussions with the community around HTML5 video. Visit us on Facebook to join the conversation.
The Future of Mobile Video is Apple, For Now
by Jeroen Wijering on December 12, 2011
Consolidation has begun in the mobile video space. In early November, Adobe announced it would stop developing its Flash Player for mobile devices (read: Android). Going forward, HTML5 will be the only method to play back videos on mobile phones and tablets. This is a big win for Apple, the company that most strongly opposed Flash in the last few years
According to Adobe, Android 4 (Ice Cream Sandwich) will be the last mobile platform to get a Flash plugin. The OS is launching without one, though. Given the terrible track record of Flash for mobile, we shouldn't be surprised if it never arrives. Ergo, video publishers should ensure their video works in HTML5 on Android today.
Apple is winning under the hood as well. The H.264 codec is baked into the CPU of every single mobile phone today, while WebM is still confined to a software-only (and non-HTML5) implementation on some Android devices. Google is working on hardware, but the path from reference designs to integration in phones and, eventually, market share is a long one.
Until WebM hardware decoding is supported by a decent slice of mobile devices, video publishers will continue to focus on H.264. Seeing this, Google continues its support for H264 in Chrome, despite the announcement to drop it "soon" almost a year ago. For all intents and purposes, H.264 is the baseline codec for HTML5 video at present.
Completing its hat trick, Apple is well on its way to providing the de facto streaming protocol for mobile video: HLS. Built on top of HTML5, this protocol allows publishers to deliver their videos securely with high quality. I should note that this is relevant only to roughly 10 percent of all publishers, but these publishers account for 90 percent of all mobile views.
What Is HLS?
The acronym HLS stands for HTTP Live Streaming. It is a protocol that allows publishers to stream video using plain HTTP web servers, as opposed to often expensive and hard to scale dedicated streaming servers. This streaming is achieved by chopping up the video hosted on the server into small (usually 10 seconds) fragments, stitching them together again in the browser. The browser only requests the next fragment in line, instead of loading the entire video and wasting bandwidth, as happens in vanilla HTML5. See diagram below for a single fragmented stream:
A video streamed through HLS is usually encoded into multiple qualities, ranging from a mere 180px to full-blown 720px and beyond. Every time the browser returns to the server to load the next fragment, it decides which quality level to load. The browser thus continuously adjusts the quality of the stream to best match the available bandwidth. This is hugely important in mobile, with devices perpetually swapping between 2G, 3G, 4G and WiFi connections. See diagram below for an adaptive fragmented stream:
In addition to this, the fragments of HLS streams can be encrypted for secure delivery. Users who intercept these fragments will not be able to play them at all. This is a big security advantage over plain HTML5 video, where every savvy user can find the URL of a video and download it for his own use.
Why Use HLS?
Today's wide usage of the HLS protocol is a result of the success of iOS. Apple designated the protocol as the one and only way to stream video to the iPhone and iPad. No Flash, no Silverlight, no RTP or RTSP. On top of that, HLS is required for in-app video. Even simple MP4 downloads, which do work for in-browser playback, are not allowed in iOS apps.
Every major publisher therefore needs to use the HLS protocol, and every major encoding tool (e.g. Sorenson Squeeze) and streaming server (e.g. Flash Media Server or Wowza Media Server) supports it nowadays. This broad ecosystem, in turn, now has many devices that support the protocol as well. Nearly every popular set-top box can play HLS (Xbox, PS3, Roku, Apple TV, Boxee), as will Android phones running the new Ice Cream Sandwich release.
Wondering if there are any competing protocols? Absolutely. Smooth Streaming from Microsoft is one, but it requires the non-mobile Silverlight plugin. There is also Dynamic Streaming from Adobe, which requires the soon to be retire? Flash plugin. HLS is built on top of HTML5, which makes it easy to implement by both browsers and devices.
A standardization effort is on its way as well, in the form of MPEG DASH (HLS, as well as RTMP and RTSP. However, as things go with standards, progress is slow and broad support is years away.
The Apple Standard
So, for the foreseeable future, we'll watch our mobile video the Apple way: embedded using HTML5, encoded using H.264 and streamed using HLS. Any platform that wants broad support for quality video (Windows Phone?) must implement HLS and any publisher that wants many mobile viewers must leverage HLS.
Now, is this a bad thing? Quite the contrary. The alternative to a central protocol is fragmentation: multiple plugins, multiple codecs and multiple protocols. Which is bad for large media corporations, as it reduces their bottom line. Even worse for smaller video publishers though, since they lack the resources to even make their video available at all. And that, in turn, is a detriment to mobile video at large. The key to mass adoption is broad-reaching availability across a wide variety of content.
This blogpost is a modified version of our article first published on Mashable. Read Full Article Here.
HTML5 Video: Still not there yet, but making headway
by Pablo Schklowsky on October 10, 2011
Last year, we declared that HTML5 video was not quite there yet. Well, it's nearly 18 months since that post, so what's happened in the intervening time?
Let's start off with the positive: compared to 18 months ago, the browsers' implementations of the <video> tag have become much more stable. They also all have built-in support for pseudo-streaming (i.e. the ability to seek to an unbuffered position in the video file). The tools surrounding HTML5 video — streaming servers, transcoders, etc. — have also improved.
On the other hand, many of the issues we pointed to in our last post have not yet been resolved. HTML5 video is still "not quite there yet", but we'll take a look at the developments over the past year and make some predictions on where this is all headed.
Answering some open questions
In our last post on the subject, Jeroen mentioned three major issues which prevented HTML5 video from taking off. Let's see where these issues are today.
Codec support
The major question surrounding codecs revolves around whether open video codecs such as Google's WebM and Ogg Theora would overtake proprietary formats such as H.264. As before, this still comes down to browser and device support. Though the open-source browsers have decided on an open format — WebM — no current mass-market mobile device has hardware drivers which can decode VP8 (the video codec used in WebM).
On the desktop, the sides seem firmly entrenched. Apple has no interest in moving away from H.264, considering the investment they've made in the technology. Microsoft doesn't support WebM natively (users need to manually install the codecs). Firefox and Opera still have no desire (or, possibly, ability) to support H.264. And although Google announced in January that H.264 support would be removed from Chrome, more than 8 months later, there's been no indication when (or even if) this will happen.
The codec wars are still being fought full-steam. And the end result of the lack of a standard video format is that many publishers simply encode once — in H.264 — and rely on Flash for support in browsers that don't support it.
Streaming
We predicted that the browsers would choose to implement their own streaming mechanism to compete with Apple's HTTP Live Streaming (HLS) format (built into desktop and mobile Safari). The question would be what open standard would be chosen to build upon?
What happened instead is that this area was more or less overlooked. Safari Desktop and Mobile, and Android 3.0+ are still the only browsers with built-in support for an HTML5 streaming protocol. Publishers who require that their content be streamed (rather than simply downloaded) on any other device or browser must fall over to a Flash or Silverlight player.
Moreover, a common streaming format has still not been agreed upon. The browser vendors are reluctant to hitch their wagon to any one method of HTTP streaming — for technical reasons, and because they're waiting to see which formats users begin implementing themselves. Of course, this is something of a chicken-or-egg proposition.
Fullscreen
A draft standard for adding fullscreen support to browsers has been written up and more or less agreed upon. Safari has already implemented support for this in version 5.1. While no other browsers have implemented the necessary APIs, Chrome (which uses the same rendering engine as Safari, called Webkit) is probably the closest to making this a reality. Although Mozilla wrote the spec, there's currently no word on when Firefox will implement it Firefox has implemented fullscreen support in their nightly build, but the feature is disabled by default. In short, true fullscreen functionality is still lacking on most browsers.
It's worth mentioning that on most mobile phones (not tablets), HTML5 videos will always play in fullscreen mode. This is partially due to limitations in hardware, but it also makes sense from a usability perspective — if you're watching video on a web page on a 3.5-inch screen, do you really want to see anything other than the video itself?
What's coming up
So what can we expect within the next 6-12 months? We recently attended the Open Video Conference in New York, and rubbed shoulders with the people who are making HTML5 Video happen — browser engineers from Apple, Google, Mozilla and Opera were all in attendance (not to mention YouTube, Netflix, Internet Archive and many more). Everyone had a ton to bring to the table (Silvia Pfeiffer, who organized the conference's Open Media Developer track, has written a great summary of the work that went on). And while there's a lot of exciting technology being built, the core problems I mentioned earlier which are preventing HTML5 from becoming the de facto standard in web video (format compatibility and streaming) are still not being addressed in a unified way.
That being said, some of that new stuff is pretty cool, and may end up moving the needle. Let's take a look.
The <track> Element: Adding Text Elements to Media
The HTML5 <track> element is for adding timed textual metadata to a media element. This enables video players to add functionality to support subtitles, closed captions, chaptering and more. While none of the browsers currently support <track> natively, we got to see a cool JavaScript demo which added captioning functionality into a <video> tag.
Once this becomes a reality, text tracks will be an exciting new development in HTML5. It will help make video accessible to the seeing- and hearing-impaired, enable subtitles for foreign language speakers, and make video files indexable (and therefore searchable). All of these will pave the way for video and audio to become first-class citizens on the web.
MediaSource API: Direct access to video data
Google is working on a feature for Chrome, called the MediaSource API, which will allow JavaScript developers to manipulate video data at the lowest possible level (the byte stream). One application of this mechanism would be for video players to piece together small bits of video, serving as the basis for an adaptive streaming application.
This approach puts the onus on JavaScript video players, such as the JW Player, and on video content providers, to come up with their own solutions for streaming video in HTML5. While I'm sure there will be attempts at making this happen, the jury's still out on whether this method can become the basis for HTML5 video streaming, for the usual reasons — browser fragmentation, and the ever-present format wars (Chrome's implementation will only support WebM at first). My personal opinion is that until the browsers present a standard for HTTP streaming to developers and publishers, you'll see a couple of cool demos, maybe even an end-to-end solution (think Netflix or YouTube), but not an overall standard.
Conclusions
Yes, progress has been made. The tools are better (for example, the popular desktop encoder Miro Video Converter now includes support for WebM). The servers are better (Wowza Media Server and Adobe Flash Media Server (FMS) support both Apple HLS for HTML5 streaming and RTMP for Flash streaming). And the browsers are better, especially the mobile ones (many of the HTML5 video bugs in Android and iOS were fixed in versions 2.3 and 4.0, respectively).
So why did I say at the beginning of this article that HTML5 still isn't there yet? Why isn't Flash losing more ground, considering its own drawbacks (poor resource utilization, lack of support on iOS, to name a couple)? The simple answer is that Flash offers a safer, more uniform cross-platform environment for video developers and publishers, while HTML5 presents a dizzying array of browsers to test against, and competing formats to support. You still need both Flash and HTML5 to cover all of your bases, but most publishers are still choosing Flash as their primary video delivery platform for these reasons.
The JW Player will continue to stay close to the bleeding edge of HTML5 video, and we'll continue integrating both Flash and HTML5 together as seamlessly as possible. We're rooting for HTML5 and its promise of open standards, better accessibility and better performance. But it'll still be some time before HTML5 has everything it needs to take its place at the head of the table.
- 1 of 6
- ››