WebRTC comes to 10.4 (plus: Space, the increasingly limited frontier)

Say cheese!

WebRTC is an emerging, "bipartisan" standard allowing browsers to implement real-time communications ("RTC") in JavaScript with a standardized protocol. By bipartisan I mean Google (via Chrome) and Mozilla (via Firefox), but Opera (via whatever) is also part of that discussion. The Gecko derivatives such as us and AuroraFox are the first browsers to offer this to Power Mac users; I'm not aware of any other OS X PPC-compatible browsers that have implemented it.

To be frank, WebRTC per se has limited utility. While Fx20 has even better graphics improvement than 19, the low-hanging fruit is finally being plucked and graphics stack gains are likely to be less improved in 20 and 21. While audio-only communications should be possible on most G4s and maybe even upper-range G3s, full video and audio communication is likely only going to be satisfactory on high-spec multi-core G5 systems. The WebRTC library is massive, touching large amounts of browser code, and it required a lot of hacking to even build on 10.4. In fact, we are taking advantage of a minor Mozilla oversight: even though the default build uses a QTKit-based video capture system, and 10.4 should have QTKit, too many things don't work in 10.4's implementation and what does work in it does not properly mesh with the Objective-C support in gcc 4.6.3. But Mozilla also ported over the QuickTime 7 backend even though they themselves do not use it. This works nearly perfectly with 10.4; my iSight FireWire camera generated the image displayed, and theoretically any device that can be recorded by QuickTime is compatible with TenFourFox's implementation (however, my FireWire Orange Micro iBOT camera makes a scrambled image and I'm not sure what the difference is). If Mozilla or Google change the code so that the QuickTime backend doesn't work or is removed, then our WebRTC support might be shot. So far I've only tested the media capture components. It's entirely possible the networking section doesn't work right on 10.4 and I don't have a good way yet of testing this on my internal network.

So if it's so tenuous, and works fully only on a subset of Power Macs, and may one day not work at all, why put a lot of effort into it? The reason is simple: even though WebRTC is the best-known consumer, it's all part of a generic API called getUserMedia, which allows applications to capture video and audio for a whole range of functions. (Yes, audio works too, although there aren't a lot of examples that work properly with Firefox; most of them want Chrome. So much for standards.) For example, there's quite a few "photo booth" examples that let the browser capture an image and then work with it (submit it to imgur, save it to disk, you name it). The range of applications for even a simple feature like that should be obvious. Video display is run through QuickTime, meaning it can take advantage of all its little operating system cheats, and is AltiVec-accelerated on G4 and G5.

And, for you tinfoil hats, privacy is extremely rigid. The browser will make you verify when a page wants to get at your QuickTime video sources and let you pick the video and audio sources, which can be two different devices. If you refuse, nothing is sent. If you have no devices, nothing happens. I still need to do some polishing on the build system to make this work well, but I think it's good enough to unveil in 20. The interested can track progress in issue 214.

On the 17 front, a user discovered a serious bug in our IndexedDB support -- the compression library "Snappy" Mozilla started using between 10 and 17 never had its big-endian path turned on, causing corrupted tables and crashes on sites such as Kindle Cloud Reader. This bug affects all builds of Firefox on PowerPC and I upstreamed the fix in issue 213. It will be in 17.0.5 and 20.

That brings me to our second issue: we're running out of space in Google Code and although I filed a polite request for more quota (we're nearing our 4GB allotment), Google is balking at expanding our limit. We may need to delete some deprecated files and old betas (note: formal stable and unstable releases will never be deleted) to recover some of this capacity, or, look into a permanent solution if I'm not able to recover enough. We've never paid for the service, so I can't really be upset, but if Google decides they're not going to give us any more room we'll have to think of some other plan of action to keep things operating. While the wiki, issue tracker and build changesets would remain on Google Code for consistency no matter what, one option is to find (or, possibly, buy) off-site hosting for the binaries and/or try to start a mirror network. More hopefully next week when I get an up or down from Google Code's user support.