Author Archives: Multimedia Mike

Sink Your Fangs

Check out snakebite. Some folks associated with the Python programming language put together a farm of computers that all Python committers have access to so that they can code and test. They put together an impressive network, though the PowerPC architecture is suspiciously unrepresented in any incarnation that I can find. They received some notable corporate sponsorship too, according to the announcement email on python-committers.

Wouldn’t it be neat to set up something like this for FFmpeg folks? Actually, I tend to think our first and foremost concern would be to get a community-accessible PowerPC machine for debugging various woes on that platform. My PowerPC-based Mac Mini is overcommitted as it is. I happen to be personally familiar with at least one large corporation that has an unbelievable pile of PowerPC-based Macs in its basement (along with loads of other computers), waiting to recycled one day. Regrettably, they have no policy for repurposing the computers for non-corporate functions.

And I don’t want to hear anything about how hard it would be to debug problems in a multimedia program on a remote computer halfway around the world while only interacting via terminal. I did a significant amount of debugging and performance profiling of FFmpeg’s VP3 decoder once upon a time under those very circumstances. My trick, when I had to view the results of a decode operation, were to write the video frames to individual JPEG files. Then, I would run webfs to serve those JPEGs via HTTP to the localhost IP address and tunnel it back to my own machine via SSH to view in a local web browser.

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.

Alpha FATE

Do you remember the DEC Alpha CPU? Måns Rullgård does. He still has his unit in service and running Linux. So why not run FATE? Just like FFmpeg supports impossibly obscure multimedia formats, why shouldn’t it also support CPU types of approximately the same prevalence? In both cases, as long as the support overhead is not too arduous, it’s not a problem.

What I’m saying here, in case I was unclear, is that Måns has an Alpha CPU contributing build/test results to the central FATE database.

In other FATE news, today was a very busy day. I carefully evaluated and entered 18 new test specs:

With this, I have eliminated much of the low-hanging fruit on the FATE Test Coverage wiki page. My excuses to avoid testing the more complicated (read: bit inexact) formats are dwindling.

Meanwhile, the front page of FATE is reaching critical mass. I really need to come up with a new presentation because the front page is getting harder and harder to digest.