something in the way

a tumblog about design + code
Feb 10

WebGL in Chrome, Experiments Shows OpenGL in the Browser; What It Is, What It’s Not

Media_httpcreatedigit_xpern

Mmmmmm … multi-dimensional. Photo (CC-BY) fdecomite

Attention, 3D fans: OpenGL in the browser has gradually gotten real. WebGL is a browser-friendly API for OpenGL graphics, and it’s pretty darned close to OpenGL ES 2.0, which in turn will be familiar to anyone doing modern mobile 3D development. WebGL isn’t part of HTML5, but HTML5 makes it possible: the Canvas element is what allows WebGL to work its magic. And WebGL goes nicely with technologies that are part of HTML5 or modern browser experiments, including the web audio API and browser video support. (The superb 20 Things I Learned About Browsers & The Web has a 3D in the browser section, well worth reading.) And you can use JavaScript (among other modern languages) to code 3D creations.

If you love the idea of sharing 3D as easily as a webpage, this is big news. It’s a huge step forward from the clunky, unpredictable, confusing use of Java for browser OpenGL, and unlike that solution, it’s part of the page on which it’s delivered, not part of a plug-in or launched app.

In recent days, we’ve seen the first stable browser with WebGL enabled by default, Google Chrome. Right now, Chrome or Firefox 4 beta are likely the easiest and most stable way to test WebGL graphics. I’ve been testing Firefox 4 beta on Linux and more recently the stable Chrome on Mac, Windows, and Linux, and it’s pretty fantastic.

Read Google’s announcement from Thursday, along with the other enhancements to Chrome:
A dash of speed, 3D and apps

Perhaps more exciting than the Chrome update is the superb Chrome Experiments, which recently added 3D goodness, from creative tools to eye candy to useful tools like an exploration of human anatomy:
WebGL Experiments

Grabbing the latest Chrome or installing Firefox beta will let you see them, but here are a couple of picks are a cool place to start, and have videos attached if you aren’t near a bleeding-edge browser:

http://www.chromeexperiments.com/detail/webgl-aquarium/?f=webgl”>WebGL Aquarium, Human Engines and Gregg Tavares

Field, Gregg Tavares

I’m pretty impressed with performance of experiments like the aquarium. I’m on a fairly low-end, last generation laptop with an NVIDIA 9500M, and they run easily.

WebGL is still early in development – Chrome is the first and only stable browser with support – but we’re getting to the phase when you could actually distribute stuff with it, and it could hit prime time very soon.

Which browsers support WebGL?

Chrome’s release is a very big deal. As I write this, WebGL is available in:

  • Chrome stable, from now on
  • Firefox 4.0b8 and later, meaning once Firefox 4 stable is shipped, stable Firefox, too
  • Nightly builds of Safari/WebKit (which I believe includes both Mac and Windows support, though I haven’t tested on Windows)

Opera plans support, but no public build is available yet.

Microsoft appears not to be planning support for IE9, meaning it’s most likely to be odd man out … again. But you can get support for WebGL inside IE using the free Chrome Frame plug-in.

Really, if you want to try this out, installing Chrome is a good idea. It’s also no accident that Google’s Chrome Web App store means people with interesting creations have an avenue for distribution, which should soon also be true with an open Mozilla-based store for Firefox et al.

http://www.khronos.org/webgl/

Can you use Processing.js with WebGL?

Yes! Processing.js is actually a pretty decent way to fiddle around with it. The caveat is that WebGL support in Processing.js is a work in progress; if you want to get deeper, you’ll probably want to get into direct JavaScript control of WebGL. But that hasn’t stopped people from making some interesting hacks and work, and it’s a great place to start. Some demos –

A Processing.js Web IDE that uses WebGL:

– and a stunning music visualizer we’ve seen here before:

What about Google’s O3D?

O3D is some impressive technology and for many of us was the first truly compelling vision of 3D in a browser. The downside – it’s currently a plug-in. But Google does sometimes live up to their “open Web” hype. They’ve said they’re focused on improving WebGL, and that they’ll take the ideas from O3D (like its scene graph) and port to JavaScript and WebGL. There’s even an early version of the work.

It’s worth reading the (official Google) Chromium blog on the matter, partly to see how they’ve come around on JavaScript performance.

The future of O3D

Why wouldn’t you use WebGL?

This is all compelling stuff, so let’s all abandon everything we’re doing and switch to WebGL — right? Well, not necessarily:

  • It’s not done yet. WebGL the spec appears pretty stable, but browser support is still forthcoming. When we (presumably) see stable Safari and Firefox builds in the near term, though, I think the whole thing will get a lot bigger.
  • Universal browser support is a long ways off. Microsoft’s lack of support in IE could be a side effect of the lack of universal OpenGL drivers on the Windows platform. Whatever the reason, count out IE. And likewise, count out anyone with a capable GPU card. Even compared to the mess of video support, 3D is likely to be a “nice-to-have” feature on the Web, not the universal feature the traditional 2D page is.
  • Mobile WebGL isn’t even on the table yet. So, JavaScript – yep, it’s faster on desktop computers. But mobile implementations are still evolving, mobile browsers still lag their desktop counterparts (even sometimes when they’re both based on the same Web engine, like WebKit), and performance on much less-capable mobile chips isn’t there just yet. That said, see the last bullet in this list…
  • Live visuals, art will still often need “native” tools. Want to output to a second monitor, or monitors, plural? Doing something crazy like routing textures between apps? Live visualists are pushing the kinds of features that won’t be accessible immediately on the browser.
  • Full-blown OpenGL isn’t available. OpenGL ES 2 is pretty great, but if you need the full OpenGL API, this isn’t designed to be that. And…
  • Performance is still better with C/C++. Don’t get me wrong – performance with JavaScript is stunningly good, good enough that those Google engineers changed their assessment. But it seems to me this depends on your goals. If you’re really concerned with squeezing every last ounce of performance out of your graphics, necessary if your work is about visuals with greater complexity, this still really isn’t for you.
  • This isn’t an either/or choice – OpenGL wins! Here’s the major point for me. You don’t have to choose WebGL as an exclusive solution, partly because you don’t have to choose WebGL. Invest your time in OpenGL, and learn the basic nuances when comparing, say, OpenGL 3.2 on the desktop to OpenGL ES 2 on Android and iOS to WebGL in the browser, and you can be everywhere with relatively minor adjustments.

What’s surprising to me just writing that list is, while it appears long, the advantages of WebGL are still clear, and it makes sense that some of these differences will disappear. I imagine we will still need desktop software. Google, while characterized as some sort of browser-only religion, themselves continue adding native support in their Android platform, so presumably they understand game developers and other parties want that native OpenGL access. The question may not be whether WebGL “replaces” those tools, but whether people find smarter workflows and integrated higher-level APIs to work across the platforms.

Let’s sum it up this way: if you love 3D, and if you’re an OpenGL nerd, you’re in very happy times, indeed.

And regardless, you get to watch a cool jellyfish in Chrome any time you need to unwind.

http://www.khronos.org/webgl/
http://planet-webgl.org/

Media_httpfeedsfeedbu_fuhyz
Media_httpfeedsfeedbu_fbqni
Dec 17

WebGL Will Be Part of Chrome 9 Regular Releases

Good news for the beginning of hardware accelerating the web, WebGL will now be part of the main Chrome releases not just a compile option for Chromium nightlies.

Google Chrome 9 enables WebGL support by default. “WebGL is a new web technology that brings hardware-accelerated 3D graphics to the browser without installing additional software” and it can be used to create cool applications like Google Body BrowserFieldAquarium and more.

The update for Chrome 9 also sandboxes Flash, WebGL and plugins like extensions and tabs so that using them will be more secure and not crash the browser or the tab. Hopefully Safari has this soon, and then a few years from now IE may get it. Or they will put out their own DirectX web plugin so everyone has to write it twice like currently in game development. /sarcasm

Media_httpfeedsfeedbu_vujei
Dec 2

Ben the Bodyguard

Visit this page, and scroll. That is all.

Media_httpfeedsfeedbu_dgeob
Nov 29

Google Translate Beatboxing

Media_httpcreatedigit_jbwjb

Google Translate’s pronunciations may or may not impress you, but the thing’s got some beatboxing skills. Reddit user harrichr notes a fun result:

1) Go to Google Translate
2) Set the translator to translate German to German
3) Copy + paste the following into the translate box: pv zk pv pv zk pv zk kz zk pv pv pv zk pv zk zk pzk pzk pvzkpkzvpvzk kkkkkk bsch
4) Click “listen”
5) Be amazed

Media_httpcreatedigit_emqlf

Does it count as beatboxing if the voice is non-human? (Okay, okay, yeah, you could do this on your own with just about anything by slicing off the plosives on words. But if you’re procrastinating on this Monday workday, it’ll seem utterly amazing. And don’t be surprised if Google takes over beatboxing, just like everything else. Thanks, vade!)

More variants: check out comments.

Media_httpfeedsfeedbu_dkcjz
Aug 20

Nibbble — This is how I browse dribbble on my iPad

Media_httpbeautifulpi_absuv

I just saw it, but I already know this is it. Ever since the dribbble api opened up, we’ve heard of so many clients, it’s almost the new twitter client. Well here’s nibbble, an iPad web application based around the dribbble api, created by Nial Giacomelli (@nialgiacomelli). Nial is the same designer who created the “Showtime” web app for the iPhone some time back, so he’s obviously upgraded on this one.

nibbble is so fluid, you’d be wondering why you even need a dedicated native app on your iPad. Beautiful grids of ’shots’, tap to see the author, and tap to show the shot in a lightbox. It cuts out the comments and other dribbbely features, and is purely a way of browsing images. Best of all, it’s free.

UPDATE: I’m told it also works on the iPhone — one image at a time.

[thanks @nawong for sharing it with us]

Media_httpfeedsfeedbu_jwbgl
May 27

Browser Madness: 3D Music Mountainscapes, Web-Based Pd Patching

“The hills are alive /
with the sound of browsers”

Ever thought you’d make sounds in a browser, or have new ways of visualizing music playback? It’s happening, with builds of Firefox anyone can download.

Work to make browsers rich with sound synthesis and visualization continues. “Compatibility” isn’t really an advantage yet, because Firefox is the only browser with support, and only in the next version, though that could change in the future. And yes, Flash is capable of some of this, too (though not real 3D), with 90-95% saturation, conservatively, of computers. But if not compatibility, what these experiments do represent is what happens when someone working on a tool (Firefox, in this case) really commits to making sound a priority, and supporting free standards and developer tools (an emerging standard API, WebGL, Processing.js, etc.).

In fact, it’d be great if this occurred everywhere: if you’re making a platform, make sound a priority, and people will do mind-blowing stuff with your platform.

Among the latest fruits:

1. 3D eye candy. Charles Cliffe has a psychedelic visualization of sound playback. The JavaScript nuts are also proceeding to do more things with their language than most would deem possible, even moving DSP calculations to JavaScript code. I remain a bit skeptical there: the question to me isn’t whether JavaScript is “fast enough,” but whether native code is faster or simply the better tool for some jobs. Details below.

2. Patching in a browser – with a Pd clone. Chris McCormick is porting a subset of basic Pd objects to the browser. Now, one side of me wonders whether Pd is the best choice; it’s a somewhat idiosyncratic, if powerful, language for describing sound patching. But on the other hand, I could see this being fantastic in teaching and sharing: put basic patches up in a browser, let people play with them live, then build more advanced tools (with greater hardware access and external support than is possible in a browse) in the traditional Pd tool. As I keep saying, I think there’s far too much partisanship in the discussion (“Browsers for everything!” / “Browsers are useless!”), far too little thinking about how the browser and the desktop tool are more powerful together.

Web Audio Data API – Pure Data and Processing.js from David Humphrey on Vimeo.

Check out:
mccormick.cx/dev/webpd/
wiki.mozilla.org/Audio_Data_API

Also — heck, I may try this out in workshops as soon as next week. The browser could build a basic language for music and visuals in Processing and Pd, then robust performance tools could be built in the native tools, with quite a lot of compatibility between the two.

3. Actual standards. The W3C, the standards body behind HTML, has added this discussion to an Audio Incubator group. (It’s been incubating for some time, but maybe this will help something actually hatch.) Now I’d just like to see these things in Chrome/Chromium, too – I wonder if anyone’s up to a test build, as the standards adoption discussion continues. A number of readers have pointed out that MPEG4 had a specification that included, wholesale evidently, Csound. But this process seems more organic to me – you need actual tools and real-world experiments to evaluate the validity of something, not just standards on paper.

Putting the Awesomeness in Context: An Appeal

A side rant, though: why do Web geeks only care about what happens in the browser? It’s funny to me it seems that outlets like Slashdot jump on stories like browser-based tools, but ignore exactly the same ideas if they’re in a separate app. That’s not a criticism of the Mozilla crew or these brilliant hackers – this is what development is all about, pushing your tools to the limits. But if there isn’t a broader recognition of the value of what you’re doing or why you’re doing it in the first place, there’s a danger that unsustainable tool fetish will miss the point. That is, synthesis in the browser is excellent, but if people don’t understand the value of the synthesis itself, we have a lot more work to do.

Even the tools themselves need a context. It also JavaScript is amazing, but so are tools in Python, Java, Scala, and so on… and some of the enduring power of C still shows here. Browser powers are cool, but the OS is just as important – performance of Firefox would be heavily dependent on support for OS-native, low-latency audio outputs, like JACK on Linux. (Yes, it’s open source, so you can go do it yourself. No, I have no idea how to build Firefox for JACK – maybe a reader does?)

I’ve still yet to see a compelling explanation of what the browser really is, and what’s possible with its interface paradigm. That should be a fascinating discussion, actually, especially with the radical transformation of the browser, particularly as players like Google make it the central aspect of TV-watching or tablet experiences. But the discussion is only really interesting if you don’t start out with the value as a given. For instance, if browsers become a bigger part of what we do, is its simplistic tab metaphor really sufficient? If browsers simply bundle a set of native tools, are there ways “standalone” apps might adopt similar, standards-based approaches?

David Humphrey argues that part of the value here is the view source concept, but the Web has had the same empowering influence on sharing, collaboration, and reuse with platforms other than just JavaScript. The browser itself is a largely misunderstood piece of technology, partly because users (understandably) focus on their experience, and doesn’t pay attention to which aspects are delivered by the browser, the OS, or some other piece of code.

Oh, side note: this isn’t about “the cloud.” The cool stuff here is happening on your local hardware, period. That’s what makes it fast, and that’s what makes it work for audio, and your local machine is getting cheaper, cooler, and less power-hungry all the time. New DSP and floating-point capabilities in devices like tablets could make sound more powerful and flexible than ever before – provided people work out how to maximize, not squander, those capabilities.

So, here’s what I’d like to ask: what form will the standards discussion take? And how can these larger discussions – many of which transcend the discussion of any one tool or standard – find a forum?

Behind the Scenes, More Info

While you ponder that (and I’m open to suggestions), here’s more reading for you:
Experiments with audio, part X [Dave Humphrey's increasingly-awesome blog]

Previously:
Real Sound Synthesis, Now in the Browser; Possible New Standard?

More details on the first example, and how it was built (Minefield is Firefox 3.7):

All runs in real-time with Javascript, WebGL and HTML5 only (uses Minefield Audio build) — no browser plugins are used.

This demo combines the CubicVR 3D engine on WebGL (www.cubicvr.org) with the Mozilla HTML5 Audio API (hacks.mozilla.org), Processing.js (www.processingjs.org) and BeatDetektor.js (www.beatdetektor.com)

Mozilla Audio API is used to sample the HTML5 audio tag on the page, this information is processed by BeatDetektor.js which produces timing information for the Processing.js real-time canvas textures and the CubicVR.js procedurally generated WebGL scene using them.

The camera is set to free roam a simple chase pattern with a probability to follow a nearby cube (fully automated).

Available online at:

http://cubicvr.org/CubicVR.js/bd3/BeatDetektor3HD.html

or if you have a Float32Array enabled Minefield build:

http://cubicvr.org/CubicVR.js/bd3/Bea…

you can find more info about audio api-enabled Minefield builds at:

https://wiki.mozilla.org/Audio_Data_API

You can also feel free to chat with us about the Audio API via the #audio channel on irc.mozilla.org

Enjoy! And yes, I’ll have to work out a more beginner-friendly, here’s how to do this post.

Media_httpfeedsfeedbu_cejph
Apr 30

Apple Scores Easy Points Against Flash, But Throws Debate on Openness Off the Rails

Media_httpcreatedigit_yfdah

Photo (CC-BY) Steven Depolo.

Editorial

Misdirection is an art practiced by magicians by which an audience’s attention is diverted from one place to another. What’s brilliant about it is that it’s not a lie. Indeed, the audience has to participate for it to work. We, the audience, watch the right hand instead of the left, because what the right hand is doing seems more interesting. The left hand is still there, in plain sight; if anyone bothered to look, they’d see the trick.

After months of obsessive campaigning, Apple scored the final blow with Jobs’ “Thoughts on Flash”. The firm has reduced important debates over open development, censorship on devices, and the future of Web standards into a simplistic dunking booth contest with Flash as the target. Adobe’s CEO called the debate a smokescreen. Adobe has their own biases; they want to direct attention away from the possibility that their flagship product stands to lose market share in the shakeup over the future of the Web. But that’s Adobe and Apple. What matters more is that the rest of the technological sphere has gotten dragged into a pro-Flash, anti-Flash debate. Watching that devolve over the course of yesterday was painful, and it’s time to say something.

It’s a false debate, because it’s clear that Flash’s role in the future isn’t exactly what it was in the past. Flash has traditionally done two things: it’s been a common-denominator solution for video, and a cross-platform development framework for interactivity, animation, gaming, and other “rich” application experiences. It’s recently done those two things in the absence of any solid alternative. In the browser, the bottom line is that open Web standards are finally able to accomplish many if not most of those goals, not only for video but for interactive animation and drawing. That doesn’t mean the end of Flash development: Flash is used for everything from rich client apps outside the browser to animated television on the Cartoon Network. But it does mean a different landscape.

Focusing entirely on that issue, however – as Apple apparently dearly hopes you will do – misses other, more fundamental issues.

The irony here is, I agree with most of what Jobs said — about Flash. (I expect a lot of you are with me.) But this isn’t just about Flash. It’s not just about the iPhone and the iPad (least of which once you start using “the future of the Web” as the catchphrase.) And it’s what Jobs and Apple aren’t saying that bothers me most. Whether the misdirection is intentional or not, whether Jobs’ thoughts are heartfelt (I believe they are), that doesn’t matter. There’s a danger here of losing the plot by allowing Apple to control the whole debate.

There are serious concerns about whether Apple’s path, limiting the tools developers use and what applications can say, is the right course for digital expression. And there are real concerns about the future of video standards, and whether those will give the Internet the freedom with video that it’s had with text, images, and sound. Each of those issues is far deeper than whether or not Flash sucks.

Talking about Flash, but slamming all cross-platform development

Scoring points against Flash and its issues with reliability and performance is an easy matter. But Apple isn’t just suggesting Flash is a poor alternative. They’re blocking development with other tools, restricting developers from using other tools on their single-vendor store. Apple knows better, developers, what you should do. And Jobs goes further, to argue all cross-platform development libraries, in effect, are bad:

We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

This becomes even worse if the third party is supplying a cross platform development tool.

What does that mean, exactly? When is a “layer” of software “between the platform and the developer”? Jobs’ “Thoughts” still don’t offer an explanation of an issue that has confused and troubled even some of Apple’s most loyal developers. The nearest translation I can work out is that Apple doesn’t like anyone using tools other than their own.

It’s a big deal, too. Complaining about such tools is one thing. But Apple has promised – and delivered on that promise – to weed out even high-quality apps just for the sin of using such tools.

In case there’s any doubt about how sweeping this generalization on cross-platform tools, and how divergent Jobs’ thinking is from actual developer realities, read on:

Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.

The problem is, even Apple themselves don’t necessarily live up to the same standard. It took Snow Leopard for Apple to fully “adopt” Cocoa technology in the OS, and Apple’s pro apps have only just become fully Cocoa-based and 64-bit. Aside from illustrating that Jobs is sometimes unencumbered by reality in his arguments, this raises questions about the underlying thesis, that supporting cross-platform development means that you support a lowest common denominator and nothing else.

Incidentally, while its developers have assured me they’re safe, the logic itself flies in the face of even simple tools for artists like OpenFrameworks, which because of how it’s architected as a cross-platform development tool that could target the iPhone alongside a Linux desktop, or any number of other combinations. That’s just the sort of compatibility and portability I would think you’d want for creative expression and development, but the gist of Jobs’ entire rant in “Thoughts on Flash” is the opposite: proprietary, platform-specific development is always better. Apple wants apps on their platform, and not elsewhere. I can’t blame Apple, but I do have to question whether the rest of us need to accept the logic. Jobs is really clear on this point:

Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.

Of course, “everyone” wins only if they spend their cash at the Apple ecosystem. And there are casualties: while Apple makes a great case against Flash, they have less of a case against tools like the Scratch viewer, a teaching tool that allows kids to develop on desktops using kid-friendly programming schools and run their creations on the device.

Now, if this only applied to tools, it wouldn’t be so bad. Unfortunately, a topic Jobs doesn’t mention at all is why Apple is blocking certain ideas from its store, too.

Talking about Flash, but not talking about censorship

Can you say “slippery slope”? Apple’s “Thoughts on Flash” do nothing to explain how the single-vendor control of the iTunes store has apparently made Apple feel responsible for anything delivered on their device. Yes, it’s true, game systems suffer from the same (often worse) restrictions, though I’m not arguing that’s a good idea, either. The issue is drawn into sharp relief because of the number of apps and number of developers on Apple’s mobile platforms – more so as it appears this could be the future of development. (It’s telling to me that Apple is awarding only iPhone and iPad developers its coveted Apple Design Awards this year at the WWDC developer conference.)

Apple already eroded free speech on their platform by blocking pictures of people in bikinis and other PG-rated, suggestive content. As with any censorship, what makes this a dangerously slippery slope is that it mandates double standards. One bikini app is blocked, while another (Sports Illustrated) is fine. [PC World]

Banning bikinis seems overly Puritanical enough. But we were reminded that free speech is at issue this month with the case of Pulitzer Prize-winning political cartoonist Mark Fiore. The very definition of a “slippery slope” is this: once you begin blocking some things, what’s to stop you from seriously impeding free communication. The fact that the browser remains open to any content you like, including hard-core (or potentially even illegal) porn, only illustrates how pointless this whole exercise is.

If application development is important, and not just what’s in the browser, then free expression in applications ought to be important. And as for the one argument Jobs has made on the subject, that “if you want porn, buy an Android,” here’s an experiment for you. Try searching for “porn” or “naked” on the Android Market. I did, to see if in fact Jobs was right and my Droid had become a smutty wasteland. You’ll find almost nothing there. What is there has, most often, one or two stars and a lot of negative reviews. In other words, democracy wins.

So, Jobs didn’t address the fundamental issues of how development works on his company’s devices. But he did score some points against Flash in the “open” battle over the Web and video, right?

The problem is, he didn’t really address the ongoing concerns about H.264, and the reason everyone hasn’t already adopted the video tag with that codec as a standard.

Talking about Flash, but not talking about H.264’s patent problems or real open standards

Web tags aren’t really open unless there’s a standard underneath for them to serve. Early standards advocates learned this the hard way with GIF, the Graphics Interchange Format. The story goes like this: for years, GIF was adopted as a graphics encoding standard online. Sure, it was patent-encumbered and could potentially result in massive license fees – but it was free at the moment, so why should anyone worry? (Is this sounding familiar yet?) In the late 80s and early 90s, GIF was a free ride, so no one bothered to adopt an open alternative. Then, just as GIF began to peak in popularity, the folks who owned the patented technology, UNISYS, decided to change the rules. It was their right to do that, because they still owned the patent.

Ironically, GIF’s patent was far less dangerous than the patent that covers H.264, because it applied only to the LZW compression algorithm used in writing the files, not decoding them. That meant only the GIF creation tools were really at risk, from 1994 when the additional fees were announced to 2004 when the patent expired. (If you want to brush up, there’s a 2004 reprint of a 1995 story on the topic.

First, it’s important to understand that MPEG LA, the body that licenses H.264/AVC (among other things), represents not one patent owner but a pool of patent owners. Those owners set the license fees and terms. That makes licensing patented technologies easier, but as far as making H.264 the new video standard for the Web, the whole situation is more complex, not less – because any member of that pool could decide to cause trouble before the patents expire, in roughly 2025.

But I digress. There’s a bottom-line question here.

Is it possible browsers, streamers/broadcasters, and users might incur license fees for using H.264? If they did, it could threaten the freedom of video on the Web in generally, which depends on a level playing field for publishers and viewers. It could also be devastating to free and open source video production tools: not only would those tools violate the patents, but it’s possible users of those tools could be liable for fees.

The answer is relatively clear, but only through New Years’ Eve at the end of 2015. From Betanews:

As part of its response late yesterday, MPEG LA delivered a statement to multiple sources, including Betanews, announcing that the rights management firm will extend the period for which it will refrain from collecting royalties for use of H.264 in free streaming video, until the last day of 2015. The term of that royalty-free agreement was due to expire at the end of this year.
“Products and services other than Internet Broadcast AVC Video,” reads MPEG LA’s statement to Betanews, “continue to be royalty-bearing, and royalties to apply during the next term will be announced before the end of 2010.” Internet Broadcast AVC Video is the name of the patent portfolio to which H.264 belongs, when used in the context of streaming.

H.264 licensing body won’t charge royalties for HTML5, other Web streams [Betanews, February 2, 2010]

That’s an incomplete answer, though. We still haven’t seen the 2016-2025 terms, and just as importantly, the MPEG LA is very clear that users could be liable for the use of the codec. From the same article:

But in a direct, personal response to the LWN.net reader that was shared with other members, MPEG LA global licensing director Allen Harkness explained that the fact it doesn’t charge end users (viewers) royalties for downloading H.264 streams, doesn’t mean they should not be licensed to do so. Effectively, someone has to be licensed to produce the videos, and that license does incur a fee. But that license is then effectively passed downstream to the end user.
“While our Licenses are not concluded by End Users, anyone in the product chain has liability if an end product is unlicensed,” wrote Harkness. “Therefore, a royalty paid for an end product by the end product supplier would render the product licensed in the hands of the End User, but where a royalty has not been paid, such a product remains unlicensed and any downstream users/distributors would have liability. Therefore, we suggest that all End Users deal with products only from licensed suppliers.”

By the way, before you get your conspiracy theorist hats on, one of the companies that could wind up paying steep fees is Apple. Apple is just one member in the MPEG LA pool, and its liability (the number of patents for which it would have to pay) could well be greater than its equity (the patents Apple themselves own, which are far fewer in number and smaller in importance). It’s more likely that Apple’s support for H.264 is motivated by practicality, not some desire to cash in on H.264 patents. They’re already paying to be a licensee, and they’re aware of the legal ramifications of using H.264. It’s “the devil you know,” in other words.

Is there an alternative to H.264?

There are many things to like (or even love) about H.264 as a codec, but it’s a stretch to argue that H.264 is the best codec for all Web video.

On this, we can ask Adobe and get a more fair and balanced answer. Adobe added H.264 support in Flash Player 9 and Adobe AIR. If it was the solution to everything, you’d expect it would have been the solution in Flash. So why wasn’t it? David Hassoun of RealEyes Media explained in a Flash 9 tutorial on the Adobe Developer Connection:

So does this new Flash Player support for MPEG-4 and H.264 mean that it will replace the On2 VP6 codec? Absolutely not. The addition of H.264 gives developers greater choice to select the technology that best meets their needs. The current implementation of H.264 does have some limitations, such as lack of support for alpha channel and the inability to embed video into a SWF file. On2 VP6 is a solid, high-quality choice for Flash-based video projects. The On2 VP6 codec is also clear of any licensing issues that may arise with MPEG-LA. (Licensing information can be found on the MPEG LA and Via Licensing sites.) The On2 VP6 codec will remain a consistent and viable option for media delivery—see the On2 VP6 technology white paper (PDF, 140K) for more information. The added support for H.264 simply means that there are now more options and wider spread compatibility for high quality and HD video.

Apologies for my geeky Empire Strikes Back metaphor, but here’s where we’re at: OGG Theora is blasting into space, headed for a losing battle with Darth Vader. “That boy is our last hope,” says the open video movement. “No,” says Yoda, or, erm… maybe Google. Or me. Or Frank Oz. Or something. “There is another.”

If Google were to open up the video codecs it got from On2, the whole debate could change, as I wrote last week. On2’s video codecs may actually, ironically, be better suited to the job than H.264, for some of the reasons above. But most importantly, it would mean that On2 video could become a format that’d satisfy the major browsers and open and proprietary video production tools alike, without everyone risking incurring lots of fees. (One variable to explore would be this codec’s performance on mobile, though I know various parties have considered On2’s stuff as a mechanism for targeting mobile devices.)

But let me be clear: this is not just me wishing I’d gotten a job with ZDNet or going off on some personal vendetta. There are major reasons for the visualist community to care. Both this site and its sister site have long been about online freedom of expression, and about the democratic power of our connected world and its open standards. If we’re going to have the freedom to edit, produce, distribute, and consume video, having proprietary “taxes” along the way is a very bad thing. And this debate isn’t over yet. It also has far, far less to do with Flash than a lot of people currently seem to think.

Right now, though, the news isn’t good. The biggest news this week was largely ignored:

The other shoe: Microsoft and H.264

I’m not optimistic. If I had to bet right now, I’d bet on a patent-encumbered future for video. When I spoke to parties from organizations like the Mozilla Foundation at the Open Video Conference, their biggest concern was time. While the world has focused on Apple and the iPad, the simple truth of the matter is that everyone in the tech world has reached a consensus that the time for video directly in the browser, as part of HTML5, is now. So what everyone has been waiting for is support from the world’s leading desktop OS vendor and #1 browser maker: Microsoft.

I think the battle is over. Dean Hachamovitch, General Manager, Internet Explorer says that Microsoft has chosen H.264:

H.264 is an industry standard, with broad and strong hardware support. Because of this standardization, you can easily take what you record on a typical consumer video camera, put it on the web, and have it play in a web browser on any operating system or device with H.264 support (e.g. a PC with Windows 7). Recently, we publicly showed IE9 playing H.264-encoded video from YouTube. You can read about the benefits of hardware acceleration here, or see an example of the benefits at the 26:35 mark here. For all these reasons, we’re focusing our HTML5 video support on H.264.

So why isn’t Microsoft concerned about the litany of potential license issues above? That’s easy: Microsoft doesn’t need open standards. You’ll need to pay for that license somehow. So why not get locked into their proprietary operating system in the process?

Other codecs often come up in these discussions. The distinction between the availability of source code and the ownership of the intellectual property in that available source code is critical. Today, intellectual property rights for H.264 are broadly available through a well-defined program managed by MPEG LA. The rights to other codecs are often less clear, as has been described in the press. Of course, developers can rely on the H.264 codec and hardware acceleration support of the underlying operating system, like Windows 7, without paying any additional royalty.

In fact, Microsoft is better off if alternative operating systems like Linux and Android incur license fees. It means those operating systems are just a little less free, which erases some of their advantage over Windows.

Is there any hope at all? As near as I can figure, Google is now the only company with the leverage to navigate us out of this mess, thanks to the enormous popularity of YouTube and the growing popularity of Android and the Chrome Browser, plus the fact that Chrome OS is on the horizon. Time is running out, but if (this is a huge if) Google were to open up an On2 codec, then adopt it across YouTube and its mobile and browser lines, then nail implementation so well that it convinced others (particularly Microsoft) to follow. The other likelihood is that even the likes of Microsoft may privately adopt a “wait and see” approach with those MPEG LA terms. If later this year, MPEG LA either plans to hike its rates in 2016, or it doesn’t cover terms all the way to 2025, it might raise the appeal of an alternative like Google’s.

Alternatively, we can hope that the MPEG LA decide to be generous and extend free terms through 2025. If that happened, then even this patent-encumbered video format could become a major tool in the open Web. We’d effectively get the dreamworld Apple has been hinting at: an open video tag with a free video format that looks great and has wide hardware and software support. So the “happy ending”
doesn’t have to exclude H.264.

Mozilla is, in the meantime, in a tough position. Having promised not to support H.264, we could wind up in the weird situation of having to use Flash in Firefox while Chrome, Safari, and Internet Explorer all use HTML5 and H.264. It seems that could change, though, depending on how things play out. The fact that Mozilla has taken the hard line ought to suggest that there is at least some cause for concern.

Phew. There’s absolutely no way to cover this issue in a small number of words. Well, or you could gloss over the issues and pretend they don’t exist, if you’re a tech CEO.

There are other issues left out of Jobs’ “thoughts,” though.

What we can do: think different

Don’t get me wrong. As I said, Jobs’ “Thoughts on Flash” likely mirror a lot of our own. What I’m saying is that we don’t have to limit our thoughts to that debate.

Cross-platform development, freedom of speech in software, video codecs, patents, intellectual-property, Web standards: these are all complex issues. They merit more than simply scoring quick political points against one platform or another. (And yes, that includes even being too quick to dismiss Apple’s platforms and what they do right.)

This isn’t just about the iPad or the iPhone. It isn’t just about Apple. It’s about which debates we have, who frames them, and how we address them.

The point is, what we all see in our Web browsers could depend on the these issues. What the tech community thinks and decides about how development should work, about which freedoms are important for developers and which aren’t, all depend on these issues.

Mesmerizing magic tricks are a good time. But in this case, the responsibility falls on us – not Apple, on us. Fool me once…

Apr 22

Google O3D: Mind-Blowing Open-Source 3D API in the Browser with JavaScript + OpenGL, DirectX

Wish granted!

Think 3D in the browser will never catch on? Think again. The folks at Google Labs have built an incredible-looking 3D API called O3D. It does just about everything you want, and then some:

  • It’s multi-platform: Mac + Windows + Linux.
  • It can render to both OpenGL and DirectX render pipelines.
  • You can write your own vertex and pixel shaders. You have to use O3D’s own language for doing this, but that actually enhances compatibility, as frustrated shader coders may already know. (See the FAQ)
  • It’s a scene graph, so managing complex 3D scenes isn’t a chore.
  • It has powerful built-in functions like viewports and pickers (plus custom pickers), so you can actually get something up and running in a reasonable time.
  • It has an import workflow with COLLADA, an open standard for 3D assets (and which, incidentally, has support in Google’s own SketchUp).
  • You code in JavaScript, using the powerful V8 engine (developed for Chrome).
  • Gears lets you run offline.

There are already some complaints about “another standard,” but to me, putting together a whole package here and employing other, lower-level standards (JavaScript, COLLADA, OpenGL, DirectX) makes a lot of sense.

http://code.google.com/apis/o3d/

I expect the folks working on Java and JavaFX are busy thinking about the fact that Sun just got bought by Oracle – something I’m hopeful, at least, ensures Sun’s future and is ultimately a good thing. But I hope someone on those teams is starting to get the message: 3D isn’t just something that’d be “nice to have.” It’s essential. And while even most developers likely don’t have a clue about things like custom shaders, having access to customize the graphics pipeline is likewise something ultimately benefits all developers – even if they just wind up relying on someone else’s code. I really do hope this is a priority with the coming development of Java and JavaFX, which could have the power to do these sorts of things. (Heck, Java could even benefit from the code Google just posted.)

On the proprietary side, this to me is a big blow to Microsoft’s WPF and Silverlight and Adobe’s Director. Unlike those products, O3D looks simple, powerful, flexible, open source, and directly programmable with JavaScript.

That’s not to say there aren’t some questions here – and the Java/JavaFX comparison is especially relevant:

  • Another plug-in: You do have to install a plug-in to work with O3D, something that actually isn’t necessary with JavaFX (when it finally does 3D) or right now with JOGL and Java3D.
  • Mobile, or just desktop? My big question I have is what this means for mobile. I’d love to have O3D work with OpenGL ES on, say, Google’s own Android platform.
  • Not Just JavaScript? It would be nice if eventually you could use other languages like Java to program O3D.
  • Sound? Oh, yeah, that. 3D sound is an ideal complement to this sort of scene, and the browser may be a bit constrained in that respect. I’m curious whether O3D might eventually include an audio API. (And yes, that’s where something like Director is still unparalleled.)
  • Making it actually work: Okay, there’s also the fact that I haven’t successfully installed it just yet. Working on that.

(I’ll try to get answers to those questions.)

Oh yeah, and then there are details like the necessity to write your own custom shaders just to add more than one light to a scene – I think this will initially appeal only to folks with some real 3D experience.

But am I excited? Ohhhhh, yes, indeed. O3D itself looks fantastic, and I think this is a sign that 3D times ahead are going to be really fantastic.

And as long as you have the plug-in working and a browser in full-screen mode, you could literally set up an O3D project as a performance / installation tool. O3D visualists? Absolutely. Enjoy.

Media_httpfeeds2feedb_ywscm
Media_httpfeeds2feedb_zhoht

Get Updates

Tags

Archive

2012 (6)
2011 (11)