GPU Acceleration in Snow Leopard...
 

Apple - Mac OS X - New technologies in Snow Leopard

Could this mean native AVCHD editing in subsequent versions of iMovie and Final Cut, without transcoding?

Been wondering about that for awhile also. Guess we'll find out Friday.

Just to clarify this topic a bit, transcoding should never be required whatseoever if native AVCHD editing is performed which only cuts, splices / joins two AVCHD clips. Transcoding will ALWAYS be required if other changes are made to the clip including any filters, transitions, color, brightness, sharpness, contrast, or other video changes, adding titles, etc. Whenever the content of frames need to be changed, the video will have to be uncompressed, modified, and then recompressed.

I raise this point since GPU accelerated AVCHD on the PC has been around for quite a while now with the CUDA-enabled programs like TMPGE, Power Director, Badaboom, and others, and none of these provide nor do they require any way to speed up the normal "cuts-only" editing. The programs which do perform AVCHD cuts-only editing have done so without any GPU acceleration, and these are the fastest AVCHD programs on the market (Nero Vision, Corel Video Studio, Ulead Movie Factory, Cyperlink, etc.). They perform the cuts-only edits without needing to modify frames and thus output the edited file exactly in the same GOP / frame content and structure as the original clips.

I would thus assume that GPU assist, if applied on the Mac to AVCHD, would speed up transcoding as it does on the PC for those editing situations where "cuts-only" cannot be applied, but that cuts-only editing with no transcoding will only come when the authors of Macintosh apps such as Final Cut and iMovie decide to incorporate it.

At present, neither Final Cut nor iMovie apparently has this capability, so adding GPU acceleration could only achieve a benefit for those situations where transcoding is actually required. Perhaps this will be achieved with Snow Leopard.

Larry

Just for my clarification, since AVCHD is a long GOP format of I-Frame (key frame) followed by a number of B or P frames for each 1/2 second or so of video, isn't it hard to just cut on a I-frame and have accurate editing? I mean I've done it in some MPEG editors, but there is a kind of 'snapping' to the I-frame so you can only have 1/2 second 'granularity' of the edit, which isn't fine enough for any except for rough assembly. If you want finer edits, you'd have to transcode (at least internally) wouldn't you?

I would really, like the new Snow Leopard and GPU OpenCL software developers to take advantage of this, so far though I don't think any Mac software actually does. It would be great if some future version of FCP used the SnowLeopard OpenCL API to accelerate things like this, and I think someday it will.

Editing on I frames will indeed restrict the precision to .5 second granularity, and thus prevent fine control. Shorter GOPs and AVC Intra are less compact but easier to edit. Breaking a long GOP and creating a smooth splice with another broken GOP is inherent in modern mpeg editing software. The method of avoiding a "lump" is to create a smooth transition which blends old and new frames in a way which preserves the GOP structure and cadence along with time stamps for sound presentation in sync. The result is thankfully imperceptibly 'glitched' to human perception but very visible if slow motion playback is used.

GPU acceleration has terrific potential for the Mac, and Motion does exploit it in both prior and present revs of FCP. Hopefully Compressor, iMovie, FCExpress, DVD Studio, etc. will follow.

Larry

Larry, I don't know which software you use to edit, but most Mpeg editors and those that can correctly handle native AVCHD don't add fades or anything else at your edit point. What they do is to rebuild the GOP's either side of the edit point to ensure that a new I frame is created at the cut point. There is no blending of GoP's. This will be a seamless hard cut whatever your playback speed and you can make your cut anywhere you want. The days of Long GoP being an issue are years behind us now.

The current problem is that decoding AVCHD is very processor intensive, which is why many applications require that you transcode to a more editor friendly codec first.

I agree with your description Alister but only if the edit points where the splice occurs happen to coincidentally occur at I frames. For the more general case, however, where the end of each clip before joining has been trimmed to some arbitrary frame, the chance that the trimmed clips end exactly at I-frames is only 1 in 15. Therefore, the 'usual' situation is that two partially full GOPs need to be joined.

I am not sure what you mean when you say that GOPs are re-built around either side of the edit point to ensure that a new I frame is created. Since AVCHD (unlike mpeg2) supports no multi-angle playback, open GOPs are permissible, and B frames which have reference to prior GOPs are permissible. It would therefore be impossible to create a new I frame at the edit point without also forming a new additional GOP, thus preventing frame-accurate editing. I don't believe that two or more I frames are permissible in a single GOP in AVCHD.

Perhaps this is a misunderstanding on my part. I certainly welcome further clarification.

Larry

Larry, IIRC, HDV does not require an I frame at every 15th frame. I believe 15 frames is the maximum length allowable between I frames. So the structure can be rebuilt by adding additional I frames, thus allowing cuts on p and b frames.

Even if my memory is not serving me well at 4am PST, the fact of the matter is that Avid Media Composer can do frame accurate editing of HDV; you can place a cut wherever you like; the system doesn't move it or somehow cheat it. I have to believe Avid is not the only NLE that works in this manner.

Peter,

Not sure what HDV and Avid have to do with this at all. We are not only talking AVCHD / h.264 (mpeg 4 part 10), but to my knowlwedge Avid does not even support AVCHD (with the exception of the Pinnacle Studio program they acquired for consumer use).

Am I missing something here?

Larry

You simply close the GoP the frame before the cut and then build a new shortened Gop starting with a new I frame after the cut. Both the Gop before and after the edit point are recreated using only the required frames. You can place an edit wherever you want, you are not tied to only having edits at I frames. That's an old wives tale!

Alister,

I was not aware that AVCHD allowed variable length GOPs to be used. It certainly would simplify the edit process as you describe, although the rate control and prevention of buffer overflows considerably complicate the playback decoder design. If it indeed true that the GOP can be cut anywhere and closed, leaving small and variable GOP lengths in the process, this makes the job of the NLE vastly simpler when edit splices and trimming are needed.