Do you love AVCHD, but hate the long, disk consuming transcodes? Well, ClipWrap 2.0 is here, and it lets you turn your AVCHD mts files into Quicktime compatible mov files, with no transcoding, and no generation loss. Dig it.
(disclaimer: the author of ClipWrap is a friend)
Sony has announced a couple new additions to the XDCamEX family – the PMW-350 and the PMW-EX1R.
The 350 is a shouldermount camera with interchangeable lenses and 2/3″ chips. That puts it somewhere between the 1/2″ PDW-F355 and the 2/3″ 4:2:2 PDW-700.
The EX1R is a minor bump to the EX1, adding features that users have asked for, like a dedicated viewfinder and a DVCam recording mode.
For me, the most interesting bit of news is that Sony is launching the “MEAD-MS01,” an SXS to MemoryStick adapter. I guess Sony noticed that many EX1 and EX3 users have been using SD adapters, and decided to get into that market. And of course, they had to use everyone’s least favorite flash format, Memorystick. I’ll stick to my SD cards for now, but it’s nice to see Sony “legitimize” that recording option a bit.
So I’ve been playing with an interesting “feature” in PCP2 – the “chapterize” command generates different results when it can talk to the window server versus when it can’t. In my case, it generates much better results in the case of the former.
“But,” you say, “my PCP2 xgrid jobs can’t talk to the window server!”
Very true. However, you can change the user that PCP2 uses to submit Xgrid jobs, and Xgrid will run the job with that user’s permissions if everyone is single signon’d to the same kerberos domain.
So, now we’ve got PCP2 jobs running as a real user. Next, log into the GUI as that user.
Now, when PCP2 workflows run, they’ll be able to talk to the window server, and at least in the case of “chapterize,” use what appears to be the “Good” code path. Faster, more accurate, more delightful.
I’ve seen some hilariously uninformed posts about the new Apple iFrame specification. Let me take a minute to explain what it actually is.
First off, as opposed to what the fellow in the Washington Post writes, it’s not really a new format. iFrame is just a way of using formats that we’ve already know and love. As the name suggests, iFrame is just an i-frame only H.264 specification, using AAC audio. An intraframe version of H.264 eh? Sounds a lot like AVC-Intra, right? Exactly. And for exactly the same reasons – edit-ability. Whereas AVC-Intra targets the high end, iFrame targets the low end.
Even when used in intraframe mode, H.264 has some huge advantage over the older intraframe codecs like DV or DVCProHD. For example, significantly better entropy coding, adaptive quantization, and potentially variable bitrates. There are many others. Essentially, it’s what happens when you take DV and spend another 10 years working on making it better. That’s why Panasonic’s AVC-Intra cameras can do DVCProHD quality video at half (or less) the bitrate.
Why does iFrame matter for editing? Anyone who’s tried to edit video from one of the modern H.264 cameras without first transcoding to an intraframe format has experienced the huge CPU demands and sluggish performance. Behind the scenes it’s even worse. Because interframe H.264 can have very long GOPs, displaying any single frame can rely on dozens or even hundreds of other frames. Because of the complexity of H.264, building these frames is very high-cost. And it’s a variable cost. Decoding the first frame in a GOP is relatively trivial, while decoding the middle B-frame can be hugely expensive.
Programs like iMovie mask that from the user in some cases, but at the expensive of high overhead. But, anyone who’s imported AVC-HD video into Final Cut Pro or iMovie knows that there’s a long “importing” step – behind the scenes, the applications are transcoding your video into an intraframe format, like Apple Intermediate or ProRes. It sort of defeats one of the main purposes of a file-based workflow.
You’ve also probably noticed the amount of time it takes to export a video in an interframe format. Anyone who’s edited HDV in Final Cut Pro has experienced this. With DV, doing an “export to quicktime” is simply a matter of Final Cut Pro rewriting all of the data to disk – it’s essentially a file copy. With HDV, Final Cut Pro has to do a complete reencode of the whole timeline, to fit everything into the new GOP structure. Not only is this time consuming, but it’s essentially a generation loss.
iFrame solves these issues by giving you an intraframe codec, with modern efficiency, which can be decoded by any of the H.264 decoders that we already know and love.
Having this as an optional setting on cameras is a huge step forward for folks interested in editing video. Hopefully some of the manufacturers of AVC-HD cameras will adopt this format as well. I’ll gladly trade a little resolution for instant edit-ability.
Sure enough, Apple has announced iMovie 8.0.5 with support for the iFrame format. I win the prize!
Sanyo has announced some ‘A’ revisions to their existing FH1 and HD2000 cameras, which add a new “iFrame” mode. It appears this is an i-frame only h264 mode, at a reduced 960×540 resolution. It’s a very interesting idea – if other manufacturers adopted it as an optional setting, and if NLE manufacturers supported it, it could turn H264 into an edit-friendly format. Right now, editing H264 is hamstrung by the extremely long GOPs and complex interframe relationships. Going to i-frame only makes it essentially a more advanced version of a codec like DV or DVCProHD.
Interestingly, the bottom of the press release mentions that
“The iFrame logo and the iFrame symbol are trademarks of Apple Inc.”
That’s news to me. One wonders if Sanyo jumped the gun on a release, or if this is just a format that Apple uses internally in tools like iMovie, which Sanyo has co-opted. I’ll certainly be keeping my eyes open for an Apple announcement about “iFrame.”