Author Archives: Multimedia Mike

What Platform Would You Like To Test?

What platforms should FATE test? So far, it is testing both x86_32 and x86_64 under Linux and Mac OS X, and PowerPC under Linux. These are the first and foremost platforms I care about, and have access to.

What other platforms would people like to see tested through FATE? Windows? *BSD? Solaris? Linux running on exotic bits of hardware? Game consoles? Well, I have great news: After many months of occasional work on the FATE infrastructure, I am confident that the system is in a shape where other people can run the core FATE script and submit results back to the main server.

I have released the first public version of the script at the core of FATE: fate-script.py. Anyone can run it locally on their own platforms, but it requires a few credentials (assigned by me) in order to submit results to the server.

Feedback is very welcome, as are offers to run FATE continuously on other platforms. Also, I would love to know how to properly version something with git. All I can say is that the currently posted version of fate-script.py is version 67eac48073a24deece52cb28fbb25c14858b6c23.

Parsing In Python

I wanted to see if the video frames inside these newly discovered ACDV-AVI files were just regular JPEG frames stuffed inside an AVI file. JPEG is a picky matter and many companies have derived their own custom bastardizations of the format. So I just wanted to separate out the data frames into individual JPEG files and see if they could be decoded with other picture viewers. Maybe FFmpeg can already do it using the right combination of command line options. Or maybe it’s trivial to hook up the ‘ACDV’ FourCC to the JPEG decoder in the source code. What can I say? FFmpeg intimidates me just as much as it does any of you mere mortals.

Plus, I’m getting a big kick out of writing little tools in Python. For a long time, I had a fear of processing binary data in very high level languages like Perl, believing that they should be left to text processing tasks. This needn’t be the case. pack() and unpack() make binary data manipulation quite simple in Perl and Python. Here’s a naive utility that loads an AVI file in one go, digs through it until it finds a video frame marker (either ’00dc’ or — and I have never seen this marker before — ’00AC’) and writes the frame to its own file.

acdv.py:

BTW, the experiment revealed that, indeed, the ACDV video frames can each stand alone as separate JPEG files.

We Don’t Care; We Don’t Have To

There is an old Saturday Night Live parody commercial from the later days of the U.S. phone company monopoly featuring Lily Tomlin as a phone company representative:


Lily Tomlin in the Phone Company parody SNL commercial
“So, the next time you complain about your phone service, why don’t you try using two Dixie cups with a string? We don’t care. We don’t have to. We’re the Phone Company.”

The reason I bring this up is because I participate in the FFmpeg project. FFmpeg is in a unique place among open source projects. Whereas, a common complaint against the open source paradigm is that there is too much duplicated effort among competing projects that all basically do the same thing while never matching or excelling beyond their proprietary counterparts, there is nothing else in the entirety of the software world like FFmpeg. Indeed, FFmpeg has a monopoly on do-everything multimedia manipulation programs.

Some people are distraught by this.

swfdec author Benjamin Otte has a blog post lamenting the problems of developing directly with FFmpeg. This finally prompted me to use my sucky research method against FFmpeg. The sucky research method works like this: Google for “XYZ sucks”, where XYZ is some software program, consumer product, or company in order to gauge the level of negativity against XYZ or perhaps to just commiserate with other chumps in the same boat as you. I most recently used this method to find other chumps as frustrated as me with both PHP and WordPress.

I discovered surprisingly few sites dedicated to hating FFmpeg. These stood out: FFMpeg strikes (again) and ffmpeg sucks. One comment even pointed out that there are no ffmpegsucks.tld domains registered yet, so I take that as a positive sign (hurry and register yours today!).

Most of the complaints center on the fact that there is still no central release authority or process for FFmpeg. My usual response to this is that the leadership of FFmpeg is committed to making releases eventually (this may seem non-committal but many people are still under the impression that the leadership is actively opposed to releases). It’s just that doing so takes work, planning and — get ready for it — testing. Honestly, why do you think I have been working on FATE? I want it to serve as a baseline to build confidence that the code, you know, actually works before we make any releases.

I’m not mad, though. It’s all right. I mean, seriously, what are people going to do about the situation? Refuse to use FFmpeg? Maybe fork the codebase? Heh, I dare you. FFmpeg is only as capable as the talent developing it. Better yet, is someone going to start a competing project from scratch to supplant FFmpeg? Seriously, get a grip and calm down before you hurt yourself, then we’ll talk about what we can all do together to improve FFmpeg and work toward a release schedule.

Unfortunately, we just got received a few thousand files that crash FFmpeg. That might push back the release schedule a bit. You want a reliable and secure multimedia backend library, I trust?

Related:

Processing Those Crashers

I know my solutions to certain ad-hoc problems might seem a bit excessive. But I think I was able to defend my methods pretty well in my previous post, though I do appreciate the opportunity to learn alternate ways to approach the same real-world problems. But if you thought my methods for downloading multiple files were overkill, just wait until you see my solution for processing a long list of files just to learn — yes or no — which ones crash FFmpeg.

So we got this lengthy list of files from Picsearch that crash FFmpeg, or were known to do so circa mid-2007. Now that I have downloaded as many as are still accessible (about 4400), we need to know which files still crash or otherwise exit FFmpeg with a non-zero return code. You’ll be happy to know that I at least know enough shell scripting to pull off a naive solution for this: Continue reading →