So I set up the RPC testing tool in such a way that it includes not only all 8 Linux/x86_32 configurations, but also the Mac/PPC configuration. So when I launch the RPC tool, I am testing a command line across 21 different combinations of platform/compiler configurations for FFmpeg.

That, my friends, is power.

Thanks to this new tool — nay, superpower — I have efficiently updated and reinstated the following test specs:

• armovie-escape124
• motionpixels
• qtrle-16bit
• vmnc-16bit
• vmnc-32bit

Even though I am asking for input from the Mac/PPC build, it’s probably a good thing that it is not part of the overall test environment yet. There are more than a few tests (most RGB colorspace video decoders) for which the Mac/PPC build’s output varies from all the other platforms, even the Linux/PPC configurations. I don’t know where the discrepancy lies.

Further, I have finally gotten back to adding new test specs. Predictably, the major bottleneck now is the web administration interface. Working from my notes in the FATE Test Coverage MultimediaWiki page, I added these tests:

• fraps-v3
• indeo2
• nuppelvideo
• qtrle-1bit
• qtrle-2bit
• tiertex-seq

In case I haven’t adequately articulated my case, let me reiterate that this RPC test staging tool is really neat. When testing a spec, I craft the most unremarkable command line (ffmpeg -i file -f framecrc -) and see the results. If there is an endian clash — i.e., all the big endian configurations hold one opinion about the stdout vs. the little endian configurations — I check the native colorspace of the video decoder. If it’s an RGB-based video codec, I refine the command line with a “-pix_fmt rgb24” to normalize the colorspace and dispatch the command again. If the video codec is YUV-based and I know or suspect it involves a DCT, I refine the command with “-idct simple” and send it out again.