Passing on the Left

Seven Seas publishing just released the latest book of comic goodness, InVisible written by my partner Tristan.  Unlike releasing software, where gratification is instant, Tristan finished this project months ago but the books took the slow boat from whereever the printing was done.  Or something.  Gratuitous Amazon link (buy now!)

Tristan also has a story with our friend Atticus Wolrab in Comic Book Tattoo, a book that can only be described as a tome.  12″x12″x2″, it has dozens of amazing stories based loosely on Tori Amos songs.  It came out last summer coinciding with San Diego Comicon, where I got to see the Tori Amos fan base in all their glory.

I have an interesting history with wireless routers and hubs.  I always keep a spare around, since they seem to die at random.  Some are dead on arrival, which often prompts me to buy two at the same time.  The death seems to follow the same pattern — first, it drops wireless connections every few days, then every few hours, then all the time.  Belkin, Linksys, Netgear, D-Link, Apple, I have a pile of hardware with broken radios.

I am now on my way to buy two more wireless routers.  I’d pay extra to ensure that I’d get one that won’t die in 6-12 months, but that technology is apparently not for sale.

Lennart is one of the few people thinking about audio on Linux at a high enough level to define and sort out the problems. I endorse this message.

Well, except for the part about portability — GStreamer works quite well on OS/X and Windows. Now only if it had a good raw audio subsystem, like what you would use in a game engine…

The release of VLC with Dirac support (via Schrödinger) and the release of the Dirac research codec (confusingly named dirac-1.0.0, sorry) has caused a bit of news in the geek press. I’ve noticed a few uninformed comments out there, and figured it would be wise to provide real information from a Dirac developer.

•  Decoding Dirac takes a lot of CPU. This is true, depending on your definition of “a lot”.  It is also on purpose.  MPEG-4/ASP uses more CPU than MPEG-2, but gets better compression.  Likewise with MPEG-4/AVC vs. MPEG-4/ASP.  However, it doesn’t matter.  A video stream either plays on a CPU or doesn’t.  And most new computers (that aren’t specifically underpowered) are fully capable of playing Dirac at 1080p/30.
• Encoding Dirac can be slow.  Right now, you either get slow and good (dirac-research) or fast and crappy (Schrödinger).  This is an area of active development.
• Dirac and Theora will likely coexist.  For a variety of historical and technical reasons, Theora encoder development has been concentrated on SD and smaller sizes (and corresponding bit rates) and Dirac encoder development has concentrated on SD and HD sizes and bit rates.  And each currently appear to be better than the other in their respective areas.  Given limited developer resources, I imagine this trend will continue.
• Tools exist for Dirac.  Several will be released in the next few months, including both DirectShow and QuickTime plugins.  (There are currently a few showstopper bugs remaining.)
• Comparing apples to oranges still doesn’t make sense.  Many video encoders cannot be compared to each other because they focus on different problem domains.  “1 Mbit/sec” is not a full description of how a particular video was encoded.  That could mean CBR with a strict buffer model, or simply (file_size/duration), which are completely different creatures.

Also, there are Dirac demo videos here.

I’m at this annoying stage with Orc and Liboil where I need to add a feature to Liboil to support a new feature in Schrödinger, except that the new feature would be really easy to write if Orc was further along. Sigh. So I continue to muddle along not working on either.

In other news, jirac, the Java Dirac decoder written by Bart Wiegmans as a Google Summer of Code project, is pretty much feature complete and integrated into Cortado. There are a few showstopper bugs remaining, but I’m hoping for a release soon.

And in yet other news, I will be attending IBC in Amsterdam in a few weeks to meet up with various people to talk about Dirac and GStreamer. If you would like to meet up, let me know. There will be at least 3 booths related to Dirac: the BBC will be demonstrating Dirac as used for high-definition video distribution, NHK will be demonstrating Super Hi-vision with Dirac compression (that’s 4320p, kids), and Numedia will be demoing their hardware that handles Dirac Pro (SMPTE VC-2), which is Dirac for studio compression.

I’ve been seeing comments on teh Internets about “when Dirac is ready…” Just wanted to let you all know that Dirac is ready now.

I haven’t written about the Dirac project recently.  We’ve reorganized a bit recently: most information is on diracvideo.org now, “Dirac” is now used to describe the overall project, with various subprojects like Schrödinger, dirac-research (formerly the Dirac codebase, intermingled with the specification), and a bunch others.  I’m finding that a lot of my time recently is cat herding all the subprojects and creating a coherent whole.

One such subproject is Bart Wiegmans’ GSoC project to implement Dirac in Java and get it working in Cortado.  It’s moving along quite nicely, and has reached the feel-good milestone of creating a pretty picture.  Right now, it only handles a very limited set of bitstreams — intra pictures only, variable length coding, and a specific choice of wavelet filter.  I think Bart has fixed a bug related to chroma handling since the time I created this screenshot, which is why it’s in greyscale.

Another subproject, and another GSoC project, is Mattias Bolte’s OpenGL decoding backend for Schrödinger.  This is roughly similar to the existing CUDA backend, although hopefully will work on a wider range of hardware.  He’s uncovering a number of resource usage issues in Schrödinger, such as the decoder using up to half a GB of RAM for temporary storage in some cases.   Alas, my hardware does not handle GLSL, so there will be no screenshots here.  The scope of the current project will require the use of GLSL, since serious signal processing is beyond clever texture hacks.

On a related note, progress is being made in gst-plugins-gl, the GStreamer OpenGL plugins.  Julien Isorce has done some amazing infrastructure work expanding on my original gst-plugins-gl code, which was really just an experiment.  At some point, the schrodec GStreamer element will decode directly in hardware using OpenGL, and then deliver the pictures as textures to downstream GStreamer elements, which will render it directly to the display.  Fillipo Argolias has been writing some cool GStreamer video filters that use OpenGL, but on a different branch than Julien’s work.  (My current task is merging these branches.) These filters will be used for Cheese.

Maarten Lankhorst has been working on a DirectShow filter for encoding/decoding Dirac streams based on Schrödinger.  It currently only works with Dirac inside Ogg, and is nearing the point where it is useful for people to use.  We’ll be doing a testing release sometime soon.

I have been working on a QuickTime component in whatever time I’ve had remaining after trying to keep up with everyone else’s work.  It works only with the QuickTime container, but it encodes and decodes pretty consistently with the Apple tools.  It’s pretty much ready for a testing release as well; just need the time to get it out the door.

Update: A screenie of Julien’s glfiltercube example (on a Mac, FTW):

I have posted the slides from my talk at LugRadio Live 2008.

Contrary to what the LugRadio web site says, I will actually be talking about Dirac (and Schrödinger), not GStreamer, at LugRadio Live 2008.  If you’re interested in cutting edge developments, or open media, or simply watching open-source taking over another niche, come and listen to me rant^H^H^H^Htalk about the state of video compression, media on Linux, colorspace conversion, and kitties.  Or you could just come and watch Dirac in action.

Schroedinger-1.0.0 is now out. (download) The 1.0.0 means several things: One, early adopters can start using it for real work — it’s bitstream compliant and fairly well tested internally. Two, it’s API and ABI stable, so integrators can work at adding Dirac support to various frameworks and tools. Three, I’m going to be inundated with bug reports for the next few weeks.

Schro works best (right now) in combination with Ogg and GStreamer, and when compressing SD and HD720 video at constant bit rate. Integration with other projects is now a priority.

Encoded picture quality in CBR (constant bit rate) mode isn’t as good as I would have liked it for a release, but this is a good baseline to ensure progress. A week ago, picture quality was much better, but there was a bad bug that caused bit allocation for some pictures to be way too high, thus starving future pictures and causing the picture quality to drop to “unrecognizable”. The workaround for this release is to make the bit allocator less agressive, so average picture quality is lower, but worst-case is now tolerable.

It’s been a rather dismal last few years for democracy and freedom in the world, but this past week has yielded several symbolic but heartening events: the Protect America Act expired, Kosovo declared independence, and Pakistan democratically rejected its military government.