Author Archives: Multimedia Mike

The Downside Of Contributions

The prolific Jeff Atwood has a blog post entitled Don’t Go Dark which describes the issue of programmers retreating into their chambers for months on end to create the perfect feature; at the conclusion, said programmers drop the feature on the community at large hoping for its immediate and wholesale incorporation into the project’s mainline codebase. As you can imagine, FFmpeg lends itself well to this style of lone-wolf development. Unfortunately, it also conflicts with FFmpeg’s level of code maturity which necessitates that every line of code be carefully scrutinized before it is allowed possible immortality in the mainline tree. This leads to a tremendous amount of orphaned patches. Should FFmpeg maintain such a strict policy? Personally, I agree with the project leader in his position that, if the changes are not made before inclusion, the changes will likely never be made.

There’s another angle that I don’t think was addressed by Jeff’s post. It’s a problem we saw repeatedly on the xine project. Companies who were doing things like set-top media boxes were understandably eager to incorporate xine’s superior — and fee-free – media playback architecture. Naturally, it took some… tweaking and customizations (read: ad-hoc hacks) in order to get the stuff to work just right with a specific setup, and within a deadline. When the project was complete, an engineer would drop a mega-patch with all of their changes to the xine codebase, as mandated by the GNU GPL. And it was quite useless to us.

I’m not sure what to do about the latter case. With the former, it is useful to at least anticipate developing your module in somewhat bite-sized phases that can perhaps be incorporated in separate patches.

English Phonetic CAPTCHA

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.

QT And Duck FATE Tests

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.

Pickled FATE

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