The year was 1999, the month was May, and Newsweek (an American weekly news periodical) had a cover feature entitled “What You’ll Want Next”. I remember the cover prominently featured a Sega Dreamcast controller (the console was slated for U.S. release a few months later). One of the features in the issue had an illustration of a future home and all the technological marvels that would arrive in coming years. I scanned the pictures and always wanted to write something about the prognostications contained within, some of which seemed a tad outlandish.

I never got around to it at then (plus, I had no good place to publish it). But look at the time– it’s 10 years later already! And I still have the page scans laying around, having survived moves to at least a 1/2 dozen “main desktop computers” over the intervening decade. So let’s have a look at where we were supposed to be by now.

Click for larger images

A Really Smart House

The home of the future will be loaded with appliances that talk to the Internet — and to each other. A high-speed Net connection links to set-top boxes and PCs; devices — from reading tablets to washing machine — are connected through a local wireless network. Though pervasive and powerful, the technology isn’t intrusive.

Read the rest of this entry »

Thanks to Måns for contributing FATE build/test results for the MIPS64 architecture, courtesy of his Gdium. This is in addition to his existing contributions for ARM, Alpha, and AVR32 architectures.

The Continuous Integration Maturity Model is a play on the Capability Maturity Model, something covered in software engineering curricula and then never seen again in the world of professional software development unless you happen to work for the U.S. government. But I digress.

The CIMM comes from a blog that is very concerned with continuous integration, perhaps because their business is CI software. The post has an ad-hoc table that lists various properties deemed to be worthwhile in CI systems. The table was apparently assembled by a committee of people meeting at a CI conference (who knew there was such a thing, or that I would actually have a reason to care?).

Aside: CIMM might not be the best acronym they could have used. CIMM already stands for the humorous Capability Immaturity Model.

The table has some interesting ideas, so let’s evaluate how FATE is doing using this frame of reference:

Read the rest of this entry »

Obviously, I have more than enough FATE-related work to keep my free time filled for the foreseeable future. But that doesn’t stop me from coming up with more ideas for completely revising the underlying architecture. And it’s always good to hash these ideas out on this blog since it: 1) helps me clarify the issues; 2) allows other people to jump in with improvements and alternatives; 3) allows me to put as much thought into these ideas as possible. Let’s face it– whatever design decisions I make for FATE are the ones the team tends to be stuck with for a long time.

People who dig into FATE and the various commands it executes in order to build and test FFmpeg often ask why I only perform singly-threaded builds, i.e., why not build with ‘make -j2′ on a dual-core machine? It would be faster, right? Well, yes, but only for the build phase. The test phase (which usually takes longer) is still highly serial (though the ‘make test’ regression suite can also be parallelized). A pragmatic reason I have for not wanting to multi-thread the build is that the stdout/stderr text lines can easily get jumbled which makes it more difficult to diagnose failures.

I do, however, put both cores on the main dual-core FATE machine to use– I run 2 separate installations of the FATE script, thus divvying the labor by having each core handle roughly half of the configurations. Thus far, one installation runs the x86_64 configs while the other installation is a 32-bit chroot environment running the x86_32 configs.

Can I come up with a better parallelization system? I think I might be able to. And to what end? Taking this whole operation to the next level, where “next level” is defined loosely as getting a few hundred more tests into the database while perhaps upgrading to a faster machine with more than 2 cores which is responsible for more than just native machine builds. Also, I am experimenting with moving the PowerPC builds to a faster (x86) machine for building. Better support for cross compiling and remote testing is driving some of this refactoring.

Read the rest of this entry »

I don’t get this whole cloud computing thing, and believe me, I have been trying to understand it. Traditionally, I have paid little attention to emerging technology fads; if a fad sticks, then I might take the time to care. But I’m being a little more proactive with this one.

From what I have been able to sort out, the idea is that your data (the important part of your everyday computer work), lives on some server “out there”, in the “cloud” that is the internet. Veteran internet geeks like myself don’t find this to be particularly revolutionary. This is the essence of IMAP, at the very least, a protocol whose RFC is over 2 decades old. Cloud computing seems to be about extending the same paradigm to lots of different kinds of work, presumably with office-type documents (word processing documents, spreadsheets, and databases) leading the pack.

How is this all supposed to work? Intuitively, I wonder about security and data ownership issues. I don’t think we’re supposed to ask such questions. Every description I can find of cloud computing does a lot of hand-waving and asserts that everything will “just work”.

I had one computer science professor in college lecture that said “a bad idea is still a bad idea no matter how much money you throw at it.” I don’t yet know if this is a bad idea. But it’s definitely a big buzzword. I have been reading that Ubuntu is launching some kind of cloud service and a distribution of Linux that is integrated with said service. One part of this (or perhaps both parts) is called “Cloud One”.

My personal version of the computing cloud is a microscopic yet ridiculously high density USB flash drive, something I have only recently discovered and grown accustomed to (I told you that I’m often behind the technological curve). I tend to bring it with me nearly everywhere now. When I analyze it in the context of the cloud, I worry about the security and redundancy matters. I.e., I should probably have an easy, periodic backup process in place at home. Also, I should use some kind of encrypted filesystem for good measure (EncFS over FUSE should fit the bill and operate over whatever filesystem is in place).

Benjamin Otte has recently posted the most cogent use case of (what might be) cloud computing. One aspect of his vision is that his desktop settings are the same no matter which computer he logs into. I can’t deny that that would be nice. I have long forgotten what it’s like to customize and personalize my desktop environment. This is because I work on so many different computers and virtualized sessions that it would simply be too much trouble to make the changes everywhere. I don’t see how my flash stick solution would be able to help in such a situation (though that’s not outside the realm of possibility). But I’m also not convinced that the cloud approach is the ideal solution either.

Then again, it’s not really up to me. I suspect it will be largely up to the marketers.

Followup:

• I actually found a good reason to acquiesce to the cloud computing fad soon after this post.

I did a bunch with compilers in FATE tonight:

• I formally inducted x86_32 and x86_64 configurations of LLVM for Linux into the FATE farm. I’ve heard that compiler is going to rescue us all someday. For the time being, it is exhibiting some problems with the FFmpeg source code, particularly on 32-bit.
• I upgraded the gcc used for compiling the Mac OS X versions to gcc 4.0.1 build 5493, packaged with Xcode 3.1.3 which is the latest version per my understanding. I think this is the first time I have bothered to upgrade Xcode since the first time I installed it. Everything still runs smoothly there, both on 32- and 64-bit.
• I updated the gcc-svn snapshots across x86_32, x86_64, and PowerPC, all on Linux. All 3 configurations are compiling now. That’s the good news. Regrettably, the PowerPC build is doing even worse now (i.e., failing more tests) than the recently released gcc 4.4.0.

Everyone would like to see FFmpeg performance graphs based on data collected from FATE. One day, I got down to analyzing the millisecond runtime data for one configuration regarding one of the longer tests in the suite. The numbers were all over the map and directly graphing them would prove confusing and meaningless.

Then I had an idea which draws on my limited experience with digital signal processing as it pertains to multimedia. What about plotting points that represent the average of point n along with, say, points (n-15)..(n+15)? Then I refined the idea a bit– how about multiplying each point by a factor such that point n gets the most consideration while points further away from n receive progressively less consideration?

And then I quickly covered up all evidence of the brainstorm for fear of catching a beatdown from a tough gang of statisticians for devising the most idiotic idea in the history of statistics. Imagine my surprise when I was recently reading up on a completely different topic and found the exact same techniques described in practical application. It turns out they even have formal names: Moving averages, in which various forms of weighted moving averages comprise a sub-category.

This is not the first time I have re-invented something that I would later learn is called a “wheel” (the first time I can recall was when I independently figured out a bubble sort algorithm). I’m sure a spreadsheet program can be coerced to massage the data in this manner, but I decided to go the Python route; I have to use Python to effectively extract the data from MySQL into a usable form anyway.

I created a Python script that takes a list of FATE configuration IDs and a test spec number. For each configuration ID, gather the history of millisecond run times for the specified test. Run a weighted moving average using the current run time and the 9 run times prior. The current run time is multiplied by 10, (n-1) is multiplied by 9, down through (n-9) which is multiplied by 1. Divide the average by 55 (10+9+…+1). For a more elegant mathematical explanation, see the Wikipedia entry. This script allows me to dump all the performance data for a series of configurations like, for example, all of the PowerPC configurations that run on the same machine.

Then, we turn the data over to OpenOffice Calc for graphing… <sigh…>

Dear OpenOffice.org: I hate you so much. Sometimes you elect to plot data on a graph in a sane range and sometimes you opt to begin from 0. The latter is shown above, where the former would have been much more appropriate. As it stands, any useful data to be gathered from the visualizing the trend of the weighted moving averages is lost. And don’t even get me started (again) on your fragility. Or your atrocious software update mechanism.

Anyway, the above graph shows performance over time for the idroq-video-encode test run on various PowerPC configurations. The graph actually does reveal at least one oddity– the orange pulse wave that represents gcc 4.1.2′s performance over time. That might be worth looking into, particularly since it’s on the high part of the wave right now.

Below is the same thing, only with data collected from running h264-conformance-mv1_brcm_d which is the most computationally intensive H.264 conformance sample in the FATE suite. And it looks like I mislabeled ‘gcc 4.3.3′ as ‘gcc 4.3.2′ in both graphs. Oh well; not going through the pain of regenerating those graphs with OpenOffice now.

What to do about performance graphs going forward? I really don’t think it would be worthwhile to be able to pull graphs from the database relating to performance data over time for arbitrary tests. Most of the tests are simply too short to yield any useful trends. This would be better suited to the idea of running certain tasks less frequently. Various configurations should be made to run longevity tests on full movies encoded in various formats, once every day or 2. CPU runtime performance data (in contrast to wall clock time data) should be collected on those runs and graphed for analysis.

BTW, if anyone knows of better desktop graphing apps, do let me know. Any system, I guess. As long as it can read a CSV file and create a competent graph in a reasonable amount of time on a 2 GHz CPU, I should be able to tolerate it.

I decided to reverse the order of the machines on the main FATE page. That makes the Linux and Mac OS X machines float to the top. Sorry, BSD and Solaris people, but the Linux stuff just take precedence.

And speaking of Solaris, you will notice that we have a new configuration: Solaris 10 on Sparc, compiling with gcc, with more compiler configurations hopefully to come. Thanks to JeffD for contributing these results.

Back on the topic of the front page: Of course, I have every desire to update the entire web experience. But I’m still woefully inept at modern web development. Maybe I’m being too hard on myself. Perhaps it’s better to claim that I have so many higher priority problems to solve for FATE. I have an entire other rant in process for my experience with trying to understand modern web programming.

Look, I have all this raw data in a neat format. What is a good, quick, cross-browser method to display it in a friendly manner so that it can be easily sorted by various criteria. In different GUI APIs, I’m pretty sure that I would coerce the data into some kind of DataGrid object. There’s nothing quite like that in plain HTML. Javascript, perhaps? What’s out there? Where do I even start looking?

Some anonymous hacker recently made a name for himself (wait, can you make a name for yourself anonymously?) by ranting against the difficulty of working with certain Adobe file formats. It got me wondering if we could draw more attention to the FFmpeg program by littering the code with rants against the file formats we’re trying to re-implement. I’d like to think we’re above that, if only because the average FFmpeg hacker intuitively understands that no one ever meant for us to be able to re-implement these formats, at least not the proprietary formats.

Ironically, I think you’ll hear the most complaints from the crew where free, open formats are concerned.

You can look at a seemingly bizarre format and generally experience 1 of 2 reactions:

1. What kind of moron thought of this format?! What were they thinking?!
2. What did the creator of this format know that I don’t know? What were the original design goals and what problems were they trying to solve.

Over the years, I’ve trained myself to have reaction #2. I’m not saying I’m superior; on the contrary, the philosophy leads me down the wrong path sometimes when it turns out that the format’s originator honestly didn’t know what they were doing. In that case, I end up giving them too much credit.

Along these same lines, Joel Spolsky’s take is absolutely fascinating: He describes how the Microsoft Office formats evolved to their present complexity — not out of spite for third party programmers, but to meet the needs of the applications’ features.

Actually, an impromptu and unscientific audit of the FFmpeg code (grep’ing for certain keywords) does seem to indicate a high level of animosity towards Microsoft.

Suddenly, I feel revitalized regarding the MultimediaWiki and its charter. Someday, someone somewhere is going to want to know about that UMV format on Orpheo’s Curse.

At the outset of this FATE journey, I pondered how frequently I ought to update gcc from SVN and put new experimental gcc versions into service. At that point, I had some logistical difficulties in upgrading compilers due to my computer setup which made it a serious chore. But it’s much easier to do now– at least for x86_32 and x86_64, I know how to build one compiler that can build both binaries. Further, the C compiler only takes about 45 minutes to compile on my 2.13 GHz Core 2 Duo, leveraging both cores, and barring any other CPU activity.

So, if you know me, you should know that right about now I’m thinking… automated script! Here’s the pitch:

• Write a new Python script that runs continuously which performs the following steps:
• ‘svn update’ of my local copy of gcc-svn
• If the SVN number is higher than the latest build, automatically build a new version and install it in its own directory
• Wait 24 hours and repeat

This will run on my main FATE machine, so run the script at a low priority so it doesn’t take time away from the more important build/test operations.

So that seems straightforward enough, especially drawing on the experience I have with FATE already (this is basically a simpler version of the main FATE script). For bonus points, the script should also put the freshest compiler into service automatically so I don’t have to be bothered with the tedious, error-prone process. This will be a bit trickier, but it should be possible:

• Contact the primary FATE MySQL database @ fate.multimedia.cx and update the relevant records in the configuration table.
• Signal the FATE script to start using the new compiler versions. In the present arrangement, while I have 2 scripts in order to leverage 2 CPU cores, 1 of the scripts is in charge of the 2 gcc-svn configuration for x86_32 and x86_64. The compiler path is specified in a Python configuration file. I may have to modify FATE a little bit so that the script checks some independent file for the compiler location. Then, this new script can update that location.

There is also the matter of storing so many old gcc-svn compiler versions. I’ll likely clean that up manually at various intervals but its not terribly pressing; the main FATE build/test machine inherited a 400 GB hard drive when it went into service (which, you’ll be pleased to hear, is partially used in performing backup duty for the various multimedia.cx domains).