Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Archives:

QT And Duck FATE Tests

May 27th, 2008 by Multimedia Mike

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.

Posted in FATE Server | 3 Comments »

3 Responses

  1. Vitor Says:

    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…

  2. Multimedia Mike Says:

    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.

  3. Diego 'Flameeyes' Pettenò Says:

    /me prepares cover already

    valgrind’s memcheck can output XML… as much as people hate that, it’s an almost concise output :)