Category Archives: Open Source Multimedia

News regarding open source multimedia projects.

Sun OMS Has A Spec

A little over a year ago, Sun was making rumblings about a brand new video codec that they were hoping to design from the ground up using known-good (read: patent-unencumbered) coding algorithms. This was to be called the Open Media Stack (OMS). I wrote a post about, made an obligatory MultimediaWiki page about it, and then promptly forgot all about it.

Today, by way of a blog post by Opera’s Bruce Lawson describing why HTML5’s <video> tag is, well, stalled (to put it charitably), I learned that Sun’s OMS team has published at least 2 specs, the latest one being posted a few weeks ago on June 9, 2009. As he notes, the proposed Oracle buyout of Sun puts the OMS project’s status in limbo.

The spec page links to forum threads where interested parties can discuss issues in the spec. There aren’t many comments but the ones that exist seem to revolve around the codec’s articial resolution limitations. For my part, I wonder about how to encapsulate it into a container format for transport. The format specifies a sequence header that is 96 bits (12 bytes) in length, though there are provisions for (currently unused) extended data as well as free-form user data. The sequence header would be categorized as extradata in an AVI file or in a MOV file’s video stsd atom. Successive frames should be straightforward to store in a container format since the coding method only seems to employ intra-and inter-frames. Each frame begins with a header which specifies a 37-bit timestamp in reference to a 90 kHz clock. This allows for a recording that’s just over 1 week in length. It’s also one of those highly redundant items if this format were to be stuffed in a more generalized container format.

Anyway, the main video algorithm uses arithmetic and Golomb coding for its entropy coding; 8×8 pixel macroblocks which can either be an entire block unto themselves or subdivided into 4 4×4 sub-blocks; colorspace is YUV 4:2:0 planar; specifies bit-exact 2×2, 4×4, and 8×8 transforms and quantization procedures; spacial prediction using left, top-left, top, and top-right blocks; precisely-specified 1/4-pel motion compensation. All in all, it appears relatively simple; the 0.91 spec (annexes and all) weighs in at a mere 96 pages.

Naturally, there are no reference implementations or samples available. This got me to wondering about how one goes about creating a reference implementation of a codec (or a production implementation, for that matter). The encoder needs to come first so that it can generate samples. Only then can a decoder be written. Ideally, the initial encoder and decoder should be 2 totally different programs, written by 2 different people, though hopefully working closely together (speedy communication helps). There is wisdom in the FFmpeg community about not basing the primary encoder and decoder on the same base library after we reverse engineered one of the Real video codecs and found a fairly obvious bug that occurred in both sides of the codec.

I think I know one way to ensure that the encoder and decoder don’t share any pieces– write them in different computer languages.

I’m still wondering what kind of application would need to record video continuously for up to a week. How about a closed-circuit security camera? With a terabyte drive, it could store video for a week assuming a bitrate of 1.5 Mbits/sec. That’s roughly the same bitrate as the original MPEG-1 standard. If this coding method compresses more efficiently than MPEG-1, this might be a plausible application.

GSoC 2009 is Afoot

FFmpeg has been accepted as a mentoring organization in the Google Summer of Code 2009 program. This is the program’s 5th year and FFmpeg’s 4th year in the program. Thanks as always to the big ‘G’.

To refresh, the GSoC pays students $4500 for a summer’s worth of work on qualified open source projects. FFmpeg is one of those projects. FFmpeg team members mentor various multimedia-related projects. Our current project proposals are listed in the wiki. And, as with the previous 2 years, we have some stringent requirements for our students– namely, a student must complete a small FFmpeg task, refining the solution based on critical feedback until it is part of the mainline codebase.

I personally haven’t committed to any mentor possibilities. I wonder if I should propose the Theora encoder again, which didn’t quite pan out last year? The thing is practically written already in my mind.

FFmpeg 0.5 Is Released

If you’re reading this, the multimedia.cx DNS change has propagated, yet again, for another hosting service. But that’s a venomous tale for another blog post. FFmpeg v0.5 hit the web yesterday, right about the time that my new hosting service started having serious problems. Thus, I was unable to observe the occasion at the time.


FFmpeg logo

But now I’m able to let it sink in a bit more… wow. I can’t even remember the last time we had a release and to be honest, I don’t really want to look it up because it’s a little embarrassing to think about. Thanks to all my co-devs who made the release what it is. But thanks especially to Diego Biurrun who stuck his neck out and pushed hard for this release effort starting a little over a month ago. Somehow, we got the release out.

Rest assured, we are taking notes this time around in order to make the process easier next time around. This is the dawn of a new era of open source multimedia (here’s hoping, anyway).

Gaining Momentum

Don’t look now, but the idea of making a formal FFmpeg release in the very near future is gaining traction over on the FFmpeg-devel list. There is a determined and growing team of individuals committed to this goal in the near future. To that end, there is even a Wiki page listing the steps that need to occur leading up to a release.

There is some debate about what kind of release schedule we should commit to. Some take the stance that we should follow the model that Wine apparently follows by releasing every 2 weeks. Really, every new weeks? I had never heard of that before. It strikes me as a bit severe. I personally would like to see a little more time between releases, but see them often enough that we get really good at it, and it becomes part of our shared community mindset.

After all, there are a few projects out there that depend on FFmpeg.

I admit, whenever I get to thinking about an FFmpeg release, I get a little nervous about the ensuing discussion. Not the discussion about whether or not a release should happen; that’s a foregone conclusion because it will happen. No, the item that makes me lose sleep is the biggest bikeshed hue discussion of them all — how should we version the upcoming release of FFmpeg? I don’t think I even want to get involved in that one.