iMovie update reveals new Apple video format
Like most companies, Apple periodically releases software updates for its applications, fixing minor issues. However, an iMovie update released on Tuesday revealed a brand new video format the company has been developing.
(Credit:
Apple)
Dubbed iFrame, the new video format is based on industry standard technologies like H.264 video and AAC audio. As expected with H.264, iFrame produces much smaller file sizes than traditional video formats, while maintaining its high-quality video. Of course, the smaller file size increases import speed and helps with editing video files.
iMovie 8.0.5 released on Tuesday adds compatibility with camcorders using the iFrame video format. Currently there are two cameras that support iFrame: the Sanyo VPC-HD2000A and the Sanyo VPC-FH1A.
The two cameras were introduced earlier Tuesday and default to shooting video in the new format. iFrame shoots at 960x540. The cameras can also record in high-definition 1080p (1920x1080), as well as high-speed video formats for slow-motion playback, according to Sanyo.
Apple hasn't said how long it has been working on iFrame or if other video camera manufacturers would adopt the format. The company also didn't say when support for the iFrame format would be added to its Final Cut Pro video-editing suite.
The iMovie update can be downloaded from Apple's Web site or from the software update mechanism in Mac OS X.
Jim Dalrymple has followed Apple and the Mac industry for the last 15 years, first as part of MacCentral and then in various positions at Macworld. A guitar player for 20 years, Jim also writes about the professional audio market, examining the best ways to write and record songs on a Macintosh with Logic Pro and Pro Tools. Jim is a member of the CNET Blog Network and is not an employee of CNET. 
"the new video format is based on industry standard technologies like H.264 video and AAC audio"
and that is all this new CoDec is, a wrapper just so apple can lock a new PROPRIETARY format into their devices instead of using open, universal standards.
A little patience is applicable in situations like these.
Off topic, I know.
Back on...I hope iFrame doesn't take as long to render out at H.264 does. Even on a fast machine H.264 renderings drive me crazy.
Well I complain about it a lot. Not that it is proprietary, but because it can be annoying. :)
I too have Click-To-Flash installed and it is real handy. When you really need to see that Flash video all you need to do is click to play it.
Besides, the article even says it's based on "industry standard technologies like H.264 video and AAC audio. "
Quicktime isn't based on h.264, and h.264 isn't based on Quicktime.
"QuickTime 7 features a state-of-the-art video codec called H.264, which delivers stunning quality at remarkably low data rates. Ratified as part of the MPEG-4 standard (MPEG-4 Part 10), this ultra-efficient technology gives you excellent results across a broad range of bandwidths, from 3G for mobile devices to iChat AV for video conferencing to HD for broadcast and DVD."
And:
Why is H.264 being included in QuickTime 7?
A few years ago, the International Organization for Standardization selected the QuickTime file format as the basis for MPEG-4. QuickTime in turn embraced open standards and now leads the market in MPEG-4, 3GPP and 3GPP2 content creation and playback. Apple continues to build on this commitment to open standards by incorporating H.264 ? the latest MPEG-4 video codec ? directly into QuickTime.
Can they do it quietly :)
And which one do you think consumers will pick to play back on their HD TV's?
And since iFrame would be processed at much higher speeds (due to lower resolution) but still deliver sufficient quality many consumers would obviously pick it.
Everyone that's calling for 'just one format' underestimates the problem. Features of a video format that make it good for editing make it bad for playback/distribution, and vice versa. In compressed video there are typically several frame types: p frames, which are usually the differences from a previous frame to the current one; b frames ('bidirectional') which refer to previous and future frames; finally i frames, which use intraframe-only compression, not referring to any other frame. These are also sometimes called keyframes because they contain a complete frame with no differencing required.
p frames and b frames allow codecs to make massive savings in data rates and facilitate the use of things like motion estimation to maximise the effective compression ratio. They are used in sequences known as GOPs, or groups of pictures, usually beginning with an iframe followed by a pattern of p and b frames. Now imagine that you are editing a movie and you want to make a cut right >here<. What if that frame is a b frame and has dependencies in two directions? You need to seek all over the place to gather up the frames, run the GOP sequence (which may run to hundreds of frames in heavily compressed material) from the last iframe to the current frame (and possibly slightly beyond if it's a bframe) before you end up with a full frame that you can cut at, then you have to rebuild a whole new GOP. All this gives really bad performance for editing. Anyone who has used AVC will be familiar with this problem. DivX etc all use this kind of format, and no surprises, they are all rubbish for editing, great for playback.
The ideal format for editing is "iframes only", where every frame is self-contained (just like a JPEG image), so you can jump to any point in the movie and immediately get a full frame, and when you want to cut, you just cut, no GOP acrobatics necessary. Unfortunately this is bad for playback and distribution as if it's to have decent quality levels, it has to do without all the gains that p and b frames can provide, and thus tends to have very high bandwidth *or smaller frame sizes*. Unfortunately most of the advantages of H.264 are thrown out with the p and b frames.
I'm guessing that 'iFrame' is an iframes-only format. It seems a shame that they would limit it to a small frame size, though this may be a bandwidth issue - 1080p with iframes only would require either massive storage or low quality, but that should really be a user choice. Perhaps the cameras can't handle the data rates it would require?
Upshot of all this is that we need more info, so we'll have to wait and see.
- by CarlinJ216 October 15, 2009 9:12 PM PDT
- +1..... great info
- Like this Reply to this comment
-
(35 Comments)