Jeff Atwood writes of automated spamming recently in Designing For Evil. The ensuing discussion.presented plenty of technical anti-spam brainstorms as well as the usual violent anti-spammer fantasies. However, one interesting insight I gained from the comment thread concerned the automated nature of Wikipedia’s anti-spam measures:

There is an IRC channel that receives every edit done to Wikiepdia, a bot then check the page for known bad URLs and string and reverts if necessary.

Aha! So it isn’t just a global network of diligent and vigilant volunteer Wikipedians keeping the content clean. That always struck me as largely intractable and learning this punctures the starry-eyed ethos behind the Wiki concept. But I did a little research and it seems to be a real thing.

I suppose something like that would be vast overkill for the MultimediaWiki. As the discussion also details, not all public discussion forums are created equally in terms of attractiveness to spammers, and the MultimediaWiki would probably be pretty far down the list. Some kind of registration CAPTCHA would probably be adequate. And now that I understand a little more about PHP programming thanks to FATE, I may have enough knowledge to try my hand at such a system.

Hey, here’s a CAPTCHA idea that I have entertained: Call it a phonetic CAPTCHA and challenge the user to type in the proper English word with a certain phonetic pronunciation; for example: KAH MEW NIK AY SHUNZ (communications). I was inspired by Infocom’s old Planetfall interactive fiction game where things were labeled phonetically. Perhaps it discriminates against non-native English speakers (and the less educated among the native set) as well as the spambots, but I guess every measure has its pros and cons.

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.

Some people have been checking out the new test client described in the previous post. So far, most of the questions I have received concern the format of the fate-test-cache.bz2 file downloaded from the FATE server. I admire that people are taking an interest in file format particulars -- as you know, I encourage that. It's nothing too special, though. I simply have a Python script called update-test-cache.py that queries FATE's test_spec table into an array of dictionary data structures. Then it serializes/marshals/flattens the data using Python's built-in pickle module. It's trivial to de-pickle on the client-side. Of course, Python's bzip2 module helps with size concerns.

What's the pickle format? Darned if I know, but it works famously, so I don't really care about reinventing that wheel. Especially when the code for decompressing and deserializing boils down to these 3 lines of Python:

Also, about that rsync command I mentioned in the last post:

rsync -aL rsync://rsync.mplayerhq.hu:/samples/fate-suite/ samples

Does that actually work for anyone? Occasionally, it works for me. Most of the time, it tells me:

rsync: failed to connect to rsync.mplayerhq.hu: Can't assign requested address (49)
rsync error: error in socket IO (code 10) at /SourceCache/rsync/rsync-30/rsync/clientserver.c(94)

which, according to my searches, is a fairly generic network error (at least the bit about assigning the requested address). Since I am usually populating the sample repository manually anyway, this hasn't been a big problem. But I am trying to be more diligent about making sure the rsync repository is up to date since I expect more people will be using it.

Anyway, FATE growth plods on with 2 new tests tonight: nsv-demux and real-14_4 (weird, I just realized that the db assigned that one ID 144 completely by coincidence).

This evening, I finally got my fate-client.py script minimally ready for general consumption. fate-client.py is the unimaginatively named program I threw together some time ago to allow me to validate test specs before I activate them so that FATE will automatically test them. It works like this:

• download the script (http://fate.multimedia.cx/fate-client.py)
• rsync the FATE suite of samples that live on mphq: 'rsync -aL rsync://rsync.mplayerhq.hu:/samples/fate-suite/ samples' (without the quotes, of course) -- this presently amounts to ~150 MB
• build FFmpeg as normal
• './fate-client.py -f </path/to/ffmpeg-binary> -s </path/to/fate-suite/samples>'

That's it. The script will ask the FATE server for a set of test specifications and run through them. You may also need to specify -l/--libpath= if you built and installed FFmpeg with shared libraries. Naturally, './fate-client.py -h' will spell out all the options.

You would do well to make sure that all the options are valid or else suffer Python bailout exceptions. I just added the command line options tonight and have not made them very resilient. I have been promising this utility for a long time and I wanted to get something out there sooner than later.

Remember that I'm still a rank amateur at Python, so don't be afraid to call me out if I'm doing anything in the worst Pythonic way imaginable.

Ideas for future improvement:

• Better logging-- Instead of dumping to stdout, maybe dump all the results to a CSV file (for spreadsheet analysis) and/or an HTML file for easy viewing
• Proper versioning-- I track the script via a local git repository, but how do I communicate the current version? Would this be version dd394ef8f3dad056c39ab4e1c76951190621cf8b?
• Robust error handling
• Range testing (run all tests up to ID n, or run all tests after ID n, or from IDs m to n)
• Skip a list of tests (for example, it would be useful to skip test #128 -- the internal FFmpeg regression test -- since it's not that helpful in this particular scenario)
• [Your idea here]

It's open source, GPL v2, so patches welcome. Moreover, I would love to hear if this script works at all for anyone else. Then, I would like to hear how it works on platforms outside of the 3 that FATE now rigorously tests-- I speak of Mac OS X, *BSD, Win32 with either MSVC or MinGW, Open/Solaris on all its various platforms, even PlayStation 3 and whatever else. I actually did get that OpenSolaris VMware session to boot after I waited long enough but I had no idea how to do anything useful with it. That's when I decided to get down to it and get this script out there so that hopefully someone else will test those platforms.

Extra credit: Figure out why, when bailing out of the test sequence early with Ctrl-C, terminal character echo is off. I.e., the terminal refuses to print keystrokes.

Kostya recently lamented the matter of subtitle quality. I admit that subtitles are not a topic that I have traditionally cared very deeply about, popular though they may be in the multimedia scene. All the media I care about is generally already in English. Apparently, I'm one of the rare geeks who absolutely detests anime, so I have no reason to care about fansubs for media "imported," one way or another, from certain Pacific islands.

However, some time ago, I suddenly found a reason to care about subtitles. It turns out that subtitles don't have to contain bad translations. I'm a huge fan of the old TV show Mystery Science Theater 3000 (a.k.a. MST3K). In a nutshell, the silhouettes of a guy and his 2 robot puppets make fun of rotten movies. They crack an incredibly wide variety of jokes and it's unlikely anyone can understand every one of them. Leave it to a collaboration of internet geeks to develop an annotation project where users can submit quotes and annotations corresponding to particular timecodes in the lousy movies. These annotations go into a database where they can be downloaded as plaintext .srt subtitle files.

"Now what we're doin' here, Bob, is gettin' killed by a werewolf."

Pictured is an annotation I added for episode 0904 - Werewolf. This is nothing new in the context of DVDs -- I remember watching a popup trivia subtitle track on the Spider-Man DVD. But I'm wondering if there are other annotation projects like this one out there on the net for other niche areas of interest.

I'm pleased to announce that Jason Garrett-Glaser, a.k.a., Dark Shikari has moved his young blog under the multimedia.cx umbrella: Diary Of An x264 Developer. Looks promising, so keep up with it.

I have been sitting on the results of this little experiment for a month now. I was in a bit more of a hurry during the qualification period for this year's Summer of Code because I knew it would eventually yield a bumper crop of suitable qualification tasks. But that time has long passed.

The task at hand is to systematically survey the types of files that libsndfile can create, see what it can do that FFmpeg can't, and make a plan to get those formats into FFmpeg starting with listing them as small tasks.

Libsndfile comes with several small example utilities (something can FFmpeg could probably use instead of, or to supplement, one big utility). One such program is sndfile-convert

I had to modify sndfile-convert since not all of the supported formats were enumerated in its case-switch statements. The result of the above command was 120 unique format/codec combinations. I have uploaded all 120 cow moo samples (taken from the OpenOffice media suite, handy on my Eee PC when I was running this experiment).

How many of these 120 files can FFmpeg decode? I compiled FFmpeg with GSM 6.10 support and used the following command to print out FFmpeg return code and filename for each sample:

for file in `ls`; do
  ffmpeg -i $file -f wav - 1> /dev/null 2> /dev/null;
  echo $? $file;
done

The count is: 26 supported, 94 unsupported. Time to get to work. You wouldn't believe how many different ways there are to wrap raw PCM data with a basic file header for storage and transport.

Actually, closer inspection will reveal that FFmpeg is not necessarily ready to support all of these file formats since a number of them contain 24- or 32-bit integer PCM, or 32- or 64-bit floating point PCM; these are longstanding FFmpeg TODO items.

Libsndfile is actually the first program I have encountered that handles Apple Core Audio Format Files (CAF or CAFF). I haven't even found an Apple program that creates these, at least not among the offerings bundled with Mac OS X 10.5. Now that I have created some CAFs, I see that Apple's QuickTime Player plays them handily.

FFmpeg also doesn't support multichannel (more-than-stereo) audio very robustly in its present incarnation. Yeah, that's another item on the TODO list. Check out the complete specs for CAFF, however. I think if we made it a goal to support CAFF to its fullest (save perhaps for its pulse-width modulation provisions), FFmpeg's audio handling would reign supreme at the end of the journey.

For the curious, these are the 26/120 files that FFmpeg can decode at this time:

Read the rest of this entry »

Pursuant to that outlandish PAVC idea of mine (that I first started writing about 3 years ago), I began to tinker with the DosBox Video Codec, a.k.a. Zip Motion Blocks Video or ZMBV for short, which was suggested as an alternative the last time I posted about this topic. I have met with some mixed results.

Briefly, the goal of PAVC is to efficiently and losslessly compress frames of video generated by early video game systems, where "early" is defined as anything including and preceding the Super Nintendo Entertainment System. ZMBV is designed to compress, in real time, data from old DOS games running at a number of color modes, with careful consideration given to 8-bit palette data. FFmpeg had an independent ZMBV decoder soon after the codec appeared in DosBox, and also features an independent encoder as well; both the encoder and decoder come courtesy of Kostya.

Item 1: This past week, I found a way to improve the motion estimator in FFmpeg's ZMBV encoder by changing the assumption it used to compute error between 2 blocks. Michael, being the compulsive mathematical gambler that he is, said, "I'll see your rudimentary error minimizer and I'll raise you a 0^th-order entropy approximater." No, I don't understand what that means either. But the net result is that all 8-bit files that FFmpeg converts to ZMBV are notably more compact. Score 1.

Item 2: Read the rest of this entry »

Sun recently released a live CD for their OpenSolaris operating system. What's one more platform for testing FATE? They're all virtual anyway. Live CDs make us so spoiled these days.

I got the OS installed in a VMware [Fusion] session. But the operating system wouldn't boot after the boot loader told it to. I have not had a chance to troubleshoot the issue further.

I wonder what development tools are available under OpenSolaris? Does it just provide gcc? Or is there a proprietary Sun compiler for x86_64? I know Sun invests heavily in compiler optimization, but for their own Sparc hardware; I can't imagine they would pour any money into making code run well on other CPU architectures.

Today is historic in the grand timeline of technical multimedia documentation (near and dear to my heart): It's the day when Adobe released -- without any questionable license restrictions -- documentation for their SWF, FLV, and F4V file formats.

More details at my corporate blog.