Why exactly is AVCHD so hard to edit at DVinfo.net

Ed Sanders · January 3rd, 2009, 07:30 PM

Just wondering why exactly it takes so much processing power to edit AVCHD encoded video. For instance, I have an Intel Core 2 duo 2.0 ghz, so 4.0 ghz (roughly) total computational power. Why is it then that my editing software stutters at full frame playback when my tiny little HG20 manages to decode it at full quality for playback on a television? Is this to say that these little Canon cameras have really powerful low-voltage processors in them or that the algorithms for AVCHD decoding on a computer just aren't written well?

Larry Horwitz · January 3rd, 2009, 07:51 PM

Ed,

1. AVCHD camcorders contain custom chip sets designed exclusively to do one algorithm such as h.264 exceedingly well with a very specific and limited range of operation (such as 17 Mbit/sec rate, 12 bits dynamic range, etc.) whereas general purpose processors found in our computers have not been optimized for a specific purpose.

2. Some algorithms (not neccesarily h.264) are deliberately made to be asymetrical in their encoding versus decoding so as to shift the processing burden to the place where it can be better achieved. The camera "merely" has to encode whereas the computer has to decode for an algorithm where a big premium on power consumption and complexity needs to be performed in a small, battery-operated device.

3. Encoders have the "luxury" in a camcorder of knowing the exact signal to be encoded, whereas the decoder in the NLE or player has to develop 'estimates' based on analyzing motion vector and inter-frame differences. The lossy process is not only imprecise in the sense that it never entirely replicates the exact input to the encoder when decoding occurs, but merely approximates it very closely. The errors it makes are part of the anticipated loss, and can be traded for processing time in the decoder. Very lossy recovery can be achieved, but at the expense of image quality and stability. Extreme examples are dropped frames, stutter, macroblocking, and other artifacts which appear in the less than perfect decode.

4. Editing of AVCHD, as opposed to playback, requires creating synthetic frames from the originally encoded GOPs, making the NLE dynamically render visual effects for the editor which look like truly modified frames to allow for real-time preview, and then eventually turning the results back into AVCHD GOPs once again. This process is computationally huge.

Larry

Dave Blackhurst · January 3rd, 2009, 07:58 PM

The camera has a dedicated DSP chip, optimized to do what it does without any other considerations...

Your computer on the other hand does a few other things with varying degrees of speed and skill. ALL of course dependent on... the software!

From what I learned with HDV, the amount of optimization in the software can make a HUGE difference in playback speed/smoothness/quality on the exact same hardware. IMO this is where AVCHD still has some tweaking before it's "smooth". HDV sucked in the beginning too... now it's considered "normal".

The one thing that makes AVCHD a bit more problematic is that it has a higher compression rate - meaning that to uncompress a comparable series of frames there's more work to be done than with HDV or an .avi file. More work=more time=more cycles of the CPU, and again an inefficient software algorithm can make this far worse.

Gian Pablo Villamil · January 3rd, 2009, 08:50 PM

As Larry said, allowing frame-by-frame access to AVCHD is computationally expensive, since the intermediate frames have to be generated.

For playback, appropriate software makes a huge difference.

I had been using ffdshow (x264 codebase) for AVCHD playback, and it really staggered. I bought the CoreAVC decoder for $14, and that plays back seamlessly, even on a relatively underpowered lightweight laptop.

Jeff DeLamater · January 3rd, 2009, 09:07 PM

another thing, not every NLE is created equally. and that's not to disparage any particular software, just they different softwares are optimized differently, so they will perform differently, especially on computers towards the minimum requirement range (where my computer is as well).

my computer is a amd x2 4200+ (2 x 2.2ghz) with 2gb of ram, which is pretty close the the minimum requirements, and premiere elements performs terribly on my computer and sony vegas performs much better, so if you aren't already invested in a particular software suite, try out the demo for one of the other options.

January 3rd, 2009, 07:30 PM	#1
Ed Sanders Tourist Join Date: Dec 2008 Location: Atlanta, Georgia Posts: 4	Why exactly is AVCHD so hard to edit Just wondering why exactly it takes so much processing power to edit AVCHD encoded video. For instance, I have an Intel Core 2 duo 2.0 ghz, so 4.0 ghz (roughly) total computational power. Why is it then that my editing software stutters at full frame playback when my tiny little HG20 manages to decode it at full quality for playback on a television? Is this to say that these little Canon cameras have really powerful low-voltage processors in them or that the algorithms for AVCHD decoding on a computer just aren't written well?

January 3rd, 2009, 07:51 PM	#2
Larry Horwitz Major Player Join Date: Mar 2007 Location: Eggertsville, NY Posts: 528	Ed, 1. AVCHD camcorders contain custom chip sets designed exclusively to do one algorithm such as h.264 exceedingly well with a very specific and limited range of operation (such as 17 Mbit/sec rate, 12 bits dynamic range, etc.) whereas general purpose processors found in our computers have not been optimized for a specific purpose. 2. Some algorithms (not neccesarily h.264) are deliberately made to be asymetrical in their encoding versus decoding so as to shift the processing burden to the place where it can be better achieved. The camera "merely" has to encode whereas the computer has to decode for an algorithm where a big premium on power consumption and complexity needs to be performed in a small, battery-operated device. 3. Encoders have the "luxury" in a camcorder of knowing the exact signal to be encoded, whereas the decoder in the NLE or player has to develop 'estimates' based on analyzing motion vector and inter-frame differences. The lossy process is not only imprecise in the sense that it never entirely replicates the exact input to the encoder when decoding occurs, but merely approximates it very closely. The errors it makes are part of the anticipated loss, and can be traded for processing time in the decoder. Very lossy recovery can be achieved, but at the expense of image quality and stability. Extreme examples are dropped frames, stutter, macroblocking, and other artifacts which appear in the less than perfect decode. 4. Editing of AVCHD, as opposed to playback, requires creating synthetic frames from the originally encoded GOPs, making the NLE dynamically render visual effects for the editor which look like truly modified frames to allow for real-time preview, and then eventually turning the results back into AVCHD GOPs once again. This process is computationally huge. Larry

January 3rd, 2009, 07:58 PM	#3
Dave Blackhurst Inner Circle Join Date: Feb 2007 Location: Apple Valley CA Posts: 4,874	The camera has a dedicated DSP chip, optimized to do what it does without any other considerations... Your computer on the other hand does a few other things with varying degrees of speed and skill. ALL of course dependent on... the software! From what I learned with HDV, the amount of optimization in the software can make a HUGE difference in playback speed/smoothness/quality on the exact same hardware. IMO this is where AVCHD still has some tweaking before it's "smooth". HDV sucked in the beginning too... now it's considered "normal". The one thing that makes AVCHD a bit more problematic is that it has a higher compression rate - meaning that to uncompress a comparable series of frames there's more work to be done than with HDV or an .avi file. More work=more time=more cycles of the CPU, and again an inefficient software algorithm can make this far worse.

January 3rd, 2009, 08:50 PM	#4
Gian Pablo Villamil Regular Crew Join Date: Mar 2006 Location: New York, NY Posts: 138	As Larry said, allowing frame-by-frame access to AVCHD is computationally expensive, since the intermediate frames have to be generated. For playback, appropriate software makes a huge difference. I had been using ffdshow (x264 codebase) for AVCHD playback, and it really staggered. I bought the CoreAVC decoder for $14, and that plays back seamlessly, even on a relatively underpowered lightweight laptop.

January 3rd, 2009, 09:07 PM	#5
Jeff DeLamater Regular Crew Join Date: Dec 2008 Location: Smyrna, GA Posts: 28	another thing, not every NLE is created equally. and that's not to disparage any particular software, just they different softwares are optimized differently, so they will perform differently, especially on computers towards the minimum requirement range (where my computer is as well). my computer is a amd x2 4200+ (2 x 2.2ghz) with 2gb of ram, which is pretty close the the minimum requirements, and premiere elements performs terribly on my computer and sony vegas performs much better, so if you aren't already invested in a particular software suite, try out the demo for one of the other options.