Showing posts with label HTML 5. Show all posts
Showing posts with label HTML 5. Show all posts

HTML5 Video in Safari on OS X Yosemite

We're excited to announce that Netflix streaming in HTML5 video is now available in Safari on OS X Yosemite! We've been working closely with Apple to implement the Premium Video Extensions in Safari, which allow playback of premium video content in the browser without the use of plugins.

If you're in Apple's Mac Developer Program, or soon the OS X Beta Program, you can install the beta version of OS X Yosemite. With the OS X Yosemite Beta on a modern Mac, you can visit Netflix.com today in Safari and watch your favorite movies and TV shows using HTML5 video without the need to install any plugins.

We're especially excited that Apple implemented the Media Source Extensions (MSE) using their highly optimized video pipeline on OS X. This lets you watch Netflix in buttery smooth 1080p without hogging your CPU or draining your battery. In fact, this allows you to get up to 2 hours longer battery life on a MacBook Air streaming Netflix in 1080p - that’s enough time for one more movie!

Apple also implemented the Encrypted Media Extensions (EME) which provides the content protection needed for premium video services like Netflix.

Finally, Apple implemented the Web Cryptography API (WebCrypto) in Safari, which allows us to encrypt and decrypt communication between our JavaScript application and the Netflix servers.

The Premium Video Extensions do away with the need for proprietary plugin technologies for streaming video. In addition to Safari on OS X Yosemite, plugin-free playback is also available in IE 11 on Windows 8.1, and we look forward to a time when these APIs are available on all browsers.

Congratulations to the Apple team for advancing premium video on the web with Yosemite! We’re looking forward to the Yosemite launch this Fall.

By Anthony Park and Mark Watson, Netflix Tech Blog

Live Streaming to the Browser Using MSE and MPEG-DASH

For the next two weeks, we’re running a trial in conjunction with Radio 3 to deliver surround sound to your browser for a series of classical music concerts. On the Radio 3 blog, Rupert Brun explains the background to the trial and how to get involved.

Here in Broadcast & Connected Systems at BBC R&D, we are always looking for new ways to apply our technology research to extend the reach of BBC content to the maximum number of users. Surround sound isn’t new, but delivering it to the home via the Internet has traditionally meant installing plugins or other applications, limiting the platforms and consumers we can target.

In this experiment, we believe we are the first broadcaster in the world to stream a live outside broadcast in discrete multichannel audio to the home using MPEG-DASH, and we're doing it using just a compliant web browser - no plugins, no separate software installation required.


Why Stream to the Browser, and Why Now?
The beauty of the browser is that it is (almost) ubiquitous. Every PC, tablet and smart phone has a browser installed when it ships. Increasingly, smart TVs, set top boxes and games consoles have some form of browser environment available, bringing HTML5, CSS and Javascript functionality to the majority of consumer electronic devices.

People expect to be able to consume BBC content on any platform. To enable this, the BBC currently has to support a number of streaming protocols and has to maintain many different applications with differing code bases and levels of functionality in order to support hundreds of different set top boxes, smart TVs, mobile devices and desktop environments.

What if we could have a single encoding and distribution workflow and a single cross-platform client application, reducing the complexity of distribution and allowing our developers to concentrate on delivering great user experiences?

From a listener’s perspective, the browser “just works” which makes accessing our services much easier. Removing the requirement to install plugins or other software removes a significant barrier for some users. Indeed, for cross-platform compatibility, security and stability, many browser vendors have decided not to support plugins in the future so we need to move away from these anyway.

Three particular technical standards should enable us to do this in the future: HTML5, MPEG-DASH and W3C Media Source Extensions.


HTML5 and Media Source Extensions (MSE)
In HTML5 the HTMLMediaElement, typically a video or audio tag, exposes a source element which accepts a URL of the content to be played. The browser retrieves, decodes and plays the media data automatically, providing it knows how to handle your media type. This offers simplicity for the developer and, in theory, has removed the need for plugins, but the trade-off is that there is no control over many important variables: how data is downloaded and from where, how much data is buffered, which adaptive streaming algorithms to use or what to do in case of failure.

The ability to control these variables is key to providing a world-class user experience, but by default they are hard-coded into the browser. Ideally we want to hand as much control as possible to the Javascript application, while still deferring to the browser for parsing, decoding and rendering the media data. Typically, Adobe Flash or Microsoft Silverlight applications have been used to provide all of this functionality on those platforms that support those plugins.

Most of these features can be replicated in Javascript but, until now, it has not been possible to feed media data to the HTMLMediaElement. The Media Source Extensions define a Javascript API which allows media streams to be constructed dynamically within a Javascript application.

At the heart of MSE is the MediaSource object. This object is created by the application and attached to the media element. Its purpose is to provide the media data for playback as requested by the media element.

The MediaSource object maintains a collection of SourceBuffers. These are the interface through which the application appends media data to the source and methods are provided to insert, remove and manage media data. They are essentially an abstraction of a timeline – media data can appended to the buffer based on media playback timestamp, or it can be appended sequentially, ignoring timestamps. The latter mode enables unrelated media to be spliced together, which allows uses such as advert insertion or even video editing in the browser.



The application handles the requesting of media data from the server and appends the response to the SourceBuffer. Decoupling the fetching of media data from playback allows the media data to be sourced using novel transport mechanisms or from different locations.

SourceBuffers can contain audio, video or timed text and an instance is created for each stream that needs to be presented. Typically there might be one video stream, one audio stream and perhaps a subtitle stream. Since each media type is handled separately, access services such as audio description or subtitling can be selected simply by requesting a different stream.

Finally, the specification also includes extensions to the HTMLVideoElement allowing measurement of video decode and rendering performance which could be used to help decide the most appropriate video stream to present if a number of options are available.

An additional benefit of not hardcoding features into the browser is that any functionality upgrades such as improved adaptive algorithms or defect fixes are simply a case of updating the Javascript application, which is freshly fetched each time the page is loaded, rather than requiring every user to upgrade their browser. Software updates to the browser itself might be fairly easy on a PC but happen infrequently on a smart TV or set top box.


Content Delivery Using MPEG-DASH
MPEG-DASH is the new standard for delivering media content over the Internet. It is designed to allow content to be delivered efficiently in a segmented form, making use of standard caching techniques for web content in order to deliver to large audiences. It supports bitrate adaptation, allowing each viewer to receive a stream in the best quality that their Internet connection can deliver.

Since even surround audio streams need only a low bitrate connection, we are not using bitrate adaptation for this trial. The audio stream is simply encoded at a constant rate of 320 kbps using AAC-LC. However, MPEG-DASH still takes care of dividing the live audio stream into short segments that the client can retrieve using HTTP. Most importantly, MPEG-DASH is a streaming standard which can be implemented for a browser using the W3C Media Source Extensions.


Building a MPEG-DASH Player Using MSE
In order to deliver the surround audio to you, a DASH player application needs to at least perform the following tasks:
  1. Create a MediaSource object and set it as the source of the media element
  2. Request and parse manifest and create SourceBuffer objects for each enabled stream
  3. Request segments for each stream and append them to the SourceBuffers
  4. Repeat step 3
Quite a lot of code is required just for those few steps. For this trial, we’ve chosen to use a modified version of dash.js, an open-source MPEG-DASH player implemented entirely in Javascript.


Where Next?
MSE has recently reached Candidate Recommendation stage, meaning that it should be complete enough to allow implementation, but browser support is still limited.

Right now, Chrome (33 or higher), and IE11 on Windows 8.1, are the only browsers we’ve seen which support enough features for our trial. If you’re a fan of Firefox, Safari or other browsers, these currently have incomplete support, though many of these vendors have publicly stated they are working on it.

As support for these features becomes more widespread, we expect that more and more content on the Internet will be delivered this way. Other content providers are also starting to use these techniques: Netflix has deployed a MSE-based player – this is the default player if you are using IE11 on Windows 8.1. Youtube has also deployed a MSE-based player for some content on some platforms.

Although we are actively experimenting with MSE in BBC R&D, there are no immediate plans to launch any BBC services using the technology. Nevertheless, HTML5, MPEG-DASH and MSE are a powerful set of standards that are sure to play a significant role in delivering media content on the Internet in the coming years.

By Dave Evans, BBC R&D

HTML5 Video in IE 11 on Windows 8.1

We've previously discussed our plans to use HTML5 video with the proposed "Premium Video Extensions" in any browser which implements them. These extensions are the future of premium video on the web, since they allow playback of premium video directly in the browser without the need to install plugins.

Today, we're excited to announce that we've been working closely with Microsoft to implement these extensions in Internet Explorer 11 on Windows 8.1. If you install the Windows 8.1 Preview from Microsoft, you can visit Netflix.com today in Internet Explorer 11 and watch your favorite movies and TV shows using HTML5!

Microsoft implemented the Media Source Extensions (MSE) using the Media Foundation APIs within Windows. Since Media Foundation supports hardware acceleration using the GPU, this means that we can achieve high quality 1080p video playback with minimal CPU and battery utilization. Now a single charge gets you more of your favorite movies and TV shows!

Microsoft also has an implementation of the Encrypted Media Extensions (EME) using Microsoft PlayReady DRM. This provides the content protection needed for premium video services like Netflix.

Finally, Microsoft implemented the Web Cryptography API (WebCrypto) in Internet Explorer, which allows us to encrypt and decrypt communication between our JavaScript application and the Netflix servers.

We expect premium video on the web to continue to shift away from using proprietary plugin technologies to using these new Premium Video Extensions. We are thrilled to work so closely with the Microsoft team on advancing the HTML5 platform, which gets a big boost today with Internet Explorer’s cutting edge support for premium video. We look forward to these APIs being available on all browsers.

By Anthony Park and Mark Watson, The Netflix Tech Blog

HTML5 Video at Netflix

Today, we’re excited to talk about proposed extensions to HTML5 video that enable playback of premium video content on the web. We currently use Microsoft Silverlight to deliver streaming video to web browsers on the PC and Mac. It provides a high-quality streaming experience and lets us easily experiment with improvements to our adaptive streaming algorithms.

But since Microsoft announced the end of life of Silverlight 5 in 2021, we need to find a replacement some time within the next 8 years. We'd like to share some progress we've made towards our goal of moving to HTML5 video.

Silverlight and Browser Plugins
Silverlight is a browser plugin which allows our customers to simply click "Play" on the Netflix website and watch their favorite movies or TV shows, but browser plugins have a few disadvantages. First, customers need to install the browser plugin on their computer prior to streaming video. For some customers, Netflix might be the only service they use which requires the Silverlight browser plugin. Second, some view browser plugins as a security and privacy risk and choose not to install them or use tools to disable them. Third, not all browsers support plugins (eg: Safari on iOS, Internet Explorer in Metro mode on Windows 8), so the ability to use them across a wide range of devices and browsers is becoming increasingly limited. We're interested to solve these problems as we move to our next generation of video playback on the web.

HTML5 Premium Video Extensions
Over the last year, we've been collaborating with other industry leaders on three W3C initiatives which are positioned to solve this problem of playing premium video content directly in the browser without the need for browser plugins such as Silverlight. We call these, collectively, the "HTML5 Premium Video Extensions":

Media Source Extensions (MSE)
The W3C Media Source Extensions specification "extends HTMLMediaElement to allow JavaScript to generate media streams for playback." This makes it possible for Netflix to download audio and video content from our content delivery networks and feed it into the video tag for playback. Since we can control how to download the audio/video content in our JavaScript code, we can choose the best HTTP server to use for content delivery based on real-time information, and we can implement critical behavior like failing over to alternate servers in the event of an interruption in content delivery. In addition, this allows us to implement our industry-leading adaptive streaming algorithms (real-time selection of audio/video bitrates based on available bandwidth and other factors) in our JavaScript code. Perhaps best of all, we can iterate on and improve our content delivery and adaptive streaming algorithms in JavaScript as our business needs change and as we continue to experiment.

Encrypted Media Extensions (EME)
The W3C Encrypted Media Extensions specification "extends HTMLMediaElement providing APIs to control playback of protected content." The video content we stream to customers is protected with Digital Rights Management (DRM). This is a requirement for any premium subscription video service. The Encrypted Media Extensions allow us to play protected video content in the browser by providing a standardized way for DRM systems to be used with the media element. For example, the specification identifies an encrypted stream format (Common Encryption for the ISO file format, using AES-128 counter mode) and defines how the DRM license challenge/response is handled, both in ways that are independent of any particular DRM. We need to continue to use DRM whether we use a browser plugin or the HTML5 media element, and these extensions make it possible for us to integrate with a variety of DRM systems that may be used by the browser.

Web Cryptography API (WebCrypto)
The W3C Web Cryptography API specification defines an API for "basic cryptographic operations in web applications, such as hashing, signature generation and verification, and encryption and decryption." This API allows Netflix to encrypt and decrypt communication between our JavaScript and the Netflix servers. This is required to protect user data from inspection and tampering, and allows us to provide our subscription video service on the web.

First Implementation in Chrome OS
We've been working with Google to implement support for the HTML5 Premium Video Extensions in the Chrome browser, and we've just started using this technology on the Samsung ARM-Based Chromebook. Our player on this Chromebook device uses the Media Source Extensions and Encrypted Media Extensions to adaptively stream protected content. WebCrypto hasn't been implemented in Chrome yet, so we're using a Netflix-developed PPAPI (Pepper Plugin API) plugin which provides these cryptographic operations for now. We will remove this last remaining browser plugin as soon as WebCrypto is available directly in the Chrome browser. At that point, we can begin testing our new HTML5 video player on Windows and OS X.

We're excited about the future of premium video playback on the web, and we look forward to the day that these Premium Video Extensions are implemented in all browsers!

By Anthony Park and Mark Watson, The Netflix Tech Blog

Google, Microsoft, Netflix Want Encrypted HTML5 Media Spec

Google, Microsoft, and Netflix have put forward a proposal that could add a level of copy protection to HTML5 audio and video. Encrypted Media Extensions would let apps on the web and elsewhere use keys to control who has access to a given media stream. It would allow any format that would work in HTML5 as long as the format itself can support some kind of key or bit.

If implemented, it could eliminate objections raised by Adobe as well as content providers regarding HTML5's limits. Paid movie services and others that want a secure stream have either limited HTML5 to native mobile apps, where users can't easily rip the feed, or avoided it altogether.

Netflix would have the option of dropping Microsoft's Silverlight plugin when on the web, while Google could skip Flash for its YouTube-based movie service in Android Market. Microsoft has been deprecating Silverlight and could use HTML5 even on the Xbox 360.

Concerns exist both on technical and philosophical levels. It may not necessarily provide the promised experience in at least the initial spec and could require revision. Despite promising to keep digital rights management out of HTML5, the trio have also raised alerts from Mozilla and others concerned it would break standards and force a less than ideal concern that might hurt some HTML5 supporters.

The World Wide Web Consortium, which has to consider the proposal, hasn't said when it might decide. As an unofficial draft, it could spend some time being completed before the question of approval and possible implementation comes up.

Source: Electronista

H.264 Video in Firefox for Android

Firefox for Android has expanded its HTML5 video capabilities to include H.264 video playback. Web developers have been using Adobe Flash to play H.264 video on Firefox for Android, but Adobe no longer supports Flash for Android. Mozilla needed a new solution, so Firefox now uses Android’s “Stagefright” library to access hardware video decoders.

Supported Devices
Firefox currently supports H.264 playback on any device running Android 4.1 (Jelly Bean) and any Samsung device running Android 4.0 (Ice Cream Sandwich). We have temporarily blocked non-Samsung devices running Ice Cream Sandwich until we can fix or workaround some bugs. Support for Gingerbread and Honeycomb devices is planned for a later release.

To test whether Firefox supports H.264 on your device, try playing this Big Buck Bunny video.

Testing H.264
If your device is not supported yet, you can manually enable H.264 for testing. Enter about:config in Firefox for Android’s address bar, then search for “stagefright”. Toggle the “stagefright.force-enabled” preference to true. H.264 should work on most Ice Cream Sandwich devices, but Gingerbread and Honeycomb devices will probably crash.




If Firefox does not recognize your hardware decoder, it will use a safer (but slower) software decoder. Daring users can manually enable hardware decoding. Enter about:config as described above and search for “stagefright”. To force hardware video decoding, change the “media.stagefright.omxcodec.flags” preference to 16. The default value is 0, which will try the hardware decoder and fall back to the software decoder if there are problems. The most likely problems you will encounter are videos with green lines (see below) or crashes.





Giving Feedback/Reporting Bugs
If you find any video bugs, please file a bug report here so we can fix it! Please include your device model, Android OS version, the URL of the video, and any about:config preferences you have changed. Log files collected from aLogcat or adb logcat are also very helpful.

By Chris Peterson, Mozilla Hacks

Streaming Standards for Worship

If you produce streaming video in the worship market and have your ear to the ground, you may be experiencing sensory overload right now. HTML5 is being promoted as a panacea for all plug-in-related woes; Adobe threw the mobile market into turmoil by ceasing development of the Flash Player, and there’s a new standard called DASH that supposedly will create a unified approach for adaptive streaming to all connected devices. Seems like getting that sermon out over the Internet has gotten a lot more complicated.

Well, maybe not. In this article I’ll describe what’s actually happening with HTML5, Flash, and DASH, and make some suggestions as to how to incorporate these changes into your video-related technology plans.

About HTML5
Let’s start with HTML5, which has one potential show stopper for many houses of worship: the lack of a live capability. Apple has a proprietary technology called HTTP Live Streaming that you can use to deliver to iDevices and Macs but not Windows computers. So if live video is a requirement, HTML5 is out—at least for the time being.

If on-demand video is your sole requirement, HTML5 is a tale of two marketplaces: desktops and mobile. By way of background, HTML5-compatible browsers don’t require plug-ins like Flash or Silverlight to play web video. Instead, they rely on players that are actually incorporated into and shipped with the browser. Integrating video into a webpage for HTML5 playback uses a simple tag rather than a complicated text string to call a plug-in.

Today, the installed base of HTML5-compatible browsers on desktop computer is only around 60 percent, which makes it an incomplete solution, particularly for houses of worship whose older parishioners may be technology laggards who don’t quickly upgrade to new browsers. However, in the link that you use to display your video, it’s simple to query the browser used by the viewer to test for HTML5-playback capabilities. If the viewer’s browser is HTML5-compatible, the video will play in the HTML5 player. If not, you can code the page to “fall back” to the existing Flash Player or other plug-in, which will then load and play normally. While this sounds complicated, Flash fallback is totally transparent to the viewer and occurs in just a millisecond or two.

Why HTML5 first? Because as we’ll see in a moment, this is a very solid strategy for supporting Apple and Android devices. However, before jumping in, keep in mind that HTML5 is not as mature as Flash in several important respects. First, it lacks true streaming, or the ability to meter out video as it’s played, which is more efficient than progressive download. HTML5 also can’t adaptively stream or dynamically distribute multiple streams to your target viewers to best suit their connection speed and CPU power. It’s these two issues that the aforementioned DASH standard hopes to address.

However, the DASH standard doesn’t address HTML5’s biggest implementation hurdle, which is that all HTML5 browsers don’t support a single compression technology or codec. Specifically, Microsoft’s Internet Explorer 9 and Apple Safari include an HTML5 player for the H.264 codec, while Mozilla Firefox and the Opera browser support only Google’s open-source codec, WebM. Today, Google Chrome browser includes both codecs, but Google has stated that they intend to remove the H.264 codec sometime in the future. It’s actually a bit worse than this sounds because Firefox version 3.6, which is still more than 5 percent of the installed base of desktop browsers, only supports a third codec, Ogg Theora.

To fully support the universe of HTML5-compatible browsers, you’d have to encode files in three formats and still fall back to Flash for viewers without HTML5-compatible browsers. Or you could just continue to solely support Flash and wait a year or two (or more) until the penetration rate of HTML5 browsers exceeds 95 percent, and then reevaluate.

If your only concern was desktop players, this might be a good strategy. Include mobile in the equation, however, and creating an HTML5 player with fallback to Flash might be a great strategy for your on-demand streams.

HTML5 on Mobile Devices
In the two key mobile markets, Apple and Android, HTML5 support is ubiquitous, as is support for the H.264 codec. So the simplest way to enable on-demand playback for Apple and Android devices is to add an HTML5 player on your website using only the H.264 codec, with fallback to Flash. Android and Apple devices would use the HTML5 player, as would desktop viewers running HTML5 browsers that support H.264 playback. All other desktop viewers would fall back to Flash.

While on the topic of mobile, let’s talk about Adobe’s recent mobile-related decision, starting with precisely what they decided to do. Here’s a quote from the Adobe blog that discusses this decision:

“Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores. We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) following the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook.”

Adobe will discontinue development of the Flash Player on mobile devices, pushing their key content producers to produce native apps for the mobile platforms. According to the blog post, Adobe will also continue development of the Flash Player on the computer desktop, focusing on markets where Flash “can have most impact for the industry, including advanced gaming and premium video.”

Why the decision to cease development for mobile? There are a number of reasons. The sheer number of Android device configurations made it very expensive to provide device-specific support. Now Adobe has passed the problem of ensuring device compatibility to its app developers. In addition, Adobe was locked out of the iOS market—which doesn’t support Flash—and Microsoft has also said that they won’t enable plug-ins like Flash in its upcoming Windows 8 tablet OS.

In contrast, Android, iOS and Windows 8 all support HTML5, making it the best multiple-platform solution for deploying browser-based content to the mobile market. Adobe saw the writing on the wall and decided to exit a market that they couldn’t affordably and adequately serve.

What’s the key takeaway? At a higher level, simple video playback of on-demand content is becoming commoditized, and it can be performed just as well in HTML5 as in Flash. In addition, HTML5 also has much greater reach, allowing one player to serve mobile and desktop markets—though Flash fallback is clearly necessary on the desktop.

Adobe is positioning Flash as a premium technology that offers many advantages that HTML5 can’t offer, including all those mentioned above. Other noteworthy features that HTML5 doesn’t offer include multicasting and peer-to-peer delivery, which are particularly important in enterprise markets. However, if these features aren’t important to your organization, it’s time to start implementing HTML5 for your on-demand streams—if only with H.264 support to serve the iOS and Android markets.

DASH
DASH stands for Dynamic Adaptive Streaming over HTTP, and it’s an International Standards Organization (ISO) standard that one day may provide standards-based live and on-demand adaptive streaming to a range of platforms—including mobile, desktop, and over the top (OTT) television consoles. It’s a web producer’s dream, since by supporting a single technology, your video can play on all these platforms. The specification enjoys significant industry support, with more than 50 companies contributing to the specification.

Unfortunately, there are some implementation hurdles that may delay or even derail some of this promise. First, at this point, it’s unclear whether DASH will be royalty free. Many companies have contributed intellectual property to the specification. Many companies—such as Microsoft, Cisco, and Qualcomm—have waived any royalties from their contributions, though this is not yet universal. In fact, the current status of DASH in this regard is so uncertain that Mozilla has announced that it’s “unlikely to implement at this time.” Obviously, taking Firefox out of the equation limits the effectiveness of DASH in the HTML5 marketplace.

In addition, while some companies such as Microsoft have publicly announced that they will support DASH once finalized, two critical companies—Adobe and Apple—have not done the same. This isn’t unusual in its own right since neither company typically discusses unannounced products. Still, because these companies dominate the mobile and desktop browser plug-in markets, it’s tough to plot a strategy until you know their intent.

The Bottom Line?
If you’re broadcasting live, HTML5 isn’t an option in the short term. DASH may change things in early 2012, but until we’re certain which platforms will support it and when, you shouldn’t change your existing strategy. For most producers, live broadcasting means one stream (or set of streams) for Flash and another for iOS devices using Apple’s HTTP Live Streaming (HLS). In this regard, Flash should be available for Android devices for the foreseeable future, and Android 3.0 devices should be able to play HLS streams.

For your on-demand streams, it may be time to consider switching over to an HTML5 first with H.264 support with Flash fallback. This is the most efficient mechanism for reaching iOS, Android, and other HTML5-compatible mobile devices while continuing to support legacy desktop browsers.

By Jan Ozer, Sound & Video Contractor

The Trials and Tribulations of HTML Video in the Post-Flash Era

Adobe reversed course on its Flash strategy after a recent round of layoffs and restructuring, concluding that HTML5 is the future of rich Internet content on mobile devices. Adobe now says it doesn’t intend to develop new mobile ports of its Flash player browser plugin, though existing implementations will continue to be maintained.

Adobe’s withdrawal from the mobile browser space means that HTML5 is now the path forward for developers who want to reach everyone and deliver an experience that works across all screens. The strengths and limitations of existing standards will now have significant implications for content creators who want to deliver video content on the post-flash Web.

Apple’s decision to block third-party browser plugins like Flash on its iOS devices played a major role in compelling Web developers to build standards-based fallbacks for their existing Flash content. This trend will be strengthened when Microsoft launches Windows 8 with a version of Internet Explorer that doesn’t support plugins in the platform’s new standard Metro environment.

Flash still has a significant presence on the Internet, but it's arguably a legacy technology that will decline in relevance as mobile experiences become increasingly important. The faster pace of development and shorter release cycles in the browser market will allow open standards to mature faster and gain critical mass more quickly than before. In an environment where standards-based technologies are competitive for providing rich experiences, proprietary vendor-specific plugins like Flash will be relegated to playing a niche role.

Our use of the phrase “post-Flash” isn’t intended to mean that Flash is dead or going to die soon. We simply mean that it’s no longer essential to experiencing the full Web. The HTML5 fallback experiences on many Flash-heavy sites still don’t provide feature parity with the Flash versions, but the gap is arguably shrinking—and will continue to shrink even more rapidly in the future.

Strengths and Weaknesses of HTML5 Video
HTML5 has much to offer for video delivery, as the HTML5 video element seamlessly meshes with the rest of the page DOM and is easy to manipulate through JavaScript. This means that HTML5 video offers significantly better native integration with page content than it has ever been possible to achieve with Flash. The open and inclusive nature of the standards process will also make it possible for additional parties to contribute to expanding the feature set.

A single company no longer dictates what can be achieved with video, and your video content is no longer isolated to a rectangle embedded in a page. HTML5 breaks down the barriers between video content and the rest of the Web, opening the door for more innovation in content presentation. Three are some really compelling demonstrations out there that showcase the use of video in conjunction with WebGL and other modern Web standards. For example, the video shader demo from the 3 Dreams of Black interactive film gives you a taste of what’s possible.


Click to watch the video


Of course, transitioning video delivery in the browser from Flash to HTML5 will also pose some major challenges for content creators. The standards aren’t fully mature yet and there are still a number of features that aren’t supported or widely available across browsers.

For an illustration of how deep the problems run, you need only look at Mozilla’s Firefox Live promotional website, which touts the organization’s commitment to the open Web and shows live streaming videos of Red Panda cubs from the Knoxville Zoo. The video is streamed with Flash instead of using standards-based open Web technologies.

In an FAQ attached to the site, Mozilla says that it simply couldn’t find a high-volume live streaming solution based on open codecs and open standards. If Mozilla can’t figure out how to stream its cuddly mascot with open standards, it means there is still work to do.


Flash is required to see the Red Panda cubs on Mozilla's website


Two of the major technical issues faced by HTML5 video adopters are the lack of adequate support for adaptive streaming and the lack of consensus surrounding codecs. There is currently an impasse between backers of the popular H.264 codec and Google’s royalty-free VP8 codec. There’s no question that a royalty-free video format is ideal for the Web, but the matter of whether VP8 is truly unencumbered by patents—and also meets the rest of the industry’s technical requirements—is still in dispute.

There is another major issue that hasn’t been addressed yet by open Web standards that could prove even more challenging: content protection. The vast majority of Flash video content on the Internet doesn’t use any kind of DRM and is trivially easy to download. Flash does, however, provide DRM capabilities and there are major video sites that rely on that technology in order to protect the content they distribute.

Can DRM Be Made to Play Nice with Open Standards?
DRM is almost always bad for regular end users and its desirability is highly debatable, but browser vendors will have to support it in some capacity in order to make HTML5 video a success. Many of the content creators who license video material to companies like Netflix and Hulu contractually stipulate a certain degree of content protection.

Mozilla’s Robert O’Callahan raised the issue of HTML5 video DRM in a recent blog entry shortly after Adobe’s announcement regarding mobile Flash. He expressed some concern that browser vendors will look for a solution that is expedient rather than inclusive, to the detriment of the open Web.

“The problem is that some big content providers insist on onerous DRM that necessarily violates some of our open Web principles (such as Web content being equally usable on any platform, based on royalty-free standards, and those standards being implementable in free software),” O'Callahan wrote. “We will probably get into a situation where Web video distributors will be desperate for an in-browser strong DRM solution ASAP, and most browser vendors (who don’t care all that much about those principles) will step up to give them whatever they want, leaving Mozilla in another difficult position. I wish I could see a reasonable solution, but right now I can’t. It seems even harder than the codec problem.”

O'Callahan also pointed out in his blog entry that the upcoming release of Windows 8, which will not support browser plugins in its Metro environment, means that the lack of DRM support in standards-based Web video is no longer just a theoretical concern. Microsoft may need to furnish a solution soon, or risk frustrating users who want to watch commercial video content on the Web in Windows 8 without installing additional apps or leaving the Metro shell.

Netflix Stands Behind DASH
Flash evangelists may feel that the limitations of HTML5 video and the problems that content creators are sure to face during the transition are a vindication of the proprietary plugin model. But the advantages of a truly open, vendor-neutral, and standards-based video solution that can span every screen really dwarf the challenges. That is why major stakeholders are going to be willing to gather around the table to try find a way to make it work.

Netflix already uses HTML5 to build the user interfaces of some of its embedded applications, including the one on the PS3. The company has soundly praised the strengths of a standards-based Web technology stack and has found that there are many advantages. But the DRM issue and the lack of suitably robust support for adaptive streaming have prevented Netflix from dropping its Silverlight-based player in regular Web browsers.

The company has committed to participating in the effort to make HTML5 a viable choice for all video streaming. Netflix believes that the new Dynamic Adaptive Streaming over HTTP (DASH) standard being devised by the Motion Picture Experts Group (MPEG) will address many of the existing challenges and pave the way for ubiquitous adoption of HTML5 for streaming Internet video.

DASH, which is expected to be ratified as an official standard soon, has critical buy-in from many key industry players besides Netflix, including Microsoft and Apple. An early DASH playback implementations is already available as a plugin for the popular VLC video application.

The DASH standard makes video streaming practical over HTTP and addresses the many technical requirements of high-volume streaming companies like Netflix, but it doesn’t directly address the issue of DRM by itself. DASH can be implemented in a manner that is conducive to supporting DRM, however.

DASH and DRM
Ericsson Research, which is involved in the DASH standardization effort, has done some worthwhile preliminary research to evaluate the viability of DRM on DASH. Ericsson produced a proof-of-concept implementation that uses DRM based on the Marlin rights management framework.

Marlin, which was originally created by a coalition of consumer electronics vendors, is relatively open compared to alternate DRM technologies and makes use of many existing open standards. But Marlin is still fundamentally DRM and suffers from many of the same drawbacks, and adopters have to obtain a license from the Marlin Trust Management Organization, which holds the keys.


The architecture of the Marlin rights management framework


Ericsson explains in its research that it chose to experiment with Marlin for their proof-of-concept implementation because it’s available and mature—other similar DRM schemes could also easily be adopted. Existing mainstream DRM schemes would all likely pose the same challenges, however, and it’s unlikely that such solutions will be viewed as acceptable by Mozilla. More significantly, an implementation of HTML5 video that relies on this kind of DRM would undermine some of the key values and advantages of openness that are intrinsic to the open Web.

The ease with which solutions like Marlin can be implemented on top of HTML5 will create pressure for mainstream browser vendors to adopt them quickly. This could result in the same kind of fragmentation that exists today surrounding codecs. As O’Callahan said, it’s easy to see this issue becoming far more contentious and challenging to overcome than the codec issue.

What Next?
The transition to HTML5 and standards-based technology for video delivery will bring many advantages to the Web. There are some great examples that show what can be achieved when developers really capitalize on the strengths of the whole open Web stack. The inclusiveness of the standards process will also give a voice to additional contributors who want to expand the scope of what can be achieved with video on the Web.

There are still some major obstacles that must be overcome in order for the profound potential of standards-based Web video to be fully realized in the post-Flash era. Open standards still don’t deliver all of the functionality that content creators and distributors will require in order to drop their existing dependence on proprietary plugins. Supplying acceptable content protection mechanisms will prove to be a particularly bitter challenge.

Despite the barriers ahead, major video companies like Netflix recognize the significant advantages of HTML5 and are willing to collaborate with other stakeholders to make HTML5 video a success. The big question that remains unanswered is whether that goal can be achieved without compromising the critically important values of the open Web.

By Ryan Paul, Ars Technica

Video Compression Technology: HTML5

A media container is a “wrapper” that contains video, audio and data elements, and can function as a file entity or as an encapsulation method for a live stream. Because container formats are now starting to appear in broadcast situations, both OTA and online, it is useful to consider the various ways that compressed video (and audio) are carried therein, both by RF transmission and by the Internet.

Web Browsing and Broadcasting Crossing Over
The ubiquitous Web browser is a tool that users have come to rely on for accessing the Internet. Broadcasters already make use of this for their online presence, by authoring content and repurposing content specifically for Internet consumption. But browsing capability is something that will come to OTA broadcast as well, once features like non-real-time (NRT) content distribution become implemented. For example, by using the ATSC NRT specification, now under development, television receivers can be built that support different compression formats for cached video, including AVC video and MP3 audio, and different container file formats, such as the MP4 Multimedia Container Format. It is envisioned that these receivers will have the capability of acting as integrated live-and-cached content managers, and this will invariably involve support for different containers and codecs. For this reason, we need to understand how browsers and containers — two seemingly different technologies — are related in the way they handle content.

Several container formats currently provide encapsulation for video and audio, including MPEG Transport Stream, Microsoft Advanced Systems Format (ASF), Audio Video Interleave (AVI) and Apple QuickTime. While not a container format per se, the new HTML5 language for browsers nonetheless has the capability of “encapsulating” video and audio for presentation to a user. With the older HTML, there was no convention for playing video and audio on a webpage; most video and audio have been played by the use of plug-ins, which integrate the video with the browser. However, not all browsers support the same plug-ins. HTML5 changes that by specifying a standard way to include video and audio, with video and audio “elements.”

HTML5 is a new specification under development to replace the existing HTML used by Web browsers to present content since 1999. Among the key requirements of HTML5 are that it be device-independent and that it should reduce the need for external plug-ins. Some of the new features in HTML5 include functions for embedding and controlling video and audio, graphics and interactive documents. For example, a “canvas” element using JavaScript allows for dynamic, scriptable rendering of precise 2-D shapes (paths, boxes, circles, etc.) and bitmap images. Other content-specific elements provide more control over text and graphics formatting and placement, much like a word processor, and new form controls support the use of calendars, clocks, e-mail and searching. Most modern browsers already support some of these features.

The HTML5 Working Group includes AOL, Apple, Google, IBM, Microsoft, Mozilla, Nokia, Opera and many other vendors. This working group has garnered support for including multiple video codecs (and container formats) within the specification, such as OGG Theora, Google's VP8 and H.264. However, there is currently no default video codec defined for HTML5. Ideally, the working group thinks that a default video format should have good compression, good image quality and a low processor load when decoding; they would like it to be royalty-free as well.

Multiple Codecs Present Complex Choices
HTML5 thus presents a potential solution to manufacturers and content providers that want to avoid licensed codecs such as Adobe Flash (FLV), while preferring the partially license-free H.264 (i.e., for Internet Broadcast AVC Video), and fully license-free VP8, Theora and other codecs. Flash, which has become popular on the Internet, most often contains video encoded using H.264, Sorenson Spark or On2's VP6 compression. The licensing agent MPEG-LA does not charge royalties for H.264 video delivered to the Internet without charge, but companies that develop products and services that encode and decode H.264 video do pay royalties. Adobe nonetheless provides a free license to the Flash Player decoder.

HTML5 can be thought of as HTML plus Cascading Style Sheets (CSS) plus JavaScript. CSS is a language for describing the presentation of webpages, including colors, layout and fonts. This allows authors to adapt the presentation to different types of devices, such as large screens vs. small screens. Thus, content authored with HTML5 can serve as a “raw template,” and repurposing to different devices entails generating appropriate CSS for each device. (This is known to programmers as separating “structure” from “presentation.”) JavaScript is an implementation of ECMAScript, both of which are scripting languages that allow algorithms to be run on-the-fly in decoders. Because JavaScript code runs locally in a user's browser, the browser can respond to user input quickly, making interaction with an application highly responsive.

Websites often use some form of detection to determine if the user's browser is capable of rendering and using all of the features of the HTML language. Because there is no specific “flag” that indicates browser support of HTML5, JavaScript can be used to check the browser for its functionality and support of specific HTML features. When such a script runs, it can create a global object that is stored locally and can be referenced to determine the supported local features. This way, the content being downloaded can “adapt” itself to the capabilities of different browsers (and decoder hardware). Scripts are not always needed for detection, however. For example, HTML code can be written, without the use of JavaScript, that embeds video into a website using the HTML5 “video” element, falling back to Flash automatically.

HTML5 also provides better support for local offline storage, with two new objects for storing user-associated data on the client (the playback hardware/software): localStorage, which stores data with no time limit, and sessionStorage, which stores data for one session. In the past, personalization data was stored using cookies. However, cookies are not suitable for handling large amounts of data because they are sent to the server every time there is an information request (such as a browser refresh or link access), which makes the operation slow and inefficient. With HTML5, the stored object data is transferred only when a server or client application needs it. Thus, it is possible to store large amounts of data locally without affecting browsing performance. In order to control the exchange of data, especially between different websites, a website can only access data stored by itself. HTML5 uses JavaScript to store and access the data.

Years ago, content developers predicted the crossover of television and Internet. With standard codecs, container formats and specifications like HTML5, integration of the two media will soon be common.

By Aldo Cugnini, Broadcast Engineering

Not Just Mobile: Adobe is Abandoning Flash on TVs as Well

Adobe announced Wednesday that it would be abandoning its work to enable rich applications on mobile devices through Flash, and would be focusing on HTML5 and Adobe AIR apps instead. But at the same time that it was working on bringing Flash video and applications to mobile devices, it was also hoping to bridge the divide between web video and what could be watched on connected TVs. So what happens to those efforts?

While the market for TV apps is incredibly fragmented, it doesn’t appear that Adobe’s Flash will provide a solution. The company confirmed through a statement that like mobile, it will no longer focus on porting the Flash plugin into web browsers on CE devices, but believes developers should build native apps on those devices instead. An Adobe spokesperson writes:

“Adobe will continue to support existing licensees who are planning on supporting Flash Player for web browsing on digital home devices and are using the Flash Player Porting Kit to do so. However we believe the right approach to deliver content on televisions is through applications, not a web browsing experience, and we will continue to encourage the device and content publishing community down that path.”

Adobe’s efforts to bring Flash to connected TVs, Blu-ray players and other devices, like its mobile Flash plans, were part of its Open Screen Project, which aimed to create a consistent app runtime across multiple devices. The idea was that developers would be able to create a Flash application once and be able to distribute it across web browsers, mobile devices and TVs.

Two-and-a-half years ago, Adobe announced a number of partnerships with OEMs and system-on-chip vendors such as Broadcom, Intel, STMicroelectronics, NXP Semiconductors and Sigma Designs to embed the Flash player into their silicon. But the number of TVs and other CE devices that support the Flash player have been limited to those from Sony and Logitech running the Google TV operating system. And Google TV has hardly been a success.

Now, Adobe is taking a step back from those plans, but not abandoning the TV app segment altogether. Instead of pushing multi-screen browser-based Flash applications, Adobe is hoping to convince developers to create native apps on mobile and TV devices using the Adobe AIR framework. Already some developers are taking advantage of that framework, with publishers like CNet, Epix and YouTube building TV apps for Samsung TVs based on Adobe AIR.

By Ryan Lawler, GigaOM

Google TV Porn Powered by HTML5, Not Native Apps

This summary is not available. Please click here to view the post.

Initiatives Promise Efficiency Gains For Multi-Screen Service Operations

While the Internet has yet to become an ideal medium for distributing premium content, the good news is there’s much more to come from technology advances that have already gone a long way toward enabling secure, efficient delivery of high-quality entertainment to devices of all descriptions.

In fact, these advances promise not only much better performance for unmanaged over-the- top (OTT) content; they will also streamline efforts of service providers that are developing hybrid managed services where IP-based content is a critical component of multi-device service strategies.

One key development along these lines is progress toward a unifying standard for adaptive streaming under the auspices of the International Organization for Standards’ Moving Picture Experts Group (ISO-MPEG). The MPEG Dynamic Adaptive Streaming over HTTP (DASH) working group has proposed a solution that does away with maintaining separate manifest formats for the two most prominent streaming platforms on the Web – Apple’s HTTP Live Streaming (HLS) and Microsoft’s Smooth Streaming.

At the same time, Hollywood studios through their electronic sell-through initiatives, including most notably the Digital Entertainment Content Ecosystem’s (DECE) UltraViolet platform, have created mechanisms essential to a more interoperable and consumer-friendly online content marketplace. Along with equipping UltraViolet to provide in-the-cloud support for single user accounts, DECE has specified a common file format for all UltraViolet content together with rigorous certification procedures to enable the supply of content protection from multiple vendors.

The Benefits of Adaptive Rate Streaming
When it comes to delivering long-form video over the Internet and bandwidth-constrained access links, one of the great tools invented to compensate for bandwidth fluctuations and other disruptions is Adaptive Rate Streaming (ARS). ARS dynamically adjusts bit rates to changing network and device conditions so that content is delivered at the highest level of quality that can be sustained at any given time without dropping frames or interrupting the flow for buffering.

Thus, for example, for streams targeted to HD sets, ARS bit rates might support an optimum resolution of 1080p when conditions allow and then drop down to rates suited to lower resolutions such as 780p when conditions would cause the stream to stop and buffer if the higher bit rates were maintained. Different ranges of bit rates can be set for different ranges of resolution, depending on the screen sizes of targeted devices.

ARS is a device-driven “stateless” technology, which means the ARS system must match the ARS mode that is supported by the client software running on any given device. At the initiation of a video streaming session by any user on any device, the device is presented live manifest files that define each of the available bit rate profiles for the chosen content. The device signals which profile should be streamed based on what the available access data rate is on the network and how much processing power is available on the device to handle the video stream.

To accommodate fluctuations in network bandwidth and other conditions, the ARS servers rely on feedback from the device to continually update the bit rate profile throughout the session. Every few seconds another file segment or “chunk” is sent to the device at the requested bit rate.

The two most commonly used ARS modes, Apple’s HLS and Microsoft’s Smooth Streaming, have much in common. They both rely on H.264 encoding to set the bit rates. And they employ HTTP (HyperText Transfer Protocol), the streaming protocol that supports the sequence of client request and server response transactions that are the foundation to communications on the World Wide Web. But they are incompatible because they employ different transport container formats.

HLS uses the MPEG Transport Stream format while Smooth Streaming uses the Fragmented MP4 file format for its chunks. The differences in container file sizes impose different time sequences on the client-server communications of the respective ARS systems.

The DASH Initiative
If these differences could be resolved, the fact that H.264 has emerged as the dominant codec by far in IP video communications would make it possible to fashion an ARS standard that would easily fit into the existing video streaming ecosystem. This is precisely what the MPEG DASH working group is attempting to do.

In October 2010, the DASH platform achieved Committee Draft status with expectations that it will reach Final Draft International Standard status by July 2011. The core of the draft is closely aligned with the mobile industry’s 3GPP Adaptive HTTP Streaming (AHS) specification.

AHS, adopted by 3GPP in March 2010, relies on the ISO Base Media File Format ISO/IEC 14496-12, the basis for the MP4 container, to create a uniform approach to streaming video and audio content to mobile devices. DASH has expanded on AHS (now commonly referred to as 3GP-DASH) to create the means by which clients can order ARS segments from servers that use either MP4 encapsulation or MPEG-TS.

This functionality is accomplished through a server-to-client communications mode that delivers a structured collection of data in a format known as the Media Presentation Description to define various segments within the stream, each of which is associated with a uniquely referenced HTTP URL. Altogether these segments describe how a DASH client can use the information to establish a streaming service for the user.

Thus, DASH has been structured to not only provide the means by which the DASH client can order chunks in MP4 or MPEG-TS mode, but to open standardized means of accessing many other functionalities as well. These include support for live streaming as well as progressive download of on-demand content; fast initial startup and seeking; enhanced trick modes and random access capabilities; dual streams for stereoscopic 3D presentations; Multi-view Video Coding used in Blu-ray 3D displays, and dynamic implementation of diverse protection schemes. The platform is designed to work with any HTTP 1.1-compliant server and to support distribution through regular Web infrastructures such as HTTP-based CDNs. This is critical to scaling a common streaming mode to a mass consumer base through use of the embedded base of server farms associated with CDNs worldwide.

Support for DASH
The fact that Microsoft and Apple have joined a global lineup of major firms to bring coherence to adaptive streaming represents a major step forward in the evolution of IP-based distribution of premium content. In a recent blog, Christian Kaiser, vice president of engineering at Netflix, extolled the progress on DASH, saying it has addressed most of the major points required to facilitate a standardized approach to video streaming in conjunction with use of the video playback facility in HTML5, the new multi-media optimized version of the Web’s HyperText Markup Language.

“Since HTML5 includes a facility to embed video playback (the <video> tag), it seems like a natural next step for us to use it for streaming video playback within our HTML5-based user interfaces,” Kaiser said. “However, as of today, there is no accepted standard for advanced streaming through the <video> tag.”

He said such a standard should define acceptable A/V container formats; audio and video codecs; the streaming protocol to be used (such as HTTP); how the streaming protocol adapts to available bandwidth; a way of conveying information about available streams and other parameters to the streaming player module, and a way of exposing these functionalities into HTML5. Netflix has resolved all but the last of these requirements with its own proprietary technology, he noted.

If Netflix could replace its proprietary solution with a standardized ARS platform that met all these conditions, the company and “any other video streaming service could deliver to a standard browser as a pure HTML5 web application, both on computers and in CE devices with embedded browsers,” Kaiser said. “Consumers would benefit by having a growing number of continually evolving choices available on their devices, just like how the web works today for other types of services.”

In Kaiser’s view, DASH provides a solution that would meet all his criteria, with the exception of the last one pertaining to having a way of tying the standard into the HTML5 <video> tag. He said Netflix is engaging with the community to help achieve this integration. Kaiser noted that Netflix intends by early next year to publish a limited subset of the MPEG DASH standard, which will refine the requirements for premium on-demand streaming services. Critically, he noted, the Netflix profile “will take advantage of hooks included in the DASH standard to integrate the DRM technologies that we need to fulfill our contractual obligations to the content providers, thus covering the sixth item [conveying parameters to the player] on our list.”

The fact that DASH creates a way to readily communicate to devices what the specific DRM parameters are for a given piece of content overcomes a major barrier to scaling availability of premium content cost effectively. Today, a content supplier who wants to provide a greater level of security than is supported on any given ARS platform must take specific steps to secure each targeted device with the appropriate DRM client. DASH will allow any DASH-compliant DRM to be implemented automatically with no need for intervention by the content supplier.

Challenges to DASH
Needless to say, DASH will not immediately eliminate all the chaos surrounding competing ARS platform with their variations in codecs, DRMs and streaming profiles. Notably, it remains to be seen how Adobe will adjust to the new standard, although the firm’s move away from sole reliance on proprietary compression with its embrace of H.264 on Flash 9 and 10 and its implementation of an HTTP-based ARS system on Flash 10.1 points to a more open approach in the future. Most recently Adobe indicated it is preparing to provide means by which broadcasters who publish video in Flash can deliver that video to HLS-equipped devices, including the iPhone and iPad.

Another development moving against the tide of ARS standardization is Google’s WebM initiative, which aims to provide what it says is an open-source alternative to H.264 without relying on HTTP streaming. Google says its Chrome browser will abandon support for H.264 in favor of WebM, although its YouTube videos continue to use H.264-based Flash as well as older VP6 compression in videos based on pre-9.0 versions of Flash. Suppliers of the Firefox and Opera browsers, which have never used H.264, will go to WebM in their latest versions.

WebM uses the VP8 video compression format developed as a successor to VP6 by On2, which Google acquired in 2010. It uses the Vorbis codec for audio, which comes out of an open-source project headed by the Xiph.Org Foundation. The transport container used by WebM is based on the Matroska Multimedia Container, the product of another open-source initiative.

Rather than relying on the chunk-based process used by ARS, WebM employs proprietary techniques in conjunction with variable bit rate encoding to effect rate fluctuations within a continuous stream. Describing WebM as an “untried technology,” Ben Schwartz, CTO of Innovation Consulting, in a white paper produced by Harmonic and Verimatrix, questioned the practicality of the variable bit rate (VBR) alternative to ARS. “It is much harder to benefit from caching with this approach, and head-end scalability might become an area of concern,” Schwartz said.

At this nascent stage, it is hard to say how much traction WebM will gain or even whether it will prove to be as royalty-free as Google would like. In February, MPEG-LA, which manages the H.264 patent pool, issued a call for patents related to VP8 in what appeared to be preparations for an assessment as to what royalties might be due from users of VP8.

Microsoft, while not opposed to WebM, indicated it wants to know how Google will provide protection to WebM users against patent claims before it whole-heartedly embraces WebM in its Internet Explorer browser. While Internet Explorer 9 users who install third-party WebM video support on their Windows operating systems will be able to play WebM video in IE9, IE9 will otherwise play HTML5 video in the H.264 format, because H.264 “is a high-quality and widely used video format that serves the Web very well today,” said Dean Hachamovitch, Microsoft’s corporate vice president for IE.

Writing in a blog posted in February, Hachamovitch cited Microsoft’s experiences with previous efforts to offer its Window Media Video (WMV) compression technology (later standardized by the SCTE as VC-1) on an open-source basis as a strong reason to doubt that patent infringement claims won’t be made against VP8. “Asserting openness is not a legal defense,” Hachamovitch said. “The risk question is a legitimate business concern,” he continued. “There are hundreds if not thousands of patents worldwide that read on video formats and codec technologies. Our experience with trying to release WMV for free and open use, and the subsequent claims against Microsoft, support this history as do the cases against JPEG, GIF, and other formats.”

Microsoft offered to work with Google to resolve the risk issues. “Microsoft is willing to commit that we will never assert any patents on VP8 if Google will make a commitment to indemnify us and all other developers and customers who use VP8 in the future,” Hachamovitch said. “We would only ask that we be able to use those patent rights if we are sued first by somebody else. If Google would prefer a patent pool approach, then we would also agree to join a patent pool for VP8 on reasonable licensing terms so long as Google joins the pool and is able to include all other major providers of playback software and devices.”

Clearly, with wide support and the blessing of Apple and Microsoft, DASH is by far the best hope for creating an ARS template that content distributors worldwide can rely on to ease the pain of providing premium content with acceptable quality of experience across all networks and a broader range of device types. As DASH comes into commercial use, distributors employing advanced protection mechanisms will be able to upgrade their distribution networks for content delivered to any DASH compatible client.

UltraViolet
Another major force for simplifying IP-based content distribution is UltraViolet, the electronic sell-through platform developed by the Digital Entertainment Content Ecosystem (DECE). The consortium of more than 60 companies is driven by major studios, including Sony Pictures Entertainment, Fox, Lionsgate, NBC Universal, Paramount, and Warner Bros. Many of the powerhouses in media distribution, retailing and technology are also involved with DECE, including Adobe, Best Buy, BT, CableLabs, Cisco, Comcast, Cox Communications, HP, Huawei, IBM, Intel, LG Electronics, Liberty Global, Microsoft, Motorola, Netflix, Neustar, Nokia, Panasonic, Philips, Samsung Electronics, Thomson and Toshiba.

Once the UltraViolet ecosystem is operational, which is scheduled to happen this summer, consumers will be able to create a cloud-based account with digital rights locker via one of many UltraViolet service providers or through the UltraViolet website. They will then be able to access and manage all of their UltraViolet entertainment for use on all their devices, regardless of where the content was purchased.

The UltraViolet Digital Rights Locker serves as the hub for this new marketplace. The authentication service and account management system allows consumers to access content from multiple registered devices over multiple service outlets operating on broadband and mobile networks. DECE will provide an open API (Application Programming Interface) that allows any Web-enabled storefront, service or device to integrate access to the digital rights locker into its own consumer offering.

To the extent UltraViolet eventually scales to mass usage, the platform will drive uniform approaches to file formatting and DRM that could become a force for standard practices across the entire IP video ecosystem. The UltraViolet Common File Format can be licensed by any participating company to create a consumer offering that will play on any service or device built to DECE specifications. Content providers will be able to encode and encrypt one file type in portable, standard and high definition modes with assurance their files can be accessed by consumers from home storage or the cloud from any registered device.

By mandating a common encryption format and setting rigorous requirements for certifying DRMs for use in UltraViolet, DECE is taking the guesswork out of DRM selection by content distributors and greatly simplifying their ability to accommodate multiple DRMs. Because the file format establishes where in the file sequence various DRM functionalities must be implemented, the cloud-based and local storage systems are able to implement whatever UltraViolet-certified DRM is appropriate to a given piece of content.

DECE has gone a step further toward streamlining content protection by embracing Marlin as one of the approved DRM systems – one of the true multi-vendor DRM systems in the marketplace today, and also security standard at the heart of the Open IPTV Forum’s open standards efforts. Marlin, originated by Panasonic, Philips, Samsung Electronics, Sony and Intertrust Technologies, establishes sophisticated, uniform processes for managing rights on devices in a way that can be integrated into a flexible commercial revenue security offering.

Marlin, which is gaining traction in many parts of the world, was recently selected by the U.K. YouView initiative (previously known as Project Canvas) as the common protection model for all content distributed through the group’s new YouView video store. YouView will aggregate and deliver catchup and on-demand content from the BBC, Channel Five, ITV, Channel 4, BT, Arqiva and TalkTalk to set-top box devices from a range of CE vendors.

Critically, there’s a direct tie-in between Marlin and DASH insofar as DASH has drawn heavily on the work of the Open IPTV Forum. Thus the fact that Marlin is intrinsically compatible with DASH serves as another step forward in the content industry’s efforts to overcome encumbrances to efficient operations resulting from DRM incompatibilities.

By Steve Christian, Screen Plays

Google Hearts Firefox 4 for WebM Video Support

Some folks at Google are getting ready to celebrate as Firefox 4 quickly moves toward 10 million downloads, despite Firefox competing with Google’s Chrome browser. The reason: One of the new features added to Firefox 4 is support for Google’s open video format WebM. The browser release is the biggest boost for WebM since Google open-sourced the format last May, and it could help WebM to finally go mainstream.

Firefox 4 is the first official release to include WebM support. Beta versions of Firefox 4 have been able to play WebM videos for a number of months, but those were limited to a small group of early adopters. Firefox 3.6, on the other hand, was used by around 25 percent of all web users in February, according to the latest data from Statcounter, and all these users are now prompted to update to this week’s release, which will make their machines WebM-capable.


The implications are even bigger when you look at the overall browser market, which has been divided between browsers supporting open video formats and browsers that don’t. Both Safari and IE don’t support WebM and instead use H.264 for HTML5 video playback.

Google’s Chrome added WebM support last year, and Google decided to discontinue support for H.264 entirely earlier this year. Firefox has never supported H.264, but until recently, only supported the inferior Ogg Theora video format for HTML5 video. Opera was the first browser to add support for WebM earlier last year. Combine those two with Firefox 4, and you’re looking at a significant market share, as Mozilla Open Source Evangelist Chris Blizzard pointed out on the WebM blog:

“Firefox accounts for about 30% market share – or nearly a third of all browser users. When you combine that with Chrome and Opera it means that about 50% of internet users will have access to the high-quality WebM codec over the next few months, following the Firefox 4 adoption curve.”

Numbers like these could convince more web publishers to use WebM, or possibly expand some early tests of the format. One candidate for such a move is YouTube, which has been experimenting with WebM as part of its HTML5 trial. This beta test is currently opt-in, and it’s not widely publicized on YouTube’s website.

However, YouTube has been actively converting much of its catalog to WebM, and in November, had already made 80 percent of its regularly requested videos available in the format. With half the browsers accessing the site being capable of WebM playback soon, there’s little reason why YouTube couldn’t promote the format more aggressively.

By Janko Roettgers, GigaOM

HTML5 - A Game Changer?

HTML (HyperText Markup Language) is the language of the code that sits behind every web page displayed by a browser. You find it on any web page by right-clicking your mouse and selecting View Page Source. Compared to HTML4 which was introduced in 1997, HTML5 introduces many new interesting elements. For example, the HTML5 dictionary includes “canvas” which allows inserting moving graphics that can be used in games and animations.

The HTML5 specification enables the browser to store 1000 times more data than is currently possible, so that it is possible to use web pages even when there is no connection to the Internet. For broadcasters and content providers, the most useful feature is a new capability for the native support of audio and video playback.

HTML5 is not yet fully developed and still lacks a support for many features that are critically important for the content provider: adaptive streaming, digital rights management, advertising and monetisation. In spite of that, it has already been implemented by all major browsers, e.g., Mozilla Firefox, Apple Safari, Google Chrome, Opera and lately Microsoft Internet Explorer 9.

Before the advent of HTML5, in order to get video to play, websites added proprietary programmes (e.g., Adobe Flash and Microsoft Silverlight) and required the users to download “plug-ins” to play them. That made websites more complex and dependent on a plug-in presence in the client device.

HTML5 provides a new <video> tag to play video directly (“natively”) in the browser itself, therefore no third party plug-in is required. Contrary to a plug-in where video is locked away and trapped in a black box, the <video> element can be manipulated flexibly: it can be styled with CSS, resized on hover using CSS transition, it can be tweaked and redisplayed onto <canvas> with JavaScript, etc.

The <video> tag itself is codec agnostic and leaves the browser developer open to support whatever codec they wish. This leaves the door open to the situation where each browser could use a codec of their choice. This could potentially lead to a market fragmentation and indeed to reverting back to the use of proprietary plug-ins. The table below shows which video codecs (embedded in the appropriate containers) are currently supported by the most recent browsers.


Today H.264 is the most widely used video codec in digital broadcasting. In the internet several codecs are being used, the most popular ones being H.264 and WebM/VP8. In today’s convergent environments where the IT, consumer electronics (including mobile) and broadcast worlds are coming together and the borderline between them is blurring, it would be advantageous to consider common audio and video coding for the internet and broadcasting.

Not surprising, broadcasters prefer using H.264 not only for broadcasting but also for internet distribution of video files and streams. The H.264 license issues have been successfully resolved. MPEG LA announced in August 2010 that “H.264 will be royalty-free forever so long as video encoded with the standard is free to end users and delivered via the Internet”. This means that no royalties are required for the H.264 web videos that are delivered free of charge.

However, Google recently decided to discontinue supporting H.264, as it only intends to use “open source, licence-free” codecs such as WebM/VP8. Many experts however, fear that the unresolved WebM “submarine” patent issues might later hit those who have implemented this codec. Google’s decision may force the content providers wishing to target the most popular browsers to produce two video versions, one in H.264 and the other in VP8. As things stand today, Apple and Microsoft will probably continue to support the H.264 codec, whereas Mozilla Firefox, Opera and now Google are likely to support merely WebM/VP8. It is unlikely that these two camps will ever agree on a common approach.

Although some optimists believe that HTML5 signifies the web’s rebirth, many sceptics share the opinion that HTML5 may rise or fall depending on whether or not the browsers are able to reach a consensus on a common native video and audio codec. Unfortunately, the prospects of reaching such consensus seem to be meagre.

By Franc Kozamernik, EBU Tech-i