Webmonkey » web video

Google Pools WebM Video Supporters for Patent Protection

Scott Gilbertson — Tue, 26 Apr 2011 14:13:53 +0000

Google has announced the new WebM Community Cross License (CCL) initiative. The new group is designed to create a patent-safe haven around Google’s WebM video codec for HTML5 video. Members of the new CCL initiative agree to license any WebM-related patents to each other under royalty-free terms.

The WebM codec is one of several ways web developers can deliver native HTML5 video on the web, without requiring the Flash Player plugin or other proprietary, non-standard tools. The other major codec, H.264, is older and more widespread, but carries expensive licensing fees for broadcasting sites like YouTube.

So far Firefox 4, Opera, Chrome and Internet Explorer 9 (via a plugin) all support the WebM codec. Apple’s Safari and Mobile Safari are the lone holdouts for H.264 (IE9 also supports H.264).

Microsoft, which many suspected would ignore WebM, has thus far remained cautiously supportive of WebM. While the company doesn’t include support out of the box, it has pledged to support users who “install third-party WebM video support on Windows.” Many of Microsoft’s concerns about WebM revolve around unresolved patents and licensing.

Google’s CCL initiative seems geared at least in part to assuage Microsoft’s patent fears, laying out in clear terms how participating companies will handle patents. In short, organizations that join the CCL agree to license any essential patented WebM technologies to other members of the CCL under royalty-free terms, affording each member a measure of protection against potential patent lawsuits.

For the launch Google has put together 16 companies including AMD, Cisco, LG and Samsung, as well as browser makers Opera and Mozilla.

The elephant in the room is the MPEG-LA organization which governs the licensing of the H.264 codec. MPEG-LA recently closed out its call for the submission of patents essential to WebM, but has yet to announce any lawsuits against WebM. That does not of course mean that MPEG-LA has failed to come up with any potential WebM patent violations. In fact, not announcing anything helps build the sense of patent fear, uncertainty and doubt that surrounds WebM at the moment.

But MPEG-LA may have problems of its own. The U.S. Department of Justice is reportedly investigating the group to see whether the organization is trying to stifle competition from Google. Our friends at Ars Technica report that DOJ investigators are “looking into whether MPEG-LA or its member companies (which include Apple and Microsoft) are making an active effort to cripple adoption of WebM.”

While WebM’s future may still be in doubt, Google is clearly pushing forward regardless. The company has already removed H.264 support from its Chrome web browser and recently began serving up WebM videos on YouTube. With the new CCL initiative Google has expanded its range of WebM allies beyond just browser makers and is well on its way to having a patent pool that can back up WebM against MPEG-LA.

See Also:

MPEG LA Starts the Search for VP8 patents

Peter Bright (Ars Technica) — Mon, 14 Feb 2011 17:18:54 +0000

MPEG LA, the one-stop shop for motion video patent licenses, yesterday announced a call for patents essential to the VP8 video compression algorithm — the algorithm that is fundamental to Google’s WebM video format. MPEG LA is asking organizations that hold patents believed to cover integral, unavoidable parts of the VP8 algorithm to come forward and submit those patents to the licensing company. The patents will in turn by analyzed by MPEG LA, and those deemed to be relevant will be pooled together. The pooled patents will then be available to license as a single convenient bundle.

In its promotion of WebM and VP8, Google has insisted that all the relevant patents were developed by codec company On2, which Google purchased last year. The patents can be licensed from Google without payment of any royalties or any restrictions on usage. Google has been heavily promoting WebM for use with the HTML5 tag, which allows plugin-free video to be embedded in webpages, and the royalty freedom is a key part of WebM’s value proposition.

Competitive codecs such as the open and industry standard H.264 require royalties to be paid by software and hardware developers. Companies like Opera and Mozilla, as well as the W3C group that is developing the HTML5 specification, deem these royalties be an unacceptable impediment to their usage. They have no such qualms about the royalty-free WebM.

If MPEG LA is successful in assembling a patent pool, that royalty freedom could come to an end. The company is soliciting patent submissions until March 18th. Once the submissions have been made, it will determine which patents are essential to VP8; only those patents that are unavoidable can form part of the patent pool. The owners of those selected patents will then decide on the license conditions they wish to impose, and these conditions could include royalty payments.

Whether this will happen, of course, is the big question. MPEG LA might fail to form a patent pool altogether: it may receive no relevant patent submissions, in which case the patent pool process will likely end. Such an outcome still won’t mean that WebM is in the clear — a company may feel that it’s more lucrative to avoid a patent pool and allow WebM usage to become more widespread before asserting claims — but it would probably imply that there aren’t dozens of potential claimants just waiting to come forward.

This sort of outcome might well see Microsoft’s current neutral stance towards WebM (it will work in Internet Explorer 9, just as long as a suitable third-party codec is installed) become more overtly positive. Redmond might start shipping a WebM codec of its own, for example.

If MPEG LA does form a patent pool, the license terms will be critical. MPEG LA exists to monetize patents, however, so it’s unlikely that any patent pool would permit the kind of indiscriminate royalty-free license that Google currently offers. More likely, they would choose terms similar in kind to those of H.264; Web video may be free, but decoders still incur a royalty. This would put WebM implementors in a difficult position — either drop WebM support, pay up, or risk going to court to fight a patent infringement suit.

An infringement suit is an unappealing prospect: even if you win, the drain on your financial resources can mean that ultimately, you lose. This is especially problematic for organizations like Mozilla, since Google offers no indemnification for users of WebM — if Mozilla gets sued, Google won’t step in to help. As such, the safest, most conservative option for Opera and Mozilla would be to drop support. Google has deeper pockets and can better sustain a legal attack, but even there, the company has to weigh its options carefully. A lost court case could cost tens of millions of dollars. Paying up just to avoid the problem may very well be the better option.

But paying up is problematic too. VP8 is, for most purposes, inferior in quality to H.264. H.264 is much more widespread in software tools, hardware accelerators, and so on: it’s enormously widespread already. If VP8 loses its key feature — royalty freedom — implementers may very well decide that, since they have to pay anyway, they’d be better off paying for the superior, more widely used H.264 license, and abandoning WebM entirely.

Whatever happens — and it will probably be many months before we find out — this is bad news for WebM. The formation of a patent pool directly undermines Google’s claims about the codec — and yet, even if MPEG LA fails to create a pool, question marks surrounding the codec will remain.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

See Also:

Microsoft Puts H.264 Video Back in Google Chrome, Considers WebM for IE

Scott Gilbertson — Wed, 02 Feb 2011 17:14:57 +0000

Microsoft has announced a plug-in for Google’s Chrome web browser that allows Chrome on Windows to play H.264 web video through the HTML5 tag. The new plug-in comes on the heels of Google’s decision to remove H.264 support from Chrome and focus on the company’s competing WebM video codec.

You can grab the new Chrome plugin from Microsoft. Microsoft previously released a similar H.264 plugin for Firefox, which also only supports WebM video.

The video move is the latest sign of a collision between the two tech giants, who now compete directly in search, courtesy of Microsoft’s Bing initiative and mobile, where Google’s Android is taking market share and the new Windows Phone 7 is struggling for a foothold. Google has also launched various cloud-based applications that take aim at Office. This week, the two threw punches over search, with Google claiming Microsoft copies its results, and Microsoft complaining the Google perpetrated a sting worthy of a spy novel.

Now the two are sparring over web video. Google has thrown its weight behind the WebM codec, which the company owns, while Microsoft supports H.264. However, Microsoft says that, provided Google makes some changes, it may be willing to support the WebM codec as well.

While HTML5′s video tag promises a native way to watch video in your browser, video codec support among browsers is divided. Firefox, Opera and Chrome support the WebM codec while Apple’s Safari and Microsoft’s IE9 support H.264. As it stands there is no “it just works” solution, which means most websites still use Flash video players.

Microsoft’s H.264 plug-ins for Firefox and Chrome are part of the company’s attempt to be pragmatic — since Windows includes native support for H.264, users should be able to watch H.264 video even if the browser doesn’t support it. On the other side of the coin, Internet Explorer 9 will be able to play WebM video through a similar third-party plug-in.

However, while Microsoft isn’t including native support for WebM in the next version of IE, it doesn’t appear to totally rule out the idea. As part of the plugin announcement, Dean Hachamovitch, corporate vice president for Internet Explorer, outlines some of Microsoft’s problems with the WebM codec. The main problem is that Microsoft is concerned about WebM’s potential patent risks.

Google insists that it owns all of the patents covering WebM and the VP8 video codec. But the company offers no indemnification for costs incurred should a patent lawsuit arise. That means that anyone distributing WebM/VP8 could be on the hook for any patent-related fees that might come up.

Some have dismissed Microsoft’s patent worries as an example of Microsoft spreading “fear, uncertainty and doubt” about WebM, but Microsoft does have history on its side in this case. As Hachamovitch points out, such patent lawsuits often don’t arise until a technology is in widespread use. So just because no one is suing over WebM now, doesn’t mean they won’t in the future. Hachamovitch cites the JPEG photo compression format, pointing out that JPEG was around for ten years before the first patent lawsuits appeared. Eventually the patents in question were ruled invalid, but not before millions of dollars were spent defending and licensing JPEG.

Of course the same patent threats potentially hang over H.264, but the MPEG-LA consortium — the governing body that oversees the patents surrounding H.264 — provides a kind of legal buffer between H.264 licensees and any lawsuit.

Surprisingly, Hachamovitch says that, if Google is willing to indemnify WebM users against patent lawsuits, “Microsoft is willing to commit that we will never assert any patents on VP8.” Of course that doesn’t mean other companies won’t, but it would be a huge step forward for WebM if Microsoft jumped on the bandwagon. Google did not respond to a request to comment in time for this story.

For now at least Microsoft has chosen a pragmatic approach — plugins. There will be a WebM plugin for Internet Explorer and H.264 plugins for Firefox and Chrome. In the end, Windows users will be able to watch just about any video on the web regardless of which browser they’re using. It might not be an ideal solution, but it is one that, from the user’s point of view, just works.

See Also:

Google Dropping H.264 Codec from Chrome Browser [Updated]

Scott Gilbertson — Wed, 12 Jan 2011 15:44:28 +0000

Google has rather nonchalantly dropped a bombshell on the web — future versions of the Chrome browser will no longer support the popular H.264 video codec. Instead Google is throwing its hat in with Firefox and Opera, choosing to support the open, royalty-free WebM codec.

Google says the move is meant to “enable open innovation” on the web by ensuring that web video remains royalty-free. While H.264 is widely supported and free for consumers, sites encoding videos — like YouTube — must pay licensing fees to the MPEG Licensing Association, which holds patents on AVC/H.264

Prior to Google’s announcement, the web video codec battle was evenly split — Firefox and Opera supported the open Ogg and WebM codecs, while Safari and Internet Explorer supported H.264. Google took the egalitarian path and supported all three codecs.

Google’s move away from H.264 makes sense given that Google is already heavily invested in WebM. In fact, the only reason the WebM codec exists is because Google purchased On2, the creators of the VP8 codec. Once Google acquired the underlying code it turned around and released VP8 as the open source WebM project.

There’s been considerable outcry from developers concerned that they now need to support two video codecs to get HTML5 video working on their sites. However, given that Firefox — which has a significantly greater market share than Google’s Chrome browser — was never planning to support the H.264 codec, developers were always going to need to support both codes for their sites to work across browsers.

Google’s decision to drop H.264 from Chrome does raise some questions though. For instance, Android also ships with H.264 and so far Google hasn’t made any announcement regarding the future of H.264 on the Android platform. One of the reasons H.264 has become so popular is that the codec enjoys robust hardware support across devices — whether it’s desktop PCs, mobile devices or set top boxes. While WebM has made some strides in hardware acceleration since it was originally released, it still lags well behind H.264. At least for now it seems that Android most likely needs to continue supporting H.264.

The move also raises questions about YouTube, still the largest video site on the web. Currently the site serves H.264 videos to most browsers, whether through the HTML5 version of the site or using the Flash Player. It seems obvious that Google must be hard at work converting the site to use WebM, but will it continue to support H.264 for those browsers and devices that don’t support the WebM codec? So far Google hasn’t made any announcements regarding YouTube and H.264.

Critics of Google’s decision to drop H.264 support in Chrome point out that Chrome ships with Flash, which, like H.264, is not really an open web technology. Indeed it would seem hypocritical for Google to dump some closed tools while keeping others, but, in Chrome’s defense, Flash is well entrenched in the web and ditching it really isn’t practical. Rather Google’s decision seems to be pragmatic — the company is in a position to take a stand on video codecs and it is doing so before H.264 becomes as entrenched as Flash.

[~~Google did not respond to a request for comment on this article.~~ A Google Spokesperson tells Webmonkey that the announcement is related to "Chrome only and does not affect Android or YouTube." Presumably both will continue to offer H.264 support. As for Flash, the Spokeperson says, the Chrome announcement "is about the importance we place on open technologies being the foundation of the emerging web platform moving forward." In other words, dropping Flash support isn't practical.]

See Also:

Pick the Perfect HTML5 Video Player for Your Site

Scott Gilbertson — Thu, 06 Jan 2011 16:40:05 +0000

There’s no question that HTML5 video is at the forefront of the web’s migration to HTML5. Unfortunately converting your site’s video to HTML5 is a little more complicated than just dropping in the video tag.

We’ve covered a few HTML5 video players in the past — SublimeVideo, FlareVideo and the DIY route — but new players seem to emerge every day and deciding which one is right for you can be complicated.

To help you out developer Philip Bräunlich has put together a great chart of 19 different HTML5 video player solutions. The chart breaks down each player, covering options like whether or not there’s a Flash fallback for older browsers, if keyboard shortcuts are supported, how easy it is to theme and use, and what license the code is available under. The sidebar also has links to demos so you can see each player in action.

If you’ve been trying to figure out which video player has everything you need, Bräunlich’s chart should be a huge time saver.

Vimeo Spreads the HTML5 Love With Web-Native Video Player

Scott Gilbertson — Wed, 18 Aug 2010 16:04:57 +0000

Video sharing site Vimeo has taken the HTML5 plunge one step further with a brand new “universal” embeddable player aimed at mobile devices like the iPhone or the iPad.

Vimeo’s new “Universal Player” is actually capable of serving several different kinds of video formats, but it uses a script to check the browser’s video capabilities. Depending on what the browser can handle, Vimeo may display an HTML5 player, a Flash player or a platform-native player. For users, the playback experience and user interface are the same, regardless of the player being used.

The new embed code, now the default throughout the whole Vimeo site, still serves Flash to desktop browsers, reserving the native options for iPad and iPhone users. But eventually, Vimeo plans to let desktop users in on the HTML5 fun — including perhaps serving WebM videos to Firefox, Chrome and Opera users.

So, if you’re reading this post on an iPad or an iPhone, this movie will launch in a native player wrapped inside the browser’s skin:

WORDS from Everynone on Vimeo.

Interest in HTML5 video is reaching a fever pitch. It’s being fueled mostly by the iPad and other mobile browsing devices that can’t play Flash. Also, the recent launch of the new WebM video format, and the HTML5 video capabilities being built into the latest browser releases have publishers and video services exploring non-Flash alternatives for their viewers.

Vimeo’s new player builds on the HTML5 video player the company first launched as a beta project back in January. But the rapid growth of HTML5 video on the web has urged Vimeo to push this new player to the fore. Other video sites, most notably YouTube, have also launched their own site-wide non-Flash experiences in the last few months. But in most cases the only way to use the native web video players is to visit the actual website. Vimeo is the first to offer an embeddable native player by default.

Despite the new browser sniffing code that lurks behind the new embedding methods, we didn’t notice any significant speed difference from the old code, though of course on mobile devices restricted bandwidth and does make for somewhat choppier video playback.

If you’d like to start using the new player, just head over to Vimeo and grab some embed code and drop into your site. Visit the page with a mobile device and you’ll see the new player.

If you’ve got older Vimeo embed code on your site you’ll need to upgrade it, but fortunately Vimeo is offering a handy JavaScript tool that can do the upgrade with a single click. See the Vimeo blog post for more details. For those of you who don’t want to bother with upgrading old code, fear not, the old code will continue to work just fine. It will just serve up the Vimeo Flash Player.

Indeed there are several reasons you might not want to use Vimeo’s new code, the most troublesome being that it uses an HTML iframe to load the player. Since many popular publishing platforms and social networks don’t allow iframes, you may want to stick with the older code. The new player also got off to a bumpy start, some videos we tested worked just fine on our iPhone, others threw various errors. Thankfully, most of the bugs appear to have been solved since the initial announcement Tuesday.

If you’ve been wanting to take advantage of HTML5 video, but still want the ease of uploading that comes from using a video sharing service, Vimeo is currently your best bet. Look for other services to follow suit in the near future.

See Also:

Review: New Features Bring Safari 5 Up to Speed

Michael Calore — Tue, 08 Jun 2010 19:55:05 +0000

Apple released an update to its Safari web browser Monday afternoon. We’ve been testing it for close to a full day, and we’ve found that Safari 5 performs as advertised: It’s faster, more capable and well worth the upgrade.

Safari 5 was launched rather quietly at the end of the first day of the 2010 Worldwide Developer Conference, an event that was dominated by Steve Jobs’ debut of the next iPhone and the new iOS. Safari wasn’t discussed during the morning keynote, but an announcement was made later that afternoon at a web-developer session.

You can download Safari 5 on Apple’s site. Both Mac OS X (Leopard or better) and Windows (XP and up) versions are available.

First up is the speed boost, which is definitely noticeable in GMail, Facebook, our WordPress admin and other sites with lots of “stuff” going on, like Huffington Post. This is thanks to Safari 5′s new Nitro JavaScript engine. This is the same piece of engineering previously named SquirrelFish (we kind of wish they’d kept that name), that powers JavaScript rendering on top of Safari’s WebKit engine. It gives a small bump to page-load times, but the real improvements are seen in page performance. The complex web apps we tested perform with close to zero latency, about as fast as Google Chrome, the most nimble of the major browsers.

For faster page loads, Safari 5 is implementing DNS pre-fetching. Basically, the browser looks at all the links on the page you’re currently on and fetches the IP addresses of all the linked sites and page assets, preparing itself to make the jump more quickly as soon as you click on a link and begin loading another page. All of this happens in the background. Google Chrome and Firefox do this, too.

There’s added support for various pieces of the HTML5 stack in Safari 5, as well as more support for CSS 3 and other technologies powering modern web apps. According to Apple’s overview page, Safari 5 supports geolocation, sectioning elements, drag and drop, HTML5 form validation, Ruby, AJAX History, EventSource and WebSocket. We can’t tell which version of WebSocket is being supported — typing javascript:alert('WebSocket' in window) into the URL bar just tells us “True,” but nothing else.

At any rate, all of these new features are great to see, as Firefox, Chrome and Opera have supported most or all of these APIs and technologies for a while, and IE9 will support most of them. It also washes away some of the bitter aftertaste left by last week’s PR mess around HTML5 support.

There’s also support for full-screen playback of H.264 videos, and for subtitles — the screenshot at the top shows YouTube’s H.264 player. Apple is touting this as HTML5 video support, but we’d like to point out that while H.264 does make up the bulk of online video, HTML5 doesn’t require videos be H.264. All the other major browsers are backing the new, open source WebM format for video, which we’ve urged Apple to support as well.

One of the most talked-about new features is Safari Reader. A small gray “Reader” button now appears in the URL bar when you land on a news website or blog. Click it, and Safari strips out all of the clutter on the page (ads, widgets, sidebars, headers and footers) and presents just the text in a large typeface, cleanly formatted in a white window that floats, lightbox-style, over a darkened page. It also strings multipage articles together in the same window automatically. It’s intriguing to speculate about how Reader, if widely adopted, will change website-design principles by encouraging cleaner, more readable layouts. Scott Gilbertson explores this idea in detail in his in-depth look at Safari Reader here on Webmonkey.

There’s also an extensions manager in Safari 5. Here, Apple is taking a page from the books of Chrome Extensions and Mozilla Jetpack by offering developers a lightweight browser-extension framework that runs add-ons written in HTML, JavaScript and CSS. This makes it much easier for developers to get started writing extensions, and it makes it easier for authors to port an extension from one browser to another. It limits what the extension can do to mostly manipulating DOM events or the browser UI, but that should be enough for almost any goal. Safari 5 extensions are sandboxed, too. You know, to protect the kids.

There’s an application form you have to fill out if you want to make and distribute Safari extensions. Go to the Safari Developer Program site and enroll for free. Apple will give you a certificate that must be used to sign your extensions.

You can distribute your extensions however you want, but they must be signed. This is to assure users that when they download an extension or receive an update notification, they’re downloading a package from a certified Apple developer and not some nefarious prankster.

A couple of sticking points.

First, the URL bar in Safari 5 is smarter — it does full-text searches of page titles and URLs in your history and bookmarks now — but it’s not smart enough. Other browsers have moved to a unified URL bar that serves as a location bar and a web search input field, and anything else just feels confusing at this point. Hopefully, somebody will write an extension to fix this. Until then, we have to do our web searches in the dedicated search field off to the right, which now includes Bing as a preset choice along with Google and Yahoo.

Second, the status bar (as always with Safari) is invisible by default. You have to manually turn it on under the View menu. I’ve always argued against this practice. A browser that doesn’t supply a visual link destination for each and every click is an insecure browser. I just don’t trust those bullies out there on the web, and neither should you.

See Also:

Report: Google Will Release VP8 Video Codec Under an Open Source License

Michael Calore — Tue, 13 Apr 2010 00:35:23 +0000

We may finally have a solution to help open video out of the morass its currently stuck in. Recently, all eyes have been on Google to see if it would open up the VP8 video codec, which it very recently bought the rights to when it acquired software maker On2.

According to NewTeeVee, Google is stepping up to the plate.

Google will soon make its VP8 video codec open source, we’ve learned from multiple sources. The company is scheduled to officially announce the release at its Google I/O developers conference next month, a source with knowledge of the announcement said. And with that release, Mozilla — maker of the Firefox browser — and Google Chrome are expected to also announce support for HTML5 video playback using the new open codec.

If this actually happens, open video will get a huge boost on the web. It will take a few years for VP8 to gain dominance, given the huge penetration of Flash and H.264, but it’s a significant step forward. Since Google owns YouTube, a major game piece is already in play.

One big question remains — will VP8 videos play on the iPad and iPhone?

See Also: