Archive for the ‘Multimedia’ Category

File Under: HTML5, Multimedia

Netflix Plans to Ditch Silverlight for HTML5

Image: Screenshot/Webmonkey.

Netflix is looking to ditch its Silverlight-based video player for an HTML5 version that would work pretty much anywhere, but HTML5 isn’t quite up to the task just yet, according to the company.

Microsoft has already put Silverlight — once Microsoft’s much-hyped alternative to Adobe’s Flash Player — out to pasture. While Microsoft will continue to support Silverlight for some time, it will be retired come 2021.

That gives Netflix and others eight years to come up with an alternative. For its part Netflix wants to use HTML5, but HTML thus far lacks some key components Netflix needs, namely a way to generate media streams for playback, a cryptography protocol and, most controversially, DRM for streaming media.

All three components are, however, already draft proposals at the W3C and will likely be an official part of HTML before Silverlight disappears. The three things Netflix needs to bring its video player to HTML5 are the Media Source Extensions specification, the Web Cryptography API and the Encrypted Media Extensions specification, better known as DRM for the web.

Netflix has been working with Google to add support for all three — which the company refers to as “HTML5 Premium Video Extensions” — to Chrome and Chrome OS. For now the new Netflix player for Samsung’s Chromebook “uses the Media Source Extensions and Encrypted Media Extensions to adaptively stream protected content.”

Chrome still lacks support for the Web Cryptography API, so Netflix has developed a Pepper Flash plugin to handle that part of the equation for now. Eventually the company plans to remove the Flash element as soon as Chrome lands support for the Cryptography API.

At that point, says the Netflix blog, “we can begin testing our new HTML5 video player on Windows and OS X.”

Mozilla Reconsiders, May Support WebP Image Format

WebP versus JPEG. Click the image to see the full size examples on Google’s WebP comparison page. Image: Google[/caption]

Want your website to load faster? Slim your images. According to the HTTPArchive, images account for roughly 60 percent of total page size. That means the single biggest thing most sites can do to slim down is to shrink their images.

We recently covered how you can cut down your website’s page load times using Google’s image-shrinking WebP format. Unfortunately, one of the downsides to WebP is that only Opera and Chrome support it. But that may be about to change — Firefox is reconsidering its decision to reject WebP.

The change of heart makes sense since most of the objections Firefox developers initially raised about WebP have since been addressed. However, Firefox hasn’t committed to WebP just yet. As Firefox developer Jeff Muizelaar writes on the re-opened bug report, “just to be clear, no decision on adopting WebP has been made. The only thing that has changed is that we’ve just received some more interest from large non-Google web properties which we never really had before.”

Whatever the case, if Firefox does land support for WebP it would help the fledgling format cross the line where more browsers support it than don’t, which tends to be the threshold for wider adoption.

If you’d like to experiment with WebP today, while still providing fallbacks for browsers that don’t support it, be sure to check out our earlier write-up.

File Under: Browsers, Mobile, Multimedia

Mozilla Wants to Put Your Phone Inside Firefox

What if your web browser were also your phone? That’s a future being imagined by Mozilla, Ericsson and AT&T.

Mozilla has combined Firefox’s WebRTC support with Ericsson’s Web Communication Gateway and AT&T’s API Platform to put together a working demo of calls — both voice and video — and text messages all made from within Firefox.

Mozilla’s “WebPhone” is one part Skype, one part Apple’s Messages and all parts web.

The demo builds on previous Mozilla efforts like the recent WebRTC video calling demo with Google, as well as the Firefox Social API demo Mozilla showed off last year (the Social API provides the glue that brings your mobile contact info into Firefox in the video above).

Aside from the cool factor, web-based calling has a potentially huge benefit for users — no more need for your phone. Mozilla’s WebPhone concept would make it possible to call from any device and the person you’re calling would still see your info.

WebPhone also makes it easy to receive calls and messages anywhere. Anyone who’s ever used Apple’s Message app knows that it’s nice to get messages on the desktop, eliminating the need to track down your phone when you’re already in front of a screen. WebPhone would make it possible to not only get messages on whichever device you’re using, but take calls as well.

Indeed what’s most surprising about Mozilla’s WebPhone demo is that AT&T and Ericsson are involved since more than anything they’re participating in a vision of the future where they are little more than pipes for sending data.

If you happen to be in Barcelona Spain for the ongoing Mobile World Congress event you can check out a live demo of WebPhone at the Mozilla booth. For now the rest of us will have to settle for the demo video above.

Stop Squinting at Your Screen Thanks to This Responsive Type Experiment

Tracking Webmonkey. Image: Screenshot/Webmonkey.

Responsive design typically focuses on screen sizes, but that’s just the practical application of the larger goal — making a website function well no matter how or where you are viewing it. The emphasis ultimately is on you, not your device.

Developer Marko Dugonjić takes responsive design’s emphasis on you to new levels of interactivity with his experiment in typesetting by face detection.

Using a very cool JavaScript headtracking library — which taps WebRTC and getUserMedia to access your webcam — Dugonjić’s app calculates how close you are to the screen and adjusts the font size to make text more readable.

To see it in action, head on over to the demo page and grant it permission to use your webcam. For the most useful example, check out the onload-based implementation, but for a better sense of how it works be sure to try the “Realtime” version.

It may not be the most practical experiment and how well it works depends on plenty of factors well beyond the control of the site (how good your eyes are, whether or not you’re wearing your glasses and so on), but it’s not hard to imagine how this could be very useful in some situations — for example, bumping up font-size when your site is displayed on a television.

When you’re done playing with the resizing demo be sure to check out Dugonjić’s more practical and more immediately useful Typetester.

DRM for the Web? Say It Ain’t So

So far it ain’t so, but some form of DRM in HTML is becoming a more likely possibility every day.

The W3C’s HTML Working Group recently decided that a proposal to add DRM to HTML media elements — formally known as the Encrypted Media Extensions proposal — is indeed within its purview and the group will be working on it.

That doesn’t mean that the Encrypted Media Extensions proposal will become a standard as is, but it does up the chances that some sort of DRM system will make its way into HTML.

The Encrypted Media Extensions proposal — which is backed by the likes of Google, Microsoft, Netflix and dozens of other media giants — technically does not add DRM to HTML. Instead it defines a framework for bringing a DRM system, or “protected media content” as the current draft puts it, to the web.

If you think the idea of DRM seems antithetical to the inherently open nature of HTML, you’re not alone. Ian Hickson, former editor of the W3C’s HTML spec, has called the Encrypted Media Extensions proposal “unethical.” Hickson is no longer in charge of the W3C’s HTML spec, but HTML WG member Manu Sporny, has already asked the WG not to publish the first working draft because the “specification does not solve the problem the authors are attempting to solve.”

There are numerous problems with the Encrypted Media Extensions proposal, including the basic fact that, historically, DRM doesn’t work.

Other problems specific to the current draft of the proposal include the fact that it might well be impossible for open source web browsers to implement without relying on closed source components. Then there are the gaping security flaws that would make it trivially easy to defeat the currently defined system.

But Sporny raises a far more ominous objection — that the proposal in its current form does not actually define a DRM system. Instead it proposes a common API, which would most likely lead to a proliferation of DRM plugins. Here’s Sporny’s take:

The EME specification does not specify a DRM scheme in the specification, rather it explains the architecture for a DRM plug-in mechanism. This will lead to plug-in proliferation on the Web. Plugins are something that are detrimental to inter-operability because it is inevitable that the DRM plugin vendors will not be able to support all platforms at all times. So, some people will be able to view content, others will not.

That sounds a lot like the bad old days when you needed Flash, Real Player, Windows Media Player and dozens of other little plugins installed just to watch a video.

That’s a web no user wants to return to.

At the same time there continue to be companies which believe DRM is essential to their bottom line and the web offers no solution. That’s why Flash, Silverlight and other DRM-friendly plugins remain the media players of choice for many content providers.

So the question of DRM on the web boils down to this: should the W3C continue to work on a spec that defines some kind of DRM system or should the interested companies go off and do their own work? For its part the W3C clearly wants to be part of the process, though it remains unclear what, if any, value a standards-based DRM system might have for web users.