Tag Archives: ffmpeg

Less Frequent Tasks

Michael suggested on the FFmpeg-devel list that Doxygen documentation ought to be continuously generated so that any errors and warnings during documentation generation can be caught, logged, analyzed, and minimized. However, the consensus was that it’s not especially useful to add this to the master FATE suite of test specs.

Another item that came up in the discussions of a possible release is that one of our tests should be the processing of an entire DVD-length movie to catch any problems (like memory leaks) that only manifest over a long runtime. Obviously, that’s not especially appropriate for a normal FATE test spec.

And another type of test that I envisioned when I was originally brainstorming the system (for a year and a half) is a way to continuously fuzz-test FFmpeg. But, like the previous 2 items, it does not need to be performed on every code commit.

I realized that all of these tasks (and probably more– be creative) can be run on a less frequent basis — say, once per day — and on one machine (like the fastest machine on my farm). It can be set up as an adjunct project to FATE.

Now I need a good FFmpeg command line for converting a ripped DVD image to another format that will maximally stress the program, in a multithreaded manner, no less.

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.

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.