Online video is an exciting field to work in. As creator of the JW Player, I’m privileged to be at the forefront of the industry. Every week, our team receives thousands of emails from web developers regarding various bug reports, product feature requests and general thoughts about the online video space. In these emails, we’ve seen a growing interest in HTML5, since its video implementation allows web developers to independently control video content.
Apple’s launch of the iPad and its successive arguments with Adobe over Flash accelerated HTML5 video development. One could argue that today’s tech industry is in a state of video tag euphoria. Although many high level discussions regarding online video are circulating through the blogosphere, the practical side of HTML5 video development has been overlooked. Therefore, when working hands-on with HTML5 for video development, it becomes clear the standard faces a major threat.
The video tag is still in its infancy and misses certain core functionalities. As developers demand these features, browser vendors are tempted to implement incompatible solutions instead of agreeing upon standards. These hasty developments, already underway, are setting HTML video up for the same chaos as HTML styling in the pre-CSS era.
Here are a couple of the most pressing issues:
Codecs
The H264 versus OGG debate is ongoing, but all browsers have placed their bets – Firefox and Opera favor OGG, Internet Explorer and Safari choose H264. Chrome plays it safe and does both.
While their reasoning is noble, Firefox’s choice to support just OGG isn’t practical. The majority of online video content is encoded in H264. Nearly all mobile devices that support web browsing use H264. Desktops and laptops can do hardware decoding of H264. By contrast, content in OGG is virtually nonexistent and the number of mobile devices supporting OGG decoding is devoid. The lack of hardware decoding for OGG makes playback of HD content a resource hog. Apparently, developers don’t want this.
Perhaps OGG (or VP8) will gain traction in the coming years. However, developers want to use HTML5 video today. And today’s online video format is H264.
Streaming
HTML5 does not specify a streaming mechanism yet. While this is being worked on (W3C: Fragments, Media Multitrack API), it means that live, DVR and long-form video content cannot be played using a video tag. Most browsers do provide an alternative, such as utilizing the range request header to do pseudo-streaming, but this is no long-term solution.
Safari, however, does provide a working streaming solution. It is easy to use (although a simple ingestion tool is still missing) and follows the emerging standard of chopping up videos into small fragments and delivering those to the browser. Unfortunately there are small differences between Safari’s implementation and that of, say, Silverlight and Flash:
1) Safari requires the video fragments to be wrapped in an MPEG TS container, while both Flash and Silverlight use MP4 containers.
2) Safari uses M3U8 text files to tell the browser which video fragments are available. Silverlight and Flash both use XML files.
Since streaming is the single biggest block missing in HTML5 video, other browsers may rush to implement their own streaming solutions (for example, IE9 might support Silverlight’s fragmentation and manifesting). A single standard is needed for HTML5 video streaming to ensure its usefulness.
Fullscreen
While a small feature at first sight, fullscreen playback is essential to the success of HTML5 video. Fullscreen video captivates the viewer, greatly enhancing the visual experience, and tends to increase viewer engagement. Without fullscreen, HTML5 video is mostly useful for presenting short clips.
Browser-wise, things get a little complicated. The W3C video draft specifically states that browsers should not provide a public API to cause videos to be shown full-screen. The underlying reasoning (phishing) is valid, but technologies like Flash and Silverlight have already proven that simple restrictions can mitigate these risks.
Meanwhile, developers have demanded fullscreen playback and browser vendors worked around the W3C spec to implement custom solutions. In Firefox 3.6, fullscreen viewing is available by right-clicking a video (no API). In Webkit (the rendering engine both Safari and Chrome are based on), fullscreen mode can be activated by means of ALT-clicking (semi-API). Both options are too obscure to gain any traction. A single public API with clear restrictions is needed.
Conclusion
Video is an important part of today’s internet. It deserves to become a first-class citizen and the video tag provides the opportunity to make that happen. Browser vendors should be stringent when building solutions that are both practical and compatible. If not, crossbrowser HTML5 video will be too difficult, not to mention expensive, to implement. This presents the risk of web development regression.
In favor of its advancement, we cannot allow this to happen. Online video will go mobile and big screen. It also needs to become accessible and searchable. HTML5 video will advance the progress in these areas, if developed carefully and intelligently. However, without compatible solutions, online video is in definite jeopardy of a setback.