Yearly Archives: 2008

Call For SWF and FLV Spec Feedback

At work, I have been tasked with updating the Flash Player’s SWF and FLV specs for Flash Player 10. If you have an interest the documentation of multimedia formats, give the specs a read and email me with suggestions for how the specs could be more clear (and correct). I wanted to send out this solicitation during this last round of updates but the docs still had some pesky licensing terms that scared off some folks. Those ominous licensing terms were removed as part of the Open Screen Project. Here are the current links:

I thought this call would be more appropriate for my personal, technical blog with a narrower interest rather than on my more broad corporate blog. Do me a favor, though, and don’t ask that the formal specs describe the intricate details for On2 VP6 or Nelly-Moser.

Granular Regression Tests

I have been studying the FFmpeg regressions test infrastructure ever so carefully so I can decide the best way to convert all of its functionality and test coverage into the FATE system as individual test specs. I have some ideas but I never know when I will have both the time and the motivation to implement them. In the interim, I am retiring the master ‘make test’ full regression test spec. In studying the regression architecture, it’s immediately obvious that ‘make test’ invokes these 3 sub-regression suites, which each have their own test specs now:

That should help until I break down the tests even further. Oh, and I also added a test spec for ‘ffmpeg -h’. Hey, FFmpeg got into a state once where it segfaulted on help. We don’t want to let that go uncaught again.

GSoC Showcase: ALAC

For his FFmpeg Summer of Code project, Jai Menon successfully completed an encoder for the Apple Lossless Audio Codec (ALAC). As you can see, Jai’s encoder is competitive with Apple’s iTunes, as well as dBpoweramp, another program that implements an ALAC encoder:


ALAC compression comparison chart

Thanks to Benjamin Larsson for setting up the graph. We’re rooting for the cyan bar to be the lowest one of each bar quartet. The code is already in the mainline tree.

The 13 samples I used for this test come from the OpenMusic CD and showcase a reasonable diversity of genres. The raw rips are available here.

Poor Amarok?

The MOOBEX project was really the first real exposure I had to the Amarok application. For the uninitiated, Amarok is a rather full-featured KDE-based music playing application and has been around since 2003. Back when I used Linux more exclusively, I stuck to xine directly for all of my media playback needs.

How was my first impression of Amarok? Well… it’s hard to say. The program was different on each distribution that I tried. In OpenSUSE, I was thoroughly frustrated when I first tried to play a file through Amarok, or rather, when I selected an audio file through the file manager and just let the system do its thing. Amarok popped up and just sort of stared at me. Okay, I recognize that I’m throwing a bunch of formats toward Amarok that the distro has administratively determined to be “legally unsafe”. But I should still get some obvious feedback to that effect. Oh, wait, look way down there in the status bar:


OpenSUSE Amarok error message

When I launched an audio file on another KDE-based distro installation (Mandriva), I expected the same behavior from Amarok. To my surprise, the program threw a far more brazen error. Ubuntu has Amarok version 1.4.9.1. Mandriva sports 1.4.8. The Amarok version in Mandriva exhibited the superior UI characteristic. I understand the source of the unsupported codecs. But I wonder about the dialog discrepancy. I am not sure if this dialog behavior is a version specific thing in Amarok, or a configuration option in Amarok, or an dialog characterstic configurable in the hosting KDE libraries. It’s a minor matter, to be sure, but it still makes me wonder how individual distributions would be able to devalue something like the Adobe Flash Player if it were open source and allowed distros to make “choice” changes to the functionality.

I’m sure that the Amarok developers worked very hard to produce the best music player they could. And it probably hurts to see their fruits of their labor mangled by various distributions to the point of practical worthlessness. I know the feeling based on my work on xine.

But here’s a huge annoyance with Amarok which I suspect is a core behavior: stop should mean STOP! When I did get a file to play and then tried to stop playback, the audio kept right on going long enough to make me think that something was wrong. Eventually, the audio started to gently fade out. This is not reasonable behavior. The expected action for a stop button is an immediate halt.