So many fun programming languages out there, and more emerging all the time. But who has time to learn them all? I certainly don’t, but I still want to learn. One issue I have is that I don’t learn that well by reading through a language reference or a tutorial. I learn best by doing, and when it comes to learning a new language, I learn best when I have a specific task I am trying to accomplish. To that end, I was thinking that it would nice to have a list of essential, yet simple, programming exercises, preferably ones that are suited for higher level languages. These would give me concrete goals to research whilst attempting to learn a new language. Further, I would build up a small repository of sample programs to which I could refer later. When I need to write something in Perl, my chief method of refreshing my skill is to look back on similar code I wrote as many as 10 years ago.

I did a cursory Google search for something along these lines, but came up empty-handed. It may be necessary to start assembling a list of my own. This would include items like:

• Reading a file, line by line, and processing each line through a regular expression; or perhaps a more complicated, less sed-style textual processing application
• Opening a socket to a web server and fetching a web page; perhaps screen-scrape something useful off of the fetched data
• Write a simple web server (and consider carefully the security implications of what you produce)
• If the language has a graphics API (e.g., through something like gd or SDL), create a canvas, draw some dots, lines, shapes, load a font and write some text, load an image and blt it; decode a video in real-time using FFmpeg
• If the language has an API for accessing your favorite database, use it to connect to the db server, SELECT, INSERT, UPDATE, DELETE, etc.; understand how the API can organize query data into the language’s native data structures (e.g., Perl’s DBI can fetch the results into a hash array which is extremely useful and intuitive)

These are just a few ideas off the top of my head. Another important aspect would be specific exercises targeted at understanding the language’s native data structures since those tend to be a key selling point of many very high level languages.

The second day of WordCamp 2007 was far more technical than the first day, featuring presentations about things like optimization strategies WordPress to survive a possible Digg or similar network storm. Performance enhancements are always interesting from a technical perspective, but I rarely have motivation to set them up for the blogs hosted on this site. (For those in attendance, when the speaker queried why some of us weren’t using plugins such as wp-cache, I was the guy who yelled out, “Too lazy!”)

Try this talk title: Designing Massively Multiplayer Social Systems, delivered by one Rashmi Sinha. To be honest, a lot of it was very fluffy stuff about building online communities and well-known problems therein (think Digg mobs) and how unfair it is that the internet is quintessentially meritocratic vs. democratic. However, I did take away one very key item from her presentation: SlideShare– think YouTube, but for PowerPoint presentations. I had never heard of it before but the knowledge comes at a useful time since I still need to get that LinuxTag talk online. Further, it may be valuable to post my other presentations as well.

However, a few concerns occurred to me right away, chief among them is the fact that PowerPoint presentations do not do a terrific job of presenting things by themselves; they most often serve as visual aids. Indeed, if a set of presentation slides actually deliver a cohesive presentation without human intervention, they were not created properly. I wondered how this context-free principle would work on SlideShare, particularly for my recent FFmpeg presentation which was almost entirely pictures. Fortunately, it appears that SlideShare is smart enough to extract the embedded notes that presentation software allows you to make.

My very first practical concern is whether SlideShare only handles PowerPoint presentations. It turns out that it can also handle OpenOffice Impress presentation files (and PDF files). I uploaded my FFmpeg: Past, Present, and Future slides to the service to test it out. It mostly worked, except that I used a few special fonts which are not embedded in the file. I need to see if there’s a way to correct that. Plus, this was the first time that I saw the feature that SlideShare extracts and lists your notes– I need to expand those and re-upload the presentation.

Then again, it seems reasonable that OpenOffice can probably export a series of linked HTML pages with the properly rendered slide and all the accompanying notes. Maybe I’ll go with both routes, in deference to those on fringe computing platforms that don’t have a viable Flash solution.

I had so much fun at last year’s WordCamp that I decided to register for this year’s festivities, which have been expanded to cover 2 days. I’m always on the lookout for ways to improve this blog and the communication it provides, as well new multimedia technology angles.

The first talk of the day — PodCasting — was highly relevant to multimedia, in fact; it was about PodPress, a WordPress plugin that makes PodCasting more ergonomic. The author talked about how much complexity the PodPress plugin currently embodied, which actually confused me a little. To my thinking, the plugin just processes a little bit of a multimedia file in order to find its metadata and knows how to spit out that metadata along with a MIME type via PHP. But I oversimplify. Actually, the demo he gave presented the plugin in its slickness, going so far as to show you, the admin, how your PodCast will actually appear to the users of various services, most prominently iTunes, but also several other PodCasting client programs. Plus, the plugin deals with an impressive array of multimedia files and probably handles lots of idiosyncrasies that arise in various file types.

Next up was a debate regarding Blogging vs. Journalism featuring John C. Dvorak and Om Malik. It was an interesting discussion though I personally didn’t take very much away from it since I don’t care about the blog vs. serious news source distinction for the purpose of this research journal-style blog. One take-away point: Blogs and news sites have very distinct styles and stigmas attached– so, do you want your site to look like a blog or a news site?

It was during this talk that I started thinking… there was a 4.2 earthquake here early yesterday morning. Though it was scarcely notable in the grand scheme of things, if that earthquake had waited about 30 hours to strike — during a bloggers conference — it could have had unprecedented live internet coverage.

After lunch came a wonderfully animated speaker delivering her talk about Kicking Ass Content Connections. She spoke of how last year’s fad was tagging while this year’s fad is relationship building — and proceeded to extol the virtues of the latter. I thought it ironic that she would introduce the topic in that manner as the comparison immediately cast it in a negative light. However, this relationship building notion is something I ponder from time to time as I periodically seek out other blogs that deal with similar interests as this one. I generally find that the few blogs that pertain to the subjects at hand are all hosted right here @ multimedia.cx. But I keep searching, disbelieving that we could be alone in this vast universe called the internet. Another point she made was that even some of the most mundane blogs that record an individual’s tedious day to day activities may, at some time in the distant future, provide archaeologists a clue of what life was like in this day and age. During this discourse, I was reminded of this Onion article: Recently Unearthed E-Mail Reveals What Life Was Like In 1995.

Still, I must say that I admire her for the yeoman’s work she does in her primary role of documenting WordPress.

Next was Blog Monetization, a topic that I still stubbornly refuse to care about. However, a key takeaway point from the speaker was: would you read your blog if it wasn’t your blog? I.e., if someone else wrote the same content as you, would you find it interesting?

Contributing to WordPress was a tag team effort– As for the first speaker, I thought Tobey McGuire’s Peter Parker was delivering a convocation. But I have to give him credit because his pre-written and obviously oft-rehearsed speech worked surprisingly well. This led into the second speaker whose talk sounded incredibly familiar to me– because it’s basically the same speech I gave at LinuxTag last month. That’s because both presentations dealt broadly with how a prospective contributor can get up and running with helping on an open source development effort, so there is much room for similarity. (This also reminds me that I still need to post my presentation from LT’07. Really, I plan to do this, but I would like to properly annotate my slides for the web since the slides themselves provide zero context.)

The presenter for Designing the Obvious needs proper credit for his courage to dump his entire stock presentation the day of the conference and tailor a brand new, virtually slide-less presentation for this specific crowd. I jotted down a lot of ideas for how to improve my blogs based on the ensuing discussions, just as he warned would happen.

The last talk of today was delivered by a big Google guy who discussed benevolent search engine optimization (SEO) strategies. Quite interesting, though common sense stuff, and I didn’t take away much personally. I operate on a slightly different level for this blog in particular– my SEO strategy is to simply write about stuff that no one else on the entire internet writes about. However, this often comes with the caveat that no one else on the entire internet cares about the stuff.

I have amassed quite a collection of Sega CD titles over my years of multimedia hacking. Since it was an early CD-based console, I reasoned that at least some of the games would contain full motion video (FMV). In fact, essentially all Sega CD games fall into one of the following 2 categories:

1. Standard 16-bit Sega Genesis-type games that were enhanced by a Red Book CD audio soundtrack
2. Games that were driven entirely by very low-quality FMV

Screenshot of Mad Dog McCree for the Sega CD, an FMV-driven FPS

Many Sega CD games, particularly those published by Sega itself, contain many large files with the extension .sga. I have never made much headway on understanding any of these files, save for the fact that many of them use sign/magnitude 8-bit PCM audio. As for the video codec, “Cinepak” or “Cinepak for Sega” is often thrown around. I can certify that it is not the stock Cinepak data commonly seen in the early FMV era. Though perhaps the Sega CD console was the proving ground for later Cinepak technologies. A lot of Sega CD FAQs around the internet were apparently plagiarized from each other, which must have originally been plagiarized from Sega marketing material because they all shallowly list one of the system’s graphical capabilities as “Advanced compression scheme.”

Read the rest of this entry »

As of this writing, there are 25 lossless audio coding (LACs) algorithms cataloged in the MultimediaWiki. Apparently, that’s not enough because an audiophile friend electrical engineer with a solid DSP background (amended per the audiophile’s suggestion) just communicated the news that he is working on a new algorithm.

In particular, he was seeking advice about how to make the codec container-friendly. A pet peeve toward many available LACs is that their designers have historically insisted upon creating custom container formats for storing the compressed data.

Aside: The uninitiated might be wondering why this custom container characteristic irks us multimedia veterans so. Maybe it’s just best to solve one problem at a time: if you want to create a new codec format, work on that. Don’t bother creating a container to store it at the same time. That’s a different problem domain entirely. If you tackle the container problem, you’re likely to make a bunch of common rookie mistakes that will only earn the scorn of open source multimedia hackers who would otherwise like to support your format.

My simple advice for him is to design the codec so that each compressed chunk decompresses to a constant number of samples for a given file. Per my recollection, this is a problem with Vorbis that causes difficulty when embedding it inside of general purpose container formats– a given file can have 2 decoded chunk sizes, e.g., 512 and 8192 samples (I’m sure someone will correct me if I have that fact mixed up). Also, try not to have “too much” out-of-band initialization data, a.k.a. “extradata”. How much is too much? I’m not sure, but I know that there are some limitations somewhere. Again, this is a problem with those saviors of open source multimedia, Vorbis audio and Theora video. Both codecs use the container extradata section to transmit all the entropy models and data tables because the codec designers were unwilling to make hard decisions in the design phase. (Okay, maybe it would be more polite to state that Vorbis and Theora are transparent and democratic in their approach to entropy and quantization models by allowing the user the freedom to choose the most suitable model.)

No OOB setup extradata is ideal, of course. What about the most basic parameters such as sample rate, sample resolution, channel count, decoded block size? Any half-decent general-purpose container format has all that data and more encoded in a standard audio header. This includes AVI, ASF, QuickTime, WAV, and AIFF, at the very least. Perceptual audio codecs like Windows Media Audio and QDesign Music Codec get by with just a few bytes of extradata.

Takis has been a busy FFmpeg hacker: He recently established an experimental server to automatically build the current source-controlled copy of FFmpeg and perform some rudimentary tests with the output. This is some great initiative on his part.

(Oh, and look what else Takis has been up to while no one is looking: a graph of FFmpeg code change over time.)

I have wanted to build an automated building and testing infrastructure for FFmpeg for a long time now. I got my first concept up and running late last November. I just realized that I never blogged about it although I did announce it on the ffmpeg-devel mailing list. The concept lives at http://builds.multimedia.cx/, though be advised that the script that updates it went offline in late December.

Predictably, people seemed to think the autobuild system was a good idea but that my implementation needed a lot of work. And they were right. The reason that I never blogged about it is likely that I figured I was about to deploy a better concept very soon.

It is now July and I have had months to brainstorm ideas for an improved autobuild and test infrastructure. Unfortunately, as can often happen with revision 2 of an unproven idea, I fear my concept has devolved into an exercise in architecture astronomy.

Read Joel Spolsky’s excellent essay, “Don’t Let Architecture Astronauts Scare You”. It’s about people who heavily theorize in the abstract but rarely accomplish anything useful. Personally, I consider it a clear indicator of architecture astronomy when a program’s fundamental paradigm revolves around the idea that, “Everything is an object (or module)!” It is my opinion that declaring everything in your architecture to be an object is the abstraction endgame (to be more specific, everything is a swappable, user-configurable module, even the central engine of the program that is supposed to coordinate everything between other modules).

I’ll explain the evolution of my autobuild idea: It started simply enough with a script that iterated through a bunch of compiler versions and ran the configure/make commands to build each. It logged stdout and stderr separately and logged general information about success/failure, SVN version, etc. into a rudimentary database table that could be simply queried with a PHP script.

I soon realized that this is wholly inadequate to the overall goals I wished to accomplish in this endeavor (building and testing on many platforms). Security is a major issue, which I blogged about before, and which I solved in the first iteration using the most paranoid policies of chroot’ing the configure/make steps and prohibiting network access during the process. Another problem is the eventuality of infinite loop bugs. Any build or test step could conceivably encounter such a condition.

This realization led me to redesign the autobuild/test system as a series of individual executable steps, all stored in a database, of which the primary script has no hardcoded knowledge. And this is where the “Everything is a module” philosophy comes into play. Unfortunately, the further I plot this out on paper, the harder it becomes because the execution module concept is too generic; it’s hard to do certain specific things. I realize I need to back off a bit on the abstraction.