Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Archives:

Less Frequent Tasks

January 29th, 2009 by Multimedia Mike

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.

Posted in FATE Server | 3 Comments »

3 Responses

  1. Martin Lindhe Says:

    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

  2. Art Clarke Says:

    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.

  3. Multimedia Mike Says:

    @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.