Michael suggested on the FFmpeg-devel list that Doxygen documentation ought to be continuously generated so that any errors and warnings during documentation generation can be caught, logged, analyzed, and minimized. However, the consensus was that it’s not especially useful to add this to the master FATE suite of test specs.
Another item that came up in the discussions of a possible release is that one of our tests should be the processing of an entire DVD-length movie to catch any problems (like memory leaks) that only manifest over a long runtime. Obviously, that’s not especially appropriate for a normal FATE test spec.
And another type of test that I envisioned when I was originally brainstorming the system (for a year and a half) is a way to continuously fuzz-test FFmpeg. But, like the previous 2 items, it does not need to be performed on every code commit.
I realized that all of these tasks (and probably more– be creative) can be run on a less frequent basis — say, once per day — and on one machine (like the fastest machine on my farm). It can be set up as an adjunct project to FATE.
Now I need a good FFmpeg command line for converting a ripped DVD image to another format that will maximally stress the program, in a multithreaded manner, no less.
For the doxygen stuff, here’s a script I made for the same purpose.
Schedule this with cron to autogenerate doxygen docs on a website from svn dox.
add to your crontab file:
MAILTO=”mailinglist@address”
now stderr output (doxygen warnings) will go to the mail address
and then crontab line:
*/20 * * * * /home/ml/scripts/backup/gen_doxygen_docs.sh https://svn-repo.url/xxx/ xxx_docs /var/www/docs/xxx
—- gen_doxygen_docs.sh —-
#!/bin/sh
REPO=$1
DOX_FILE=Doxyfile
TMP_DIR0=/tmp/backup_tmpXXX
TMP_DIR=$TMP_DIR0/$2
WEB_DIR=$3
mkdir $TMP_DIR0 2> /dev/null
mkdir $TMP_DIR 2> /dev/null
cd $TMP_DIR
rm -rf *
svn –force –ignore-externals export $REPO $TMP_DIR > /dev/null
doxygen $DOX_FILE > /dev/null 2>&1
rm -rf $WEB_DIR/*
mv -f $TMP_DIR/doxygen/html/* $WEB_DIR
# cleanup
rm -rf $TMP_DIR
And here’s an example of a program that is banging the leaving daylights out of libav and running valgrind on every ffmpeg checkin:
http://build.xuggle.com/job/xuggle_java_xuggler_jdk5_i386_ubuntu_memcheck/
See the artifacts for the raw log files. It tests specifically:
decoding nellymoser, mp3 and aac audio
encoding mp3 and pcm audio
decoding on6, h263 and h264 video
encoding h263 video
It doesn’t test encoding nellymoser audio because it turns out the nellymoser encoder in ffmpeg access uninitialized memory (which Valgrind finds). I really need to file a bug on FFMPEG for that.
@Martin: Nice, but I will would be more interested in logging the results to a database rather than filling up a mailbox.
@Art: Continuous valgrind’ing is another great idea, but I wasn’t sure if the process was automatable.