Trying to understand AVCHD

[Jeremy Garchow]

HDVs close, but younger and smarter cousin. Equally hard to process, fcp can’t handle it natively. Better quality (more modern compression technique, mpeg4 vs mpeg2 of hdv). Similar file sizes with hyper efficient compression.

More audio channels, more frame rates, IT based vs tape based.

You’re lucky though as FCP requires you to transcode very frame to ProRes.

It certainly has a future. Competing camera companies came together to develop it. And until bandwidth is unlimited, it will stick around for a while as it has to.

[Bill Willins]

Thanks Jeremy. Do you think FCP will handle this codec natively in its next major re-write…coming in the not to distant future ?

[Walter Biscardi]

[Bill Willins] “Thanks Jeremy. Do you think FCP will handle this codec natively in its next major re-write…coming in the not to distant future ?”

Really none of us can offer insight on that one. You will find out the same time the rest of us find out. Whenever Apple decides to release a revised version of the suite. When that will be, I would not venture a guess.

I’ll be at NAB in April so if Apple decides to show us something, I’ll get to see it. If not, well I’ll be spending a lot of time at the Avid and Adobe booths.

Walter Biscardi, Jr.
Editor, Colorist, Director, Writer, Consultant, Author, Chef.
HD Post and Production
Biscardi Creative Media

“Foul Water, Fiery Serpent” Winner, Best Documentary, LA Reel Film Festival.

Blog Twitter Facebook

[Jeremy Garchow]

If you know FCP is getting a major rewrite in the not too distant future, then you know more than me.

😉

Jeremy

[Gary Askham]

I’ve seen some good things from AVCHD even though it is quite a low bitrate codec. You must remember that there are a number of different types of AVCHD – some better than others.

I still avoid editing any of these newer “camera” codecs given the choice – HDV, XDCAM, Nanoflash, NXCAM and AVCHD (and obviously h.264). Even if FCP started supporting AVCHD I would prefer to transcode it before it got onto my timeline. Computers are getting more and more powerful and drives getting faster and faster but I still like the responsiveness of a codec designed for editing – DV, ProRes, DNxHD and Uncompressed.

I’ve now accepted that these codecs are here to stay and that it makes sense for a camera to record to a codec that can be recorded to slower, cheaper media and take up hardly any space.

But the stability and responsiveness you lose in the edit are not worth the extra few GBs you save on hard drive space. I know that Premiere and Avid now are capable of editing some of these camera codecs and FCP has been able to edit HDV and XDCAM natively for a few years. But I like my sequence to start playing when I press play and not crash when I move a clip into the timeline.

I’ve read that a FCP refresh may come as early as April – with a further update in the Summer when OSX Lion comes. And if it adds native AVCHD support I’ll probably continue transcoding to ProRes.

————————
FCP and Avid Technical Support
Air Post Production
Shoreditch – London

[Don Walker]

With the speed that FCP transcribes AVCHD to ProRes, it would foolish to edit AVCHD natively even if you could. ProRes would use your computers resources so much more efficiently!. I have been using a Panasonic HMC-150 as a second camera to an HPX-170 and on the timeline the footage looks identical. I would be willing to bet that the HMC-150 would hold up pretty well as a 2nd to some higher end cameras as well. It’s a great little camera and workflow. (ALWAYS BACK UP YOUR SD CARDS TO A HARD DRIVE!!!!)

don walker
texarkana, texas

John 3:16

[Ben Holmes]

I would hope that if a new version of FCP DID support AVCHD natively, it would also offer quicker import to ProRes – let’s hope so, as there are many advantages to this workflow. To be clear to the OP about the benefits – ProRes is a 10-bit codec, and will handle changes (filters, CC etc.) better than putting the AVCHD into the timeline. AVCHD at ANY bitrate is 8-bit, limited to 256 levels of luma and chroma, whatever compression is used.

Although I suppose this can be overcome by rendering an AVCHD timeline in ProRes, I would prefer to have all my media in one codec, whatever the source – ProRes is also great for rendering gfx out of Motion or After Effects.

Personally, I’d prefer not to see so many cameras recording these long-GOP, heavily compressed formats, however good they can look at the increased bit-rates of the ‘pro’ AVCHD cameras – it will always pass a performance overhead to the edit system and keeps 8-bit video on the radar at a time when others are moving to 12-bit or 14-bit RAW workflows

Edit Out Ltd
—————————-
FCP Editor/Trainer/System Consultant
EVS/VT Supervisor for live broadcast
RED camera transfer/post
Independent Director/Producer

https://www.blackmagic-design.com/casestudies/detail.asp?case=therydercup

[Bill Willins]

Wow, thanks everyone for all the great insights. The COW at it’s best strikes again. BW

[Jeremy Garchow]

Ben Holmes: “I would hope that if a new version of FCP DID support AVCHD natively, it would also offer quicker import to ProRes”.

That’s the thing, ProRes is no slouch to encode, either. What would be sweet is a dedicated USB ProRes encoder, like the elgato turbo h264, but in ProRes.

I wish LongGOP would go away as well. Panasonic has some awesome I frame codecs. 100mb/sec dvcpro hd is a little heavy bandwidth wise to move around very easily. 50mb/sec avc-intra (AVC-I 50) is 10 bit and 50mb/sec which can fit in to some broadcast workflows. AVC-I 100 is very very nice, but again, kinda heavy in a broadcast sense.

12 or 14 bit RAW workflows for broadcast are very far off. I don’t care what other websites tell you 😉

Jeremy

[Andrew Rendell]

There’s always going to be some issues with heavily compressed codecs. What a long GOP means is that the frames are a mixture of encodings that are called “I”, “B” and “P” and of those only the “I” frames actually have all the information required to display the frame and the “B” and “P” frames need the computer to add information from the other frames before/after them, so whenever you do a cut you’re changing the sequence of frames, so the encoding of a whole bunch of frames before and after the cut falls down and the computer has to do a load of processing to rebuild them in a way that’ll play. (It’ll cut fine if the last frame of the outgoing shot and the first frame of the next shot are both “I” frames, but you don’t know which frame is which coding). Codecs that use all “I” frames are fine (as a couple of people have mentioned) but have much higher bit rates.

Also, compression chucks away information in a way that doesn’t look bad when you just watch the shots, but I really messes up your ability to derive keys from it, e.g., getting green screen composites to work is a real pain if the footage is compressed.

There’s another issue that I’ve encountered, which is that TV broadcasting is compressed and if you compress pictures that have already been compressed, especially with a different codec, the picture quality takes a nose dive. It’s called concatenation and you can get hours of grief if what you supply to a broadcaster fails their technical standards.