Ah, my first press release. This is the most attention anything I've done has ever received. Part of me wishes it was for something less mundane than writing a driver for some off-the-shelf consumer hardware, but I guess I can't complain. It's not often that Slashdot posts about driver releases.

What has been interesting is the response from the community that the press exposure has generated. Criticism that I was expecting—lack of kernel 2.4 support, for example—hasn't come up at all, and the response on Slashdot was decidedly positive which is almost unheard-of. The only (reasonable) complaint so far, besides the missing features like VBI and PAL which I'm planning to remedy anyway, is the price of the Plextor devices compared to similar products. The "Plextor quality costs extra" argument only goes so far, especially considering that Lifeview and Georgia Tech are selling substantially identical GO7007-based units for 25-50% less.

Plextor has been kind enough to donate a TV402U to Isaac Richards, author of MythTV, so maybe soon Myth will support these guys. Ultimately, I'd like to see ODMs develop self-contained PVRs running MythTV with WIS hardware on-board, but we'll have to see. For now, I'll be content to just get some community support around the GO7007.

I've just released the first new version of Spook in almost six months. Embarrassing that I've let things go for so long, but at least all the features that have been accumulating in private trees since then have mostly been added. The network-side code has been overhauled which not only made things more efficient but paved the way for multiple media streams in the same RTSP session. Audio. w00t.

Since I started adding the audio support, the limitations and flaws in the current stream implementation have been bothering me. It kind of made sense at first to declare "the output from this grabber is named 'foo', and the input to this encoder is named 'foo' and the output will be named 'bar'," etc, but it's not only confusing but it prevents me from implementing a number of more useful features. It would be nice, for example, to have Spook automatically open all the video and audio capture devices it could get its hands on, compress them to some default reasonable format, and put up a template webpage with a list of everything it found so that the user could test out Spook without configuring anything at all. Not possible if all capture and transformation actions have to be declared explicitly.

There's two major changes I'd like to make to the way Spook creates media streams. The first is to change the media compression and format specification from an imperative form to a declarative form. There's no good reason (other than Unix tradition, I suppose) to force the user to explicitly list the various filters and encoders and the order they should be used, when all that's really necessary is for the user to specify the desired end result. "I want a 320x240 384kbps MPEG4 stream" is enough information to set up the entire module pipeline automatically. The main problem that arises is getting all the nuances of each type of stream correct—providing two different streams, one of 30 fps and one of 10fps, can be done by dropping frames after compression with JPEG, but with MPEG4 the frames must be dropped before they are encoded.

The other change is to convert the stream namespace into a hierarchy instead of using free-form strings. This sounds minor, but it allows modules to create new streams on the fly without causing confusion. Through the magic of sysfs, the V4L module can automatically discover all your USB webcams, configure streams for them, and create meaningful, static names for them. The two cams plugged into the hub on the lower USB port on the front of your system will be always be named something like "Device::Video::USB::2-1:1.0" and "Device::Video::USB::2-2:1.0" no matter when they were connected, because their name is based on their position on the bus. The same devices can be accessible with their device path, like "Device::Video::/dev/video1" or whatever, if you prefer that.

The real advantage of putting the streams into a tree is being able to perform transformations over an entire subtree rather than on one at a time. This would allow one part of the tree to contain a "mirror" the same streams as another part, but having passed through one or more modules. For example, the "Low Quality::" tree could contain the above streams as "Low Quality::Video::USB::2-1:1.0", etc, compressed as 100 kbps 10 fps video, rather than the native 30 fps uncompressed YUV format received from the hardware. These mappings from an existing subtree to a new one would be specified in the configuration file, of course, so the user could control which subtrees were available and the exact parameters used.

At the end of the whole chain, there still needs to be some sort of connection to make the stream available to clients across the network. This could be done through explicit pairings ("rtsp://*/webcam" will serve video from "Low Quality::Video::USB::2-1:1.0") or by exporting entire subtrees ("rtsp://*/cams/" will serve anything below "Low Quality::Video", such as "rtsp://*/cams/USB::2-1:1.0") as the user sees fit. As I mentioned, template webpages could optionally enumerate the streams in exported subtrees to simplify the initial configuration.

By now, you're probably wondering why I'm putting so much effort into automated support for large numbers of streams. It's not like most people have so many webcams that they can't configure them manually, right? Well, the ultimate goal is to turn Spook into more of a generic network media mixer, capable of importing video from any video source local or remote, performing some set of transforms on it, and exporting it over the network using a variety of formats and protocols. Re-encode video from the DCS-900 watching your koi pond into MPEG4 and relay it through another, more well-connected server via RTSP? No problem. Webcast press conferences from the room's AV system while simultaneously recording them for later retrieval over streaming RTSP or AVI download over HTTP? Makes sense to me. "Tune in" to the physics class lecture you're skipping by dialing a number from your mobile phone? Why not?

Putting as many media sources as possible into a common namespace doesn't get much closer to convergence, but it's a necessary step.

The spambots finally found my weblog, so the comment plugin is gone. Hope y'all don't miss it too much. Feel free to email me directly if you're unable to contain your rage over my scathing political commentary.

I guess I've been kind of anti-social for the past few months. I've been doing some work for Wis Technologies, who makes the world's most bad-ass real time video encoder ASIC, filling in some gaps in their reference software. They've been funding work on Spook, and although most of it hasn't yet gone back into the public tree, it's come a long ways. I also have some stream-relay code that I've yet to check in. Hm, Spook is looking kind of abandoned these days. I should poke it a bit more in the near future.

January has been consumed with a mad rewrite of the Linux driver for the WIS encoder. The old driver sucked mightily, so when Plextor wanted to their ConvertX product line to have Linux support (which didn't exist before only because it didn't occur to anybody), trashing the old code and starting from scratch was pretty much the only option. It came out pretty well though. It's in QA now and should be released via Plextor in a week or so.

I've got my process down. Update the README, `make distcheck`, upload the tarball, update the webpage, submit to Freshmeat, update the weblog.

Tonight's release adds Video4Linux support, so now the other 95% of the Linux community can use it. V4L is the API used by frame grabber cards and USB webcams, so I guess I should support it. USB webcams are pretty pathetic quality in comparison to Firewire webcams, and are also annoying to support because every USB webcam driver has its own funky API to set framerate and what-not. But it's what most people seem to have, unfortunately. Just for fun, I threw in support for the Philips webcams, but since I don't have one myself I have no idea if it will work.

Maybe tomorrow somebody will actually subscribe to the mailing list, too.

Been a while since I posted here, eh? As it happens, I've been deeply engrossed in a little toy that grew into a real project.

I've always been disappointed in the lack of decent streaming webcam software. Everyone and their dog has written a "grab an image and FTP it somewhere" app, usually complete with a crappy, useless GUI. (All you people who remember Cyclops are nodding your heads and thinking, "Yeah Nathan, you're one to criticise crappy webcam servers.") Some people go so far as to write a custom Java/ActiveX applet to pull down images real fast for kind of a redneck "streaming" effect. (Carson calls this "faux streaming".) The closest I've seen to live video is the HTTP multipart/jpeg streaming implemented by camserv and the Axis network cameras. This works, to some extent, but there's just something repulsive about shovelling JPEGs down a TCP socket as fast as possible and calling it "live video".

Come on, people! For decades we've had video compression techniques that are specifically designed to push live video down small pipes. And protocols for streaming real-time multimedia over IP networks have been standardized for over 10 years. The folks lucky enough to have multicast IP access have been holding multi-user video conferences since before most of the world had even heard the word "Internet". So why on Earth should we put up with the equivalent of mailing Grandma a stack of Polariods and telling her to flip through them really fast?

Before you say anything, don't give me that "widest possible audience" crap. I know you want your webcam to be accessible to anybody with a web browser, but how many people do you know who don't have QuickTime installed? Seriously, everybody who didn't have QuickTime installed already went and installed it to watch the Lord of the Rings trailer. And if they didn't care about the LotR trailer, they don't deserve to watch your webcam anyway.

OK, so where was I? Right—my point was that we already have the technology, standards, infrastructure, and most importantly the viewing software in place to start feeding people quality live video from our homes and offices. All we need is the server software. So, properly motivated by such an obvious need, I wrote some.

Spook is my attempt at a decent live streaming video solution. It captures video from Firewire cameras, compresses it to MPEG4 with XviD, and streams it (via unicast, no multicast required) to anybody who asks for it using RTSP. The result: true live video at 30 frames per second with a resolution of 320x240. In half the upstream bandwidth of the average cable modem. Now that is what I'm talking about.

Today was the first release of Spook. It only supports Firewire cameras for the moment, so I'm sure I'll get a few more folks interested once I support Video4Linux and all the TV capture cards and USB webcams it brings. The problem with V4L is that configuration for each camera chipset is different, so it may be a bear to support configuration of FPS and all that. I'll find out soon, I guess.