Category Archives: FATE Server

FATE Building Blocks

For 2 years, I’ve been wrangling with the overall architecture of the FATE system. Right now, there’s a primary fate-script.py program that manages building and testing on FATE installations that is sorely in need of many upgrades. Then there is fate-client.py which is a somewhat lighter-weight testing program. I have long wanted to merge the 2 scripts but could never settle on how to do it. At the base level, should the script assume that it’s operating in continuous build/test mode (a la fate-script.py) or single-shot test mode (a la fate-client.py) by default? Or neither? Should it force the user to specify a mess of command line options?

I had an epiphany recently while reading the documentation for Python’s standard (as of v2.3) optparse module, specifically the section entitled “What are options for?”

Options are used to provide extra information to tune or customize the execution of a program. In case it wasn’t clear, options are usually optional. A program should be able to run just fine with no options whatsoever… Lots of people want their programs to have ‘required options’. Think about it. If it’s required, then it’s not optional!

This led me to consider the possibility of a FATE script that could do something without any options and then build from there.

Default Operation Continue reading →

Thinking About Programming

Do you ever think about programming? Rather, do you ever think about how you think about programming?

You have to start somewhere
Indeed, the whole reason I got into computer programming in the first place was because I wanted to program games. It was circa 1991-1992 when I got heavily interested in programming computers. 286 CPUs running MS-DOS represented the platform I had access to. I was trying to transcend GW-BASIC and learn Turbo Pascal and Turbo Assembler. A little game called Test Drive III was one of the most remarkable titles I had seen running on this type of hardware at the time. Not only did the game do polygonal 3D graphics but it had sound support through various sound cards or the PC speaker.



At the time I was trying to understand how to do decent 2D graphics programming as well as audio programming (background music, sound effects). I had access to a friend’s Sound Blaster and after lots of research (solid, useful programming data was notoriously scarce) and plenty of trial and error hacking assembly language, I finally got the Sound Blaster to make a few blips. I probably still have the code in my archive somewhere.



I didn’t write this post just for my own sentimental programming nostalgia; there’s a punchline here: Continue reading →

Compatibility Testing With FATE

Once upon a time, I made a valiant effort to create a compatibility page for FFmpeg. The goal was simple– document how to use FFmpeg to generate media files that would play back in the most common media players of the day. At the time, this included Windows Media Player and Apple QuickTime Player. The exercise was naturally obsolete quite quickly due to the fact that I used some random SVN revision (actually, this is so old that I think we were still using CVS at the time).

I still think this is a worthwhile idea. I now realize that the idea can be improved by FATE. Create a series of test specs that map to a certain encoding combination known to work on a popular media player (or even a popular media device– this could be used for testing, e.g., iPod profiles) and document the command lines on the website. When one of the command lines breaks for all configurations, it will be worth investigating to learn why and whether the website example needs to be updated, or whether FFmpeg needs to be fixed.

Testing process:

  • Develop command line that should produce content playable for popular software player or device
  • Transcode sample media with command line
  • Test media on target player to make sure it plays
  • Enter FATE test spec
  • Document command line on compatibility page

Such a FATE test will be contingent upon a built-in file checksumming feature as I have outlined for a future revision.

Testing Older Snapshots With FATE

Suppose FATE had the infrastructure to test arbitrary branches of FFmpeg. I just realized that it wouldn’t necessarily help because the FATE test specs keep changing as the code is adjusted. This implies that there needs to be more sophisticated test management.

This occurred to me due to the chatter surrounding the recent FFmpeg 0.51 security release. Running the FATE suite against 0.51 doesn’t work since the current state of the various FATE tests are contingent upon the current mainline FFmpeg source. Possible solutions going forward? Perhaps upgrade the FATE database to support some kind of versioning? However, this would also limit my ability to monkey with the existing FATE suite of samples.