Author Archives: Multimedia Mike

The Standard, Like It Or Not

I have been studying multimedia technology since 2000. It has been a pretty chaotic technological landscape. People who wanted to publish video on the web wondered what format to use (and occasionally sought my advice). Various fiefdoms arose around Microsoft, Apple, and Real, all hoping to claim the mantle of the standard web video format. Somewhere along the line, Macromedia “accidentally” established a standard web video format via the Flash Player (now Adobe’s).

A few years ago, Adobe (my employer, BTW) upgraded the video support in Flash Player to use the same video format that happened to sit at the top of QuickTime’s codec heap: QT-MP4/H.264/AAC. A few days ago, Microsoft announced the beta of Silverlight 3, which contains support for the same formats. After absorbing that information, it took a few days for the next thought to coalesce in my mind:

We have a standard multimedia format.

All the big players support the same multimedia stack (I think even Real Player supports the same stack). I know that’s dismaying to certain elements of the free software community who insist that Xiph’s multimedia stack is the “standard” (really! there are blessed RFCs to back it up and everything); you may not like it, but that’s the way it is:

  • QT-MP4 is the standard container format, not Ogg
  • H.264 is the standard video codec, not Theora (or dirac)
  • AAC (and also MP3, for historical purposes) is the standard audio codec, not Vorbis

Sure, you may, in principal, have to send a dollar or 2 over to the Patent Illuminati (though highly unlikely). But it’s either that, or, you know, not have a standard video format. (And remember, the HTML5 video tag is not coming to save you.)

At least the free software enthusiast can take comfort in knowing that open source (L/GPL) efforts such as FFmpeg and x264 aim to create the very best tools that anyone can possibly use to create these formats.

Addendum: Now that I think about it, I don’t necessarily know if Silverlight 3 will transport H.264 and AAC inside of a QT-MP4 container or somehow pack it into an ASF file. That would be interesting to find out, though I have read (possibly uninformed) blog chatter excited about being able to stream the same file through Flash and Silverlight.

GSoC 2009 is Afoot

FFmpeg has been accepted as a mentoring organization in the Google Summer of Code 2009 program. This is the program’s 5th year and FFmpeg’s 4th year in the program. Thanks as always to the big ‘G’.

To refresh, the GSoC pays students $4500 for a summer’s worth of work on qualified open source projects. FFmpeg is one of those projects. FFmpeg team members mentor various multimedia-related projects. Our current project proposals are listed in the wiki. And, as with the previous 2 years, we have some stringent requirements for our students– namely, a student must complete a small FFmpeg task, refining the solution based on critical feedback until it is part of the mainline codebase.

I personally haven’t committed to any mentor possibilities. I wonder if I should propose the Theora encoder again, which didn’t quite pan out last year? The thing is practically written already in my mind.

Archiving Binary Builds

Someone recently asked on the ffmpeg-devel mailing list for nightly binary builds of FFmpeg and its associated libraries to be made available for download. The idea seemed to gain traction on the list so I began thinking of how we can make this a reality. Since FATE clients are already building FFmpeg binaries day and night, it’s not a huge leap to consider extending the infrastructure slightly to include packaging the binaries and sending them to a central server. So let’s talk process:

  • After building binaries as part of FATE, make a compressed bundle (.tar.bz2 for Unix, .zip for Windows) and ship the package right here to multimedia.cx. Hey, I have the space to spare (an alleged 500 GB with the current hosting plan, of which I am currently barely using 6 GB, and nearly half of that is FATE data). I also have FTP account options which should facilitate transfer.
  • The filename would follow the naming convention of “ffmpeg-bin-svn-OS-arch-compiler.ext”. So, for example, the build of SVN 18005 from Linux / x86_32 / gcc 4.2.4 would be: ffmpeg-bin-svn18005-linux-x86_32-gcc-4.2.4.tar.bz2.
  • What should be in the package? The FFmpeg binary programs and the associated libraries, of course. But in what hierarchy? A flat hierarchy doesn’t strike me as a good idea (unzip and potentially trash existing files in your current directory). Instead, package the files in, e.g., ffmpeg-svn18005-linux-x86_32-gcc-4.2.4/.
  • There should be a standard, auto-generated README.txt file in the same directory. Actually, perhaps it should be a simple HTML file since I envision it should contain — in addition to basic information such as its revision and the time it was built — a report of which tests passed and which failed, along with links to each report in the FATE database.
  • Create a web interface that allows users to browse among the latest FFmpeg binary builds. Out of everything presented in this brainstorm, this is the step that actually gives me some pause since I don’t exactly know how I would implement it off the top of my head.

Feedback welcome. Otherwise, these are likely to be the decisions I run with for the first iteration of this plan, when I get around to it (think of this as the public comment period).

Critical Mass of FATE

Okay, so you may have noticed that FATE has 3 more machines/platforms from which it is actively accumulating build/test results: FreeBSD/x86_32, DragonFly BSD/x86_32, and Linux/AVR32 (thanks to Michael K. and Måns for running the FATE script on those platforms). I was wondering when a volunteer would step forth to continuously run FATE on some BSD platform.

But the FATE main page is now unbearably unwieldy. When I first put FATE into service, the entire front page was dynamically generated using some horrifically unoptimized queries. A little over a year ago, I rushed a highly naive caching mechanism into production to address this problem. The way it operated was as follows (you might want to be sitting down for this): From a cron job run every 15 minutes, run a Python script that connects to the database server, performs all the queries for fetching data for the main page, and builds a file called main-page-cache.php which is then transferred to the server where it overwrites the old copy. The main index.php script driving the site simply includes the file. Okay, don’t all go contributing this to The Daily WTF at once. Hey, it has performed rather quickly for the last year or so. But it also explains why I couldn’t modify it very easily to allow arbitrary sorting.

Fun fact: At this point, index.php did not strictly need to connect to the database in order to simply render the main page. However, I quickly learned to do a no-op database connection anyway; without it, the end user’s browser would cache the output of the page. I’m sure there must be better browser cache control mechanisms available.

Until I switched web hosts recently, I had to run the Python script on a local machine and scp the results to the server. This explains why, if there was a power failure at home that outlasted the UPS, the main FATE page wouldn’t get updated until I returned home. That problem is solved now by the fact that the cron job and script run on the same server as FATE. At least, the problem was solved until I had to switch back to my prior web host.

After I deployed the caching system, I wondered about ways I could possibly trigger cache page rebuilds automatically after entering new results. Last autumn, I revised the FATE architecture so that results are received through a PHP script. I started to think that, when a configuration sends results through this script, it could update a new PHP cache data file specific to that configuration. The main script could dynamically include a series of these PHP cache files and sort out the data inside.

Then it dawned on me to store the data in an SQLite database with a single, highly non-normalized table. And just when I was about to go to code on that idea, it occurred to me that, as much as I love SQLite, there’s really no reason I can’t put the cache table straight into the main MySQL FATE database. The big advantages will be: No more up-to-15-minute delay before new results show up on main page; and more flexible sorting of the results on the main page.

So the plan goes like this:

  1. Create a non-normalized cache table in the main FATE database that includes config ID, machine ID. OS, architecture, compiler string, latest build ID, timestamp build ID was logged, SVN revision it corresponds to, status of the build, number of tests total, number of tests passed.
  2. Create a script that performs an initial population of this table based on the configurations marked active and their latest build records in the database. It will be necessary to re-run this script where there are new configurations added to the database, or when configuration data is updated (most often happens when I compile a new gcc from SVN).
  3. Modify the data receiver PHP script so that it properly updates the correct row in the table.
  4. Go crazy with the main FATE page. Sorting the data by different fields is as straightforward as an ORDER BY clause in the SELECT statement.

The main page should also send a cookie so that the page “remembers” the user’s last (and presumably preferred) sorting order. That assumes that any of FATE’s users actually browse the web with cookies enabled (doesn’t strike me as likely).

Writing out these ideas is useful for motivating further brainstorms. I just realized that I may as well create a simple method for accessing the latest FATE data via HTTP, perhaps output in a CSV format (no XML, thanks). Perhaps others can think of creative ways to interpret the data and act on it. E.g., maybe someone else can figure out creative ways of sending email and IRC notifications before I can get time to solve those problems.