More new test specs tonight:
I meant to add the QT SMC and RLE tests some months ago. But in a fit of programming purity, I opted instead to log some bugs for myself to fix before I added test specs. However, I remembered that I should get as much basic functionality covered by the FATE suite first. SMC works, except in some odd resolution cases; same for QT RLE. Most of those 2 decoders’ code paths work and I want to be able to catch regressions sooner than later.
I also been tightening up some older video decoder tests. I used to have a problem when using “-f framecrc” for output where FFmpeg was outputting a huge number of identical frames at very short periods. Michael tipped me off somewhere along the line that I should use “-vsync 0” in such cases to effectively eliminate the duplicates. I still don’t understand exactly what that option does but it works splendidly.
One thing I was thinking: how hard would it be to add valgrind testing (as if it where another box) to FATE? Maybe it could could be useful to detect (and avoid new) illegal reads/writes and memory leaks…
That’s actually a brainstorm I had from the beginning. But I’m not sure how well valgrind supports what we need; it just might. Namely, I would like to be able to run it in a mode where it could concisely summarize any problems it found without a lot of verbose output.
I also envision that we wouldn’t necessarily have to automate this process. Rather, we could probably modify the fate-client.py script to do the work manually.
/me prepares cover already
valgrind’s memcheck can output XML… as much as people hate that, it’s an almost concise output :)