Regarding Apple’s iFrame Spec

There is undoubtedly a lot of pain around trying to edit h.264: there’s a lot of slowness, and often crashiness across the board of video editors. The way most people are going around the problem is either by using proxy files, or Cineform or other respectable intermediate formats (e.g. ProRES, Avid DNxHD).

Apple thinks that it can outsmart us all.

They recently released their new spec for an iFrame based h.264 format that’s locked to 540p. The reason for doing that was just so iMovie can deal with these impossible-to-edit h.264 formats without re-encoding into AIC (another bullshit format they invented back in the day). So far, two Sanyo cameras support the iFrame format.

The problem with the i-Frame idea is that it’s locked to 540p. There you are, buying a $400 1080p digirecorder, and Apple suggests you record in 540p, which is 1/4th of the camera’s native 1080p resolution! In other words, you just threw away in the garbage $300 just so Apple can say that its iMovie is fast to edit. Well, here’s a finger to you Apple.

What Apple should have done was simply to implement a proxy system. Not like their demanding proxy ProRES system like they have on FCP, but a simpler one. One that employs mpeg2 at either 640×360 or 854×480 at ~2 mbps. Mpeg2 is a piece of cake to decode, especially at 2 mbps low-res, they would be very small files considering the size of the originals, and as importantly, it’s really fast to encode. Encoding a 1080p h.264 stream to VGA mpeg2 will be ready in a flash on a modern machine!

And of course, the proxy system should be transparent to the iMovie user. Although, the user should have the preference available to decide if he/she wants the proxies in the first place, and switch between the two modes easily (in case he/she wants to color grade at the end of the editing process). And by default, the exporting will always be done using the high res native versions of the files.

In my opinion, this would be a very acceptable solution. Very little “waiting” for the user while encoding the proxies, very easy editing (much easier than the current iFrame format), flexibility, and exporting using the native files. Instead, what we get is one more of these Apple “innovations” that never actually solve the problem, but create new ones. While Apple has realized miracles in their iPod and iPhone divisions, the iMovie part of things always seemed like a disaster to me. It’s like they are putting their lower grade engineers to work on these projects.

Another way to battle the problem is to take their head out of their ass and implement full GPU acceleration (via Purevideo2 and similar technologies) for h.264 decoding. If a team of 3 freelance programmers are able to create CoreAVC, the fastest h.264 decoder in the world (5% CPU utilization on a 1080/30p video), then Apple (and Sony, and Adobe) should be able to do that too. Crippling people’s HD experience is never an option though.

Death to the iFrame.

7 Comments »

William Eggington wrote on October 16th, 2009 at 4:32 PM PST:

Apple has received a lot of fingers from me over the years. LOL


JrezIN wrote on October 17th, 2009 at 4:36 AM PST:

I do suspect that this iFrame format has more to do with the web, HTML5 and iPhone than Apple thinking about HD res or something else… wait and see.


Ray Cote wrote on October 17th, 2009 at 9:59 AM PST:

You are so wrong. Here is why!

This is all about instant editing on mobile devices. Which will account for the vast majority of non professional video moving forward. It will also scale up to 1080 and down to iPhone resolutions in a quick and clean way.


William Eggington wrote on October 17th, 2009 at 10:45 AM PST:

540p scales up to 1080p? I really don’t think so Ray.


Atilla wrote on October 17th, 2009 at 10:58 AM PST:

Even in the context of higher resolutions available on desktop systems, your condemnation is premature. So, as long as we’re considering what amounts to today as vaporware on the cusp, Long Live iFrame!

Mobile GPU-friendly power & display requirements, and flash/SSD-friendlier file sizes tell the story. iFrame’s about fleshing out an ecosystem (think open standards, TuneKit-assembled multimedia), not obviating other formats.


This is the admin speaking...
Eugenia wrote on October 17th, 2009 at 11:27 AM PST:

Ray, Atilla, you are both wrong. This format has nothing to do with mobile stuff, or in-camera editing. It’s just a POOR attempt from Apple to fix the inability of iMovie (like any other video editor) to edit 1080p h.264 in real time from digirecorders (AVCHD is faster to edit because it has b-frames). As I explained in the article, Apple should have worked either with proxies, or with GPU accel., not this crippled format.


Rabid wrote on October 17th, 2009 at 12:31 PM PST:

[Comment removed, since you’re a jackass and an Apple apologist]


Comments are closed as this blog post is now archived.

Lines, paragraphs break automatically. HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

The URI to TrackBack this blog entry is this. And here is the RSS 2.0 for comments on this post.