F4V is Retarded

Why F4V is the wrong decision:

• Destroys one of the great promises of MPEG4-AVC / h.264–interoperability.
• No single file deployment (closely tied to interoperability). I certainly imagine a world where a single piece of media can be posted on the web, downloaded and played back through Flash Player, iPhone / iPod, QuickTime, Apple TV, etc. Gone should be the days of providing different files for different browsers, plugins or mobile devices.
• Effectively reduces the usefulness the existing MPEG4-AVC / h.264 ecosystem. The MPEG4 spec urges .mp4 be used as the file extension and many vendors just refuse to work with something that has a different file extension.
• You lose out on much of the existing intelligent rss enclosure handling. Blogging platforms and plugins will recognize the .mp4 extension and auto-generate enclosures (very useful for delivering to feed readers and mobile devices).
• F4V just muddles the codec picture even more. Take a look at any of the encoder dialogs in CS4 and you’ll see a confusing slew of options (flv, f4v, h.264, h.264 blu-ray, etc.). Hell, I even heard an instructor in one of the MAX hands on sessions, urge students to steer clear of h.264 encodings since that was just HD / blu-ray stuff. He actually was pushing flv (pretty bizarre for an AfterEffects class).

I’m not trying to be a jerk, there are definite reasons Adobe may have chosen to use F4V:

• Apple did it (M4V). Yep, Apple screwed the pooch as well.
• It’s easy to associate file extensions with default application handlers (i.e. AMP is the default media player for *.flv and *.f4v files).
• Allows for a unique mime-type (Flash Player gets associated with a specific file type on servers).
• OS file choosers allow filtering by extension.
• F4V clearly establishes a file as compatible with the parts of the MPEG4 spec supported by Flash Player. This has the obvious advantage of visual associations / assumptions and might assist descriptions in documentation and marketing.

I guess I feel like there should be some sort of primary directive: “thou shalt not damage interoperability.” Any time you’re thinking of messing with the spec it should be examined through this lens. As valid as some of the reasoning for using F4V is, it fails, IMHO, when compared to the primary directive.

JavaFX Video – Another Me Too Campaign in the Old, New Media War

I spent a little time checking out (high level) JavaFX multimedia capabilities. You can actually boil Sun’s entire JavaFX campaign down to a single 1 second sound bite (watch video excerpt below – full video found here).

According to Sun, they have the full support of any multimedia codecs installed on the native system as well as an on2 codec embedded within the runtime (see video quote below to hear their words for yourself).

Native codec support is sort of a mixed bag of control vs utility. JavaFX wants to do everything for every system even if that means you are effectively writing system specific code and delivering uneven experiences. If you manage to actually get the JavaFX runtime installed (no mean feat) you’ll be confronted by a wonderful security dialog which seems to ignore attempts to always trust the cert.

Once you’ve run the gauntlet of JavaFX impediments, you can actually watch some “native” (h.264 .mov files) overview videos playing inside JavaFX. The problem is that the rendering of these videos is far from native–any scrolling or resizing of the browser causes the video to stop rendering (a white rectangle is painted during these movements). I’m also surprised to see Sun using MPEG4-AVC / h.264, but not using aac audio. If you’ve got native codec support why use a crappy audio codec in your videos? The video below illustrates the rendering and audio issues (3 asides: 1) I’m bound and determined to ruin AfterEffects cartoon effect–look for me to overuse it and misapply it, 2) watch in fullscreen mode for 1:1 clarity, and 3) listen half way through to hear one of my kittens snoring).

If you ever wanted evidence of how important video is today, you need look no further than than the gigantic amounts of money Adobe, Microsoft and Sun are sinking into media centric runtimes. Like Silverlight 1.0, the initial JavaFX offering is a half-baked “me too” stab at capturing some video glory. Sure media has been a glaring hole for Java and I can appreciate how all the development platforms in the universe need to provide easier development and enable richer experiences, but so far I’ve been disappointed by the same ol’, same ol’ offerings from Microsoft and Sun. I’m sorry, but “hey look at the same stuff on my platform” isn’t innovative or visionary. As we watch Detroit’s “big three” burn out, I wonder if there aren’t lessons to be learned in our own industry as the nascent “media three” rise (maybe it should be w3m–web three media).

The XMP Revolution is Here

I was testing some MPEG4-AVC playback code the other day and ran into a Flash Player runtime exception I hadn’t ever seen before:

Hmph. An onXMPData callback–that piqued my interest. I’ve long been a fan of metadata and XMP in particular (it takes a special type of nerd to have the meta love), so when I saw this error the wheels began to turn immediately. I had been testing a lot of video files lately, but this particular piece of content was created with After Effects CS4. This made me think that the long and slow roll out of XMP into the Adobe suite was finally here and I wanted to know what exactly they were doing.

(more…)

Yes, the h.264 Specification is Freely Available

I’ve done quite a bit of research on MPEG4-AVC / h.264 over the last year, but one thing that always seemed to bug me was that I couldn’t seem to find a freely available version of the spec anywhere. I’d hoped to find something on the ISO site, and I did, but it they’re charging for the pdf. Now in my book paying cash to read a spec stinks, seems contrary to the purpose of a standard and, well, just isn’t something I’m going to do, so I just slid by soaking up crumbs where I could find them.

To be fair there’s little chance I’ll actually understand the spec, so crumbs are probably appropriate. Reading level aside, I thought I was SOL until stumbling onto a link to the spec at the ITU-T site. For those who aren’t aware the MPEG4-AVC (ISO) / h.264 (ITU-T) spec was jointly developed by the ITU-T and ISO/IEC Moving Picture Experts Group. The result is the exact same spec with different names (MPEG4 Part 10 / AVC vs. h.264) and, it turns out, completely different policies on whether to charge for the spec.

Now that we’ve cleared that up, I can get back to blankly staring at the spec until sleep or ADD overwhelms me.