Results
Here is the spreadsheet of results, reflecting FATE code coverage as of this writing. All FFmpeg source files are on the same sheet this time, including header files, sorted by percent covered (ascending), then total lines (descending).

Methodology
I wasn’t easily able to work with the default output from the gcovr tool. So I modified it into a tool called gcovr-csv which creates data that spreadsheets can digest more easily.

• Build FFmpeg using the '-fprofile-arcs -ftest-coverage' in both the extra cflags and extra ldflags configuration options
• 'make'
• 'make fate'
• From build directory: 'gcovr-csv > output.csv'
• Massage the data a bit, deleting information about system header files (assuming you don’t care how much of /usr/include/stdlib.h is covered — 66%, BTW)

Leftovers
I became aware of some spreadsheet limitations thanks to this tool:

1. OpenOffice can’t process percent values correctly– it imports the percent data from the CSV file but sorts it alphabetically rather than numerically.
2. Google Spreadsheet expects CSV to really be comma-delimited– forget about any other delimiters. Also, line length is an issue which is why I needed my tool to omit the uncovered line number ranges, which it does in its default state.

It’s a small form factor Shuttle PC (SD37P2 v2); Core 2 Duo 2.13 GHz; 2 GB RAM; 400 GB SATA HD; equipped with the only consistently functional optical drive in my house (uh oh). I used it as my primary desktop from March 2007 – November 2008, at which point I repurposed it for FATE cycles.

As mentioned, the craziest part is that this is technically the best computer in my house. My new EeePC 1201PN isn’t at quite the same level; my old EeePC can’t touch it, of course; the Mac Mini has a little more RAM but doesn’t stack up in nearly all other areas. But the Shuttle just isn’t seeing that much use since the usurpation. I had it running automated backup duty for multimedia.cx but that’s easy enough to move to another, lower-powered system.

Maybe the prognosticators are correct and the PC industry has matured to the point where raw computing power simply doesn’t matter anymore. I fancy myself as someone who knows how to put CPU power to work but even I don’t know what to do with the computing capacity I purchased over 3 years ago.

Where will the Shuttle go? A good home, I trust– I know a family that just arrived in the country and could use a computer.

New Tests
As I write this, I noticed that there are now an even 700 tests, twice as many as the last time I trumpeted such a milestone. (It should be noted that the new FATE system finally breaks down the master regression suite into individual tests.) Thankfully, it’s no longer necessary to wait for me to create or edit tests (anyone with FFmpeg privileges can do this), nor is it necessary to keep up with this blog to know exactly what tests are new. Now, you can simply inspect the file history on tests/fate.mak and tests/fate2.mak (I think these 2 files are going to merge in the near future).

Vitor, as of r24865: “Add FATE test for ANSI/ASCII animation and TTY demuxer.” Eh? What’s this about? I admit I was completely removed from FFmpeg development for much of June and July so I could have missed a lot. Fortunately, I can check the file history to see which lines were added to make this test happen. And if FATE is exercising the test, you know exactly where the samples will live. Here’s this new decoder in action on the relevant sample:

The file history fingers Suxen drol/Peter Ross for this handiwork. I might have guessed– the only person who is arguably more enamored with old, weird formats than even I. Now we wait for the day that YouTube has support for this format. I’m sure there are huge archives of these animations out there (and I wager that Trixter and Jason Scott know where).

It’s an animation — it just keeps going

Meanwhile, the FATE suite now encompasses a bunch of perceptual audio formats, thanks to the 1-off testing method and a few other techniques. These formats include Bink audio, WMA Pro, WMA voice, Vorbis, ATRAC1, ATRAC3, MS-GSM, AC3, E-AC3, NellyMoser, TrueSpeech, Intel Music Coder, QDM2, RealAudio Cooker, QCELP (just going down the source control log here), and others, no doubt.

Then there’s this curious tidbit: “Add FATE test for WMV8 DRM”. The test spec is "fate-wmv8-drm: CMD = framecrc -cryptokey 137381538c84c068111902a59c5cf6c340247c39 -i $(SAMPLES)/wmv8/wmv_drm.wmv -an". I would still like to investigate FFmpeg’s cryptographic capabilities, which I suspect are moving in a direction to function as a complete SSL stack one day.

New Platforms
As for new platforms, the new FATE system finally allows testing on OS/2 (remember that classic? It was “the totally cool way to run your computer”). Thanks to Dave Yeo for taking this on.

Further, a new MIPS-based platform recently appeared on the FATE list. This one reports itself as running on 74kf CPU. Googling for this processor quickly brings up Mans’ post about the Popcorn Hour device. So, congratulations to him for getting the mundane box to serve a higher purpose. Perhaps one day, I’ll be able to do the same for that Belco Alpha-400 netbook.

The primary GNU code coverage tool is called gcov and is probably already on your GNU-based development system. I set out to determine how much FFmpeg source code is exercised while running the full FATE suite. I ran into some problems when trying to use gcov on a project-wide scale. I spackled around those holes with some very ad-hoc solutions. I'm sure I was just overlooking some more obvious solutions about which you all will be happy to enlighten me.

Results
I've learned to cut to the chase earlier in blog posts (results first, methods second). With that, here are the results I produced from this experiment. This Google spreadsheet contains 3 sheets: The first contains code coverage stats for a bunch of FFmpeg C files sorted first by percent coverage (ascending), then by number of lines (descending), thus highlighting which files have the most uncovered code (ffserver.c currently tops that chart). The second sheet has files for which no stats were generated. The third sheet has "problems". These files were rejected by my ad-hoc script.

Here's a link to the data in CSV if you want to play with it yourself.

Using gcov with FFmpeg
To instrument a program for gcov analysis, compile and link the target program with the -fprofile-arcs and -ftest-coverage options. These need to be applied at both the compile and link stages, so in the case of FFmpeg, configure with:

  ./configure \
    --extra-cflags="-fprofile-arcs -ftest-coverage" \
    --extra-ldflags="-fprofile-arcs -ftest-coverage"

The building process results in a bunch of .gcno files which pertain to code coverage. After running the program as normal, a bunch of .gcda files are generated. To get coverage statistics from these files, run 'gcov sourcefile.c'. This will print some basic statistics as well as generate a corresponding .gcov file with more detailed information about exactly which lines have been executed, and how many times.

Be advised that the source file must either live in the same directory from which gcov is invoked, or else the path to the source must be given to gcov via the '-o, --object-directory' option.

Resetting Statistics
Statistics in the .gcda files are cumulative. Should you wish to reset the statistics, doing this in the build directory should suffice:

  find . -name "*.gcda" | xargs rm -f

Getting Project-Wide Data
As mentioned, I had to get a little creative here to get a big picture of FFmpeg code coverage. After building FFmpeg with the code coverage options and running FATE,

for file in `find . -name "*.c"` \
do \
  echo "*****" $file \
  gcov -o `dirname $file` `basename $file` \
done > ffmpeg-code-coverage.txt 2>&1

After that, I ran the ffmpeg-code-coverage.txt file through a custom Python script to print out the 3 CSV files that I later dumped into the Google Spreadsheet.

Further Work
I'm sure there are better ways to do this, and I'm sure you all will let me know what they are. But I have to get the ball rolling somehow.

There's also TestCocoon. I'd like to try that program and see if it addresses some of gcov's shortcomings (assuming they are indeed shortcomings rather than oversights).

Source for script: process-gcov-slop.py

Under my old regime I tracked test coverage as a wiki page which was a highly flawed method-- tedious and error-prone. There are those 2 adjectives again-- tedious and error-prone; whenever I see those, I search for automation methods. I think that might be more plausible thanks to the new FATE's tighter integration with the FFmpeg build system.

I don't think anyone is working on this problem so I wanted to toss out a brainstorm:

1. First, run 'ffmpeg -formats', 'ffmpeg -codecs', etc. and parse the output to collect a list of all the features (full list: -formats, -codecs, -bsfs, -protocols, -filters, -pix_fmts). Transform these lists into a standardized list of features, e.g., "DEVSD ffvhuff Huffyuv FFmpeg variant" represents features 'decode-video-ffvhuff', 'encode-video-ffvhuff', 'ffvhuff-horizband', and 'ffvhuff-dr1'.
2. Next, tag each individual test spec with the features that it exercises. E.g., test 'fate-vqa-cc' exercises features 'demux-wsvqa', 'decode-video-vqavideo', and 'decode-audio-adpcm_ima_ws'.
3. Finally, compare the data from parts 1 and 2. Print a list of all the features that are not exercised in FATE.

I think a lot of this could be implemented at the GNU make level. Then again, I'm no expert on GNU make syntax so I may be overestimating its capabilities. Or there might be simpler ways to automatically track test coverage stats based on the improved testing infrastructure.

Fortunately, Mans solved this conundrum with an elegantly simple solution:

The top of the page displays a status bar that illustrates -- at a glance -- how functional the codebase is. The web page source code identifies this as the failometer. It took me a few seconds to recognize what information that status bar was attempting to convey; maybe it could use a succinct explanation.

Mini-Book Review

Before Mans took over, I thought about this problem quite a bit. I needed inspiration for creating a better FATE main page and aggregating a large amount of data in a useful, easily-digested form. Looking around the web, I see no shortage of methods for visualizing data. I could start shoehorning FATE data into available methods and see what works. But I thought it would be better to take a step back and think about the best way to organize the data. My first clue came awhile ago in the form of an xkcd comic: Blogofractal. Actually, the clue came from the mouseover text which recommended Edward Tufte's "The Visual Display of Quantitative Information".

I ordered this up and plowed through it. It's an interesting read, to be sure. However, I think it illustrates what a book on multimedia and compression technology would look like if authored by yours truly-- a book of technical curiosities from epochs past that discusses little in the way of modern practical application. Tufte's book showed me lots of examples of infographics from decades and even centuries past, but I never concisely learned exactly how to present data such as FATE's main page in a more useful form.

Visualization Blog
More recently, I discovered a blog called Flowing Data, authored by a statistics Ph.D. candidate who purportedly eats, sleeps, and breathes infographics. The post 11 Ways to Visualize Changes Over Time: A Guide offers a good starting point for creating useful data presentations.

I still subscribe to and eagerly read Flowing Data. But I might not have as much use for data visualization now that Mans is on FATE duty.

Overview
Here are the distinguishing features that Mans mentioned in his announcement message:

• Test specs are part of the ffmpeg repo. They are thus properly versioned, and any developer can update them as needed.
• Support for inexact tests.
• Parallel testing on multi-core systems.
• Anyone registered with FATE can add systems.
• Client side entirely in POSIX shell script and GNU make.
• Open source backend and web interface.
• Client and backend entirely decoupled.
• Anyone can contribute patches.

Client
The FATE build/test client source code is contained in tests/fate.sh in the FFmpeg source tree. The script -- as the extension implies -- is a shell script. It takes a text file full of shell variables, updates source code, configures, builds, and tests. It's a considerably minor amount of code, especially compared to my original Python code. Part of this is because most of the testing logic has shifted into FFmpeg itself. The build system knows about all the FATE tests and all of the specs are now maintained in the codebase (thanks to all who spearheaded that effort-- I think it was Vitor and Mans).

The client creates a report file which contains a series of lines to be transported to the server. The first line has some information about the configuration and compiler, plus the overall status of the build/test iteration. The second line contains './configure' information. Each of the remaining lines contain information about an individual FATE test, mostly in Base64 format.

Server
The server source code lives at http://git.mansr.com/?p=fateweb. It is written in Perl and plugs into a CGI-capable HTTP server. Authentication between the client and the server operates via SSH/SSL. In stark contrast to the original FATE server, there is no database component on the backend. The new system maintains information in a series of flat files.

A new FATE

Mike's FATE system has done a great job over the last few years. It
is however beginning to prove inadequate in various ways:

[various shortcomings already dissected at length on this very blog]

To address the above-mentioned issues, I have been working on a
replacement system which is now ready to be announced.

Check it out: http://fate.ffmpeg.org/.

Considering that he just obsoleted something I've poured a lot of time and energy into over the last 2.5 years, is my first reaction to this news supposed to be unbridled joy? Hey, I'm already on record as stating that I wouldn't mind throwing away all of FATE if there was a better alternative.

I'm not certain but I'm pretty sure that at this point, the original FATE server is practically obsolete. Mans is already testing all of his configurations as well as the configs I test. As soon as the other FATE installations switch over to the new server, I should be able to redirect fate.multimedia.cx -> fate.ffmpeg.org, sell most of my computers, and spend more time with my family.

Thanks, Mans!

But when I step back and look at the graph, I can't rationalize why there should be a separate results aggregator thread. That was added to cut down on deadlock possibilities since the main thread and the tester threads would not be waiting for data from each other. Now that I've come to terms with the fact that the main and the testers need to exchange data in realtime, I think I can safely eliminate the result thread. Adding more threads is not the best way to guard against race conditions and deadlocks. Ask xine.

I'm still hung up on the deadlock issue. I have these queues through which the threads communicate. At issue is the fact that they can cause a thread to block when inserting an item if the queue is "full". How full is full? Immaterial; seeking to answer such a question is not how you guard against race conditions. Rather, it seems to me that one side should be doing non-blocking queue operations.

This is how I'm planning to revise the logic in the main thread:

test_set = set of all tests to execute
tests_pending = test_set
tests_blocked = empty set
tests_queue = multi-consumer queue to send test specs to tester threads
results_queue = multi-producer queue through which tester threads send results
while there are tests in tests_pending:
  pop a test from test_set
  if test depends on any tests that appear in tests_pending:
    add test to tests_blocked
  else:
    add test to tests_queue in a non-blocking manner
    if tests_queue is full, add test to tests_blocked

  while there are results in the results_queue:
    get a result from result_queue in non-blocking manner
    remove the corresponding test from tests_pending

if tests_blocked is non-empty:
  sleep for 1 second
  test_set = tests_blocked
  tests_blocked = empty set
else:
  insert n shutdown signals, one from each thread

go to the top of the loop and repeat until there are no more tests

while there are results in the results_queue:
  get a result from result_queue in a blocking manner

Not mentioned in the pseudocode (so it doesn't get too verbose) is logic to check whether the retrieved test result is actually an end-of-thread signal. These are accounted and the whole test process is done when one is received for each thread.

On the tester thread side, it's safe for them to do blocking test queue retrievals and blocking result queue insertions. The reason for the 1-second delay before resetting tests_blocked and looping again is because I want to guard against the situation where tests A and B are to be run, A depends of B running first, and while B is running (and happens to be a long encoding test), the main thread is spinning about, obsessively testing whether it's time to insert A into the tests queue.

It all sounds just crazy enough to work. In fact, I coded it up and it does work, sort of. The queue gets blocked pretty quickly. Instead of sleeping, I decided it's better to perform the put operation using a 1-second timeout.

Still, I'm paranoid about the precise operation of the IPC queue mechanism at work here. What happens if I try to stuff in a test spec that's a bit too large? Will the module take whatever I give it and serialize it through the queue as soon as it can? I think an impromptu science project is in order.

big-queue.py:

$ ./big-queue.py
reader function got a string of 100000000 characters

Since 100 MB doesn't even make it choke, FATE's little test specs shouldn't pose any difficulty.

History
The test spec system has been handled by a single table that includes an FFmpeg command line (with a few possible modifiers thrown in), an integer ID, a human-friendly ID, a description, the expected command line return code, the expected command output, a maximum runtime, and a Boolean to indicate whether the test is to be considered active.

Adjunct to this test database is a large corpus of test media named the FATE suite.

At first, the FATE testing script used a direct MySQL database protocol to query the test specs from the server before every build/test cycle. I soon realized this was ludicrously inefficient since the test specs don't change that often. So I cached the tests in a static file to be retrieved via HTTP, first in Python's "pickled" (serialized) format, then in an SQLite database.

Planned Upgrades
There are 2 major features I would like to build into the system going forward:

1. The ability to version the entire suite so that it's possible to test old branches of FFmpeg
2. Another database field to indicate which, if any, other test specs must be executed before this spec can be executed

I think I will take this opportunity to switch the test cache serialization format to JSON. I switched from Python pickling to SQLite because the latter was more portable between languages. JSON has that same benefit. Further, working with JSON data doesn't require a round trip to disk (i.e., want to generate an SQLite database for sending via HTTP? It needs to go onto disk first. It's possible to create and manipulate a database entirely in memory but not fetch the bits).

Things To Research

• Pondering how version control systems operate and what they have to teach regarding how to version this data (including the question of whether I can just use an existing version control mechanism instead of creating my own system)
• Efficient caching mechanism
• Tagging test specs for alternate purposes such as longevity testing
• Learn about web form programming in the 21st century so that it's not quite as painful to maintain the system.

Preliminary Versioning Concept
Here is one approach I am thinking of: Create test groups. Each test spec is assigned to at least one test group. I can think of at least 2 groups: functional (the base test set in existence that validates functionality) and profiling (the projected test set that will be used for ongoing performance and memory profiling). The web frontend will allow for the creation of labels that will apply to a single group. Doing so will apply that label to all active tests in the group.