Archive for the ‘Multimedia’ Category

File Under: APIs, Multimedia

Google, Mozilla Team Up for Skype-Killing Video Call Demo

Modified WebRTC logo by Tsahi Levent-Levi/Flickr.

Google and Mozilla, erstwhile rivals in the web browser world, have teamed up to show off the power of WebRTC by creating a web-based video chat app — think Skype without Skype.

The demo bypasses a centralized server and instead makes a direct peer-to-peer connection between browsers. The key component of the demo is a set of work-in-progress standards known as WebRTC.

WebRTC is a proposed standard — currently being refined by the W3C — with the goal of providing a web-based set of tools that any device can use to share audio, video and data in real time. It’s still in the early stages, but WebRTC has the potential to supplant Skype, Flash and many device-native apps with web-based alternatives that work on any device.

The app that the Chrome and Firefox teams developed is available on Google Code and there’s a demo app available on Google app engine if you’d like to try it out for yourself. To make it work you’ll need to use either Firefox Nightly or Chrome 25 (currently in the beta channel). In Firefox, you’ll need to go to about:config and set media.peerconnection.enabled to “true.”

Mozilla has previously showed off a demo of WebRTC with it Social API and Chrome has previously used parts of WebRTC for an interactive sand sketching experiment. This latest demo relies on a new WebRTC trick known as RTCPeerConnection, which should arrive in final form in Chrome next month and Firefox around the end of May. The RTCPeerConnection support in both browsers means there’s no need for plugins and developers can rest assured their apps will “just work” across browsers. Together Chrome and Firefox account for just under 60 percent of browsers on the web.

There is of course one other major browser that’s not yet coming to the WebRTC party.

Indeed Microsoft has proposed a WebRTC competitor to the W3C, though thus far little has happened beyond the initial proposal. As it stands now neither WebRTC nor Microsoft’s competing CU-RTC-Web proposal are actual W3C standards, but work is progressing on WebRTC and, with browsers already implementing it in the wild, it stands a much better chance of becoming a standard one day.

It’s still a little early to throw out Skype. For now you’ll have to content yourself with a very cool demo and the tantalizing possibility to one day soon you might not need Skype, Facebook or any other third-party server to chat with friends around the web.

File Under: APIs, Multimedia

Amazon Tackles Web Video With New Conversion Service

Amazon is getting into the web video game with a new video transcoding service aimed at making it easy to build the next YouTube.

Transcoding video is the process of taking a user uploaded video and converting it to a video format that works on the web, typically MP4 and WebM. Consumer video services like YouTube and Vimeo handle this for you behind the scenes. But if you want to actually build the next Vimeo or YouTube you’re going to have transcode video.

Open source tools like ffmpeg simplify the video transcoding process, but require considerable server power to operate at scale. And server power is something Amazon has in spades.

Amazon’s foray into video is hardly the first cloud-powered video transcoding service — Zencoder is another popular service (and runs on Amazon servers) — but Amazon’s offering is marginally cheaper and well-integrated with the company’s other services.

The Amazon Elastic Transcoder works in conjunction with the company’s other cloud offerings like S3 file storage. You send a video from one S3 “bucket” to Transcoder, which then converts it to the formats you need and writes the resulting files to another S3 bucket.

For now the Elastic Transcoder will only output MP4 video containers with Apple-friendly H.264 video and AAC audio. The new Transcoder options in the Amazon Web Services control panel allow you to create various quality presets if, for example, you’re delivering video to both mobile and desktop clients.

As with all Amazon Web Services the new Transcoder has a pay-as-you-go pricing model with rates starting at $0.015 per minute for standard definition video (less than 720p) and $0.030 per minute for HD video. That means transcoding a 10 minute video (the max on YouTube) would cost you $.15 for SD output and $.30 for HD, which sounds cheap until you start looking at transcoding several hundred 10-minute videos a day (200 a day would set you back $60 a day for HD). Amazon’s free usage tier will get you 20 minutes of SD video or 10 minutes of HD video encoded for free each month.

Amazon’s rates are marginally cheaper than Zencoder, which charges $0.020/minute for SD and double that for HD. Zencoder does have a considerable edge when it comes to output format though, offering pretty much anything you’d need for the web, including live streaming, while, at least for now, Amazon’s offering is limited to MP4.

File Under: Browsers, HTML5, Multimedia

Mozilla Brings Native H.264 Video to Desktop Firefox [Updated]

Look Ma, H.264 video in Firefox, no Flash necessary. Image: Screenshot/Webmonkey.

The latest nightly builds of desktop Firefox now support the ubiquitous H.264 video and MP3 codecs. When the current Firefox Nightly arrives in final form later this year, Firefox users will no longer need the Flash plugin to play H.264 web video in Firefox.

Firefox for Android and Firefox OS already support H.264 and MP3, but on the desktop the new H.264 support is, thus far, only available in the Windows 7 Nightly release.

You can grab the latest version of Firefox Nightly from the Nightly downloads page. Once installed head to about:config and turn on the preference media.windows-media-foundation.enabled.

Mozilla long opposed supporting the H.264 codec because it’s patent-encumbered and requires licensing fees. For better or worse it’s also the most popular codec for HTML5 video on the web, which drove Mozilla to take the pragmatic approach and add support to Firefox. Instead of including the codec directly in Firefox, the browser will rely on OS-level tools to play H.264 video.

Eventually all platforms except Windows XP will get OS-native codec support for H.264 video. Windows XP, which lacks OS-level tools for H.264, will continue to use the Flash plugin to play H.264 movies.

Even if you’re not a Windows 7 user there are still a few new tricks in Firefox Nightly, including a revamped downloads panel that’s no longer a separate window (and which bears more than a passing resemblance to what you’ll find in Safari 6) and support for the new CSS scoped style attribute.

[Update: As BWRic points out in the comments below the new downloads window/panel design was actually a Firefox innovation that the Safari team got around to implementing first. You can check out former Firefox UX Lead Alex Limi's original sketches of the overlay window on his blog as well as a follow up post when Safari revealed its take on the design. It's worth noting that Limi's sketches have a nice progress bar in the icon (which Safari adopted as well), which is missing from the current Firefox implementation.]

Firefox’s coming Safari-style downloads window. Image: Screenshot/Webmonkey.

For more on what else is coming in future versions of Firefox, check out the Mozilla blog’s Bleeding Edge and Firefox Development Highlights series.

The Return of the Progressive JPEG

Unlike progressive JPEGs, you just never know what a baseline image is going to be until it loads. Image: rickastley.co.uk

Everything old eventually becomes new again and lately that’s meant a revival of interest in something most web developers probably abandoned long ago — progressive JPEG images.

Progressive JPEGs offer some advantages over their more common “baseline” counterparts, including potentially smaller file sizes and faster perceived load times. But there are trade offs to bear in mind before you start converting your back catalog of images.

If you happened to have missed the pixelated image loads of the circa 1999 web, here’s a brief refresher: There are two primary types of JPEG images, baseline and progressive. These days the vast majority of photos you encounter are baseline JPEGs, which means they start loading with the fully rendered top of the image and then continue to draw in the rest of the image as the data is received.

Progressive JPGs on the other hand load the full photo right off the bat, but with only some of the pixel data. That means the image briefly looks pixelated and then appears to sharpen focus as the rest of the data loads. This was the generally recommended way to optimize images back in the days when 56K dial up was considered smoking fast.

Lately, with mobile devices bringing bandwidth limitations back to the web, there’s been something of a resurgence of interest in progressive JPEGs. The Web Performance Advent Calendar even ran a piece entitled “Progressive JPEGs: a new best practice.” Here’s developer Ann Robson’s take on why you should use progressive JPEGs instead of baseline:

Progressive JPEGs are better because they are faster. Appearing faster is being faster, and perceived speed is more important that actual speed. Even if we are being greedy about what we are trying to deliver, progressive JPEGs give us as much as possible as soon as possible.

If you’re building responsive websites, progressive JPEGs are also appealing because you can avoid the content reflow that happens when baseline images are loaded after text content. With progressive JPEGs, because some data is loaded right off the bat, text doesn’t jump around (you can avoid this for non-responsive images by specifying the image dimensions).

Be sure to read Robson’s full article for some important caveats regarding progressive JPEGs, including the fact that browser support is less than ideal. All browsers will render progressive JPEGs just fine, but many of them — Safari, Mobile Safari, Opera and IE 8 — render progressive images just like baseline JPEGs, meaning there is no speed difference.

Another strike against progressive JPEGs is that they must be rendered multiple times as more data arrives. So while they may be marginally faster and possibly make users feel like the page has loaded faster, they hit the CPU pretty hard. That makes them potentially slower than baseline JPEGs in one of the use cases they’re supposed to be ideal for — underpowered mobile devices.

But perhaps the most questionable aspect of progressive JPEGs is whether or not users actually perceive a fully loaded, but blurry image that eventually comes into focus as faster than an image that takes longer, but renders all at once. Unfortunately I haven’t been able to find any actual usability studies addressing that question. I suspect that how you feel about progressive JPEGs is probably, among other things, a good indicator of how long you’ve been using the web, which is to say that if you’re all-too-familiar with progressive JPEGs from watching them slowly sharpen into focus over painfully slow dialup it’s hard to see them as anything but an annoying anachronism.

So, should you switch to progressive JPEGs? As with most things in web design there is no right answer. First you should look at your site’s stats, see which browser and devices your visitors are using and whether or not those browsers even render progressive JPEGs progressively. Assuming they do and you want to test progressive JPEGs, check out this old, but still very relevant, post from Yahoo YSlow developer Stoyan Stefanov, who has some data on when, where and how to use progressive JPEGs.

Flickr Revamps Site Navigation and ‘Explore’ Page

Flickr’s redesigned Explore page. Image: Flickr

Hot on the heels of its awesome new iPhone app, Flickr has rolled out some changes to its web interface, revamping the navigation bar, which Flickr says makes it easier to get around the site. Flickr has also added the popular “justified” view of photos to the Explore landing page.

The Flickr blog says the changes are rolling out to everyone over the next few days, so if you don’t see them yet just be patient.

While Flickr says the new nav bar is “designed to make browsing Flickr faster and easier,” whether or not that’s true depends a little on which features you frequently use. The new navigation definitely simplifies things, but it does so by moving more than a few menu items off to obscure places. For example, options like browsing through your tags or looking at your collections have been moved out of the “You” menu to “More.” Similarly, the link to log out or get to your new mail have been moved to a new menu hidden in your user icon.

Flickr hasn’t outright deleted most menu items; they’ve just moved them to new locations. Sometimes that’s a good thing — for example, removing the “your” from all the options under a menu already named “You” makes sense — and other times it’s annoying, for example if you frequently browse by tags.

Less confusing is the new Explore page, which adopts the “justified” view that Flickr previously introduced for its Contacts, Favorites and Group Pool pages. The new layout tiles images to fit more photos at larger sizes in a smaller space and makes, well, exploring, more interesting.