In case you don’t carefully track FFmpeg development, much recognition goes out to Michael for a lot of work on the H.264 decoder. Thanks to his efforts over the past week or so, I have been able to add about 2 dozen more H.264 conformance tests. Presently, FFmpeg can decode 92/136 of the suite’s vectors across all supported configurations.
Also, finally, I have started to add encoding tests to FATE. The first test is designated idroq-video-encode. I was stuck on this for awhile while I tried to understand what sort of test material I should use. I eventually realized that there are perfectly adequate (and stunningly complicated) images already generated by FFmpeg’s videogen.c program that is built and run by ‘make test’. If you are not familiar, they look like this:
Some people attack that graph as being outdated. They’re right, you know– I really should update it to see how much more of a mess the situation currently is. I showed the graph to the leader of the PulseAudio project at LinuxTag in 2007 and he was quick to point out that it was missing quite a few tangled vines. I wager that there are 3 or 4 more boxes to add as well.
What strikes me as I review LH’s growing archive is how few topics he has touched on. I keep reading since I am confident he will eventually cover them.
New format showcase time! Gregory Montoir contributed to FFmpeg a playback system for MVI files, which are a custom container for transporting Motion Pixels video data. Another format down.
It’s a little unclear how this format differs from the more familiar MVI1 and MVI2 codecs that are encapsulated inside AVI files. But this is probably a big step towards supporting those formats as well.
Peter Ross/Suxen drol is up to his old tricks by contributing a decoder for CMV files. Here’s what our one sample looks like:
After a brief hiccup, FATE is back online, and with some new tests: motionpixels and ea-cmv, for the formats listed above, and duck-dk4.
I had to disable the gcc-svn configurations corresponding to 32- and 64-bit x86 architectures on the FATE Server. When I upgraded the compilers to the latest ones from gcc SVN repository, the compiled results were hanging indefinitely in some cases (such as the HuffYUV regression test on x86_32). This makes FATE significantly less productive since the ‘make test’ test spec has such a long timeout. That reminds me of another reason why I wanted to split out those regressions into individual test specs.
It sounds bugworthy, as is the fact that the gcc-svn compiler for PowerPC has about a 50% chance of compiling FFmpeg without encountering an internal compiler error. It would be responsible of me to report these bugs to gcc. I think the main thing that stops me is that the guidelines for submitting gcc bugs are even more frightening than those for FFmpeg. The HuffYUV hang bug really scares me since it implies tracking down incorrectly compiled code.
