I ought to mention the selected applicants for Google’s Summer of Code — FFmpeg edition. Calling them “winners”, though, is quite the misnomer. They’ve signed up for a summer of hard hacking on some ambitious goals:

• VC-1 decoder by Kostya Shishkov
• AMR decoder and encoder by Robert Swain
• EAC3 decoder by Kartikey Mahendra BHATT
• LGPL AAC decoder by Maxim Gavrilov
• Vorbis encoder by Mathew Philip

It seems that Macromedia-now-Adobe is getting serious about quality, 1st-party, Flash Player support for Linux. There is even a new development blog intended to track Linux issues: Penguin.SWF.

I recently had to help a colleague get audio output working on his stock Fedora Core Linux system (I fail to recall which version). To establish a baseline I downloaded a reliable (because I made it) raw PCM WAV file and searched for a pre-installed program that should be able to handle it. I found that savior of open source multimedia — Helix Player — was installed. Helix Player was unequipped, in its default installation state, to play the raw PCM WAV file.

I was embarrassed for the program. I eventually just did what comes naturally and downloaded and installed xine. Although I recognize that if xine were installed by default it would be horribly crippled, I believe it should still be able to play raw PCM WAV files (perhaps the simplest multimedia file in the domain).

While we’re on the subject of crippled multimedia programs: Commercial Linux distributions (SuSE Linux, I’m looking in your direction)– Is it really that useful to distribute multimedia playback apps that are crippled to the point of abject uselessness? Instead of distributing crippleware out of legal paranoia, do you think your resources might be better spent and your users better served by some helpful system that could advise your users on how to download and install full-featured multimedia players from the official websites? Maybe I’m just bitter about the number of SuSE users that post to the xine-user list reporting, “I just installed SuSE with the xine package and it doesn’t play squat! What’s wrong?”

Oh, autotools– what would I do without you? Recognizing your utility places me in a minority. I know you are woefully underappreciated and catch a lot of flack for your apparent complexity. But this is largely because many programmers refuse to face up to the fact that the complexity of building a program is commensurate with the complexity of the program itself. They might not like you but don’t take it personally as they are invariably at a loss to produce a superior solution. You do most everything that developers need from a build system– they just need to find a decent tutorial, reference, or –best of all — another source package that implements the same feature they need; there must be thousands of examples to choose from.

Remember my musing about assorted goals involved in developing HD DVD support for Linux? Several people have written me to point out that Toshiba has already beaten us to it– in the flagship HD DVD device. In case you get all your geek and/or multimedia news from this blog, this article at CDFreaks has a number of juicy details. It is reportedly a high-end PC board that runs a Red Hat-based Linux distribution on an M-Systems Disk-On-Chip (essentially a flash memory component that looks like an IDE drive in from the PC’s perspective). Of course, the most important component is the ATAPI HD DVD drive that can be removed and connected to your desktop PC, as the pioneer in this story demonstrates in a video.

See? What did I tell you in Ever-Emerging Digital Theater Technology? It’s just a PC; everything is.

This raises some interesting questions. I have yet to hear whether the launch discs actually used anything more advanced than stock MPEG-2 for video coding. There was some speculation that the discs were not using VC-1 yet. A player like this is trivally upgradeable in the field. So the software support for VC-1 may or may not be there. I still have to wonder if this was some kind of a “Plan B” device in order to beat Sony’s Blu Ray to market. This strikes me as rather unorthodox, not to mention costly. Maybe Toshiba could not get all of the custom ASICs (ideally lower cost than a off-the-shelf, general PC components) done in time but had a separate team working on this in parallel “just in case”.

After reading my post last week regarding emerging digital theater technology, Baptiste Coudurier did some legwork and located the — quite public — v1 specs for the Digital Cinema System. You can download the exhaustively-detailed PDF here. The 2 general supported video resolutions are dubbed 2K and 4K which refer to 2048×1080 and 4096×2160, respectively. Section 7.5.3 specifies exactly how much storage a compliant unit is expected to have ready (a lot), and why. Video in fact is compressed, with JPEG 2000 and uses a 36 bit/pixel XYZ colorspace. Audio is uncompressed and subtitles are PNG. How did all of these open formats make it into the mix? Strange. Also, the container format is specified as MXF. Encryption is, of course, handled by AES (that thing sure caught on in a hurry).

I have a contact working diligently on the LucasArts SANM format, most famously used in Grim Fandango. He sent me a MPEG-4 movie transcoded from an SANM file via an experimental FFmpeg module. Screenshot:

IMDb Studio Briefing has another in a long line of articles detailing how all movie theaters are about to go digital anytime now. Paramount Going Digital with ‘M:I 3′. I remember about the time that Star Wars Episode 1 was coming out in 1999, George Lucas was promising that by Episode 2′s release in 2002, everything would be digital.

Has anyone thought about what this means to unauthorized distribution (colloquially referred to as piracy)? If the studios think it’s bad with the current 0-day distribution, wow…

Seriously, does anyone give any thought to how this would work, the technologies driving it all, and weaknesses in the chain? I just want to think out loud here for a moment.

Read the rest of this entry »

A brief digression: At a frequency of roughly once every 2 days, the MultimediaWiki sustains a drive-by spamming attack. It usually takes 2-3 minutes to clean up, although one morning I woke up to a massive spam attack that took me hours to revert; that’s what prompted me to enforce user registration. What strikes me is how much more serious this problem could possibly be. I occasionally get so annoyed that I investigate MediaWiki’s anti-spam features.

Second-order digression: If you think it’s hard to find good documentation on FFmpeg, try finding the documentation you need for a Wiki package, which is — in the time-honored tradition of eating one’s own dog food — all in Wiki form. Why is this a problem? It just feels so… “squishy”. It’s not all there, it’s always in flux, it can give you a general idea of what you want to know but never feels authoritative– the same controversial points as, for example, Wikipedia. In fact, my first encounter with the Wiki paradigm was the online documentation for some open source program or another. They constructed a Wiki outline and expected users to fill it in. That experience gave me a serious aversion to Wiki for a long time to come. That said, would it be hypocritical for me to mention that I very much want to set up a Wiki-based knowledge base for FFmpeg users and developers?

I have watched the email spam arms race with much interest for many years. I am fascinated by the technical challenges involved and the solutions proposed, each with its pros and cons. Every proposed measure could be thwarted with enough effort. A few years ago, Bayesian filtering caught on and it always struck me as the tactical nuclear weapon of spam filtering. It did a lot to solve the problem on the client side (though counter measures at various levels of the email network help matters).

Then blogs, with comments, and Wikis gained prevalence. The spam problem started all over again. What I can’t seem to understand is why people fighting the good fight on this new frontier have chosen to start the arms race from square one by banging at the problem with rocks instead of going straight to the nukes. I’m wondering why there aren’t any Bayesian solutions in the Wiki space. (Thankfully, it appears that there are Bayesian comment filtering plugins available for, at least, WordPress). How would it work? Perhaps initialize it by claiming that the entire set of existing pages is valid and then allow administrators to mark certain pages as spam, or certain users as known spammers. When an edit is submitted the Wiki runs the edit through the filter to determine if it “looks” like spam and rejects it. However, one of the underlying operating principles of the Bayesian method as applied to email is that every user’s mailbox looks very different than everyone else’s. A spammer would require knowledge of an individual mailbox in order to reliably thwart the filtering. Unfortunately, the “mailbox”, or body of messages, in this case would be unified and public. This would afford a spammer an ergonomic, interactive environment by which to test spams by dumping in the text of valid pages and tweaking them with spammy URLs until the pages get through.

Okay, so maybe the idea isn’t that straightforward after all. Forget I even brought it up.

Through it all, though, I still stand by the Wiki paradigm.

Today was the first day for qualified students to submit applications for Google’s Summer of Code (last day is next Monday, May 8 ). If you’re an aspiring (or even established) multimedia hacker who also happens to be a student, check over the (sparse, compared to some other projects) list of FFmpeg project possibilities. You can also submit your own idea if you think you have a good one. Just make sure the application is written well enough and the FFmpeg mentor board will review it.