[Stephen Norrington]

Hi Eric, the media is all progressive 24p (23.976fps etc.) direct from Panasonic GH2 cameras – as part of our tests, we’ve transcoded numerous AVCHD clips to PNG frame sequences and/or ProRes via all of the following apps:

Cineform, 5DtoRGB, MediaCoder, AE CS5, AME CS5, Blender versions 2.68a, 2.69, 2.70, CS6 AE and CS6 AME

All transcodes are clean except those from CS6 AE and AME. CS6 “bakes in” the problem during transcoding so it subsequently appears in frame sequences and ProRes media. All transcodes from the other apps are clean, in the case of resultant PNG frame sequences, absolutely lossless and indistinguishable from the AVCHD original.

It’s a deep mystery! We can only theorize that there’s some fundamental handling of AVCHD in CS6 that’s different from CS5 and perhaps CC – if we can know for sure we can solve our workflow and move on – anyone from Adobe’s tech backrooms clear this up for us ?:-)

Stephen Norrington
Artproject Independent Production

[Stephen Norrington]

Actually, we’ve tested for the issue at a number of different studios, not just ours, Mac and PC based, all with different updates of CS6, all with different hardware and we see the problem consistently in every case, on every AVCHD clip from many different sources.

These other studios, once they see the problem they discover that it’s been there all along in their own AVCHD footage too – perhaps the “consumer” status of AVCHD is why it hasn’t been noticed much? AVCHD not handled often by studios for VFX, just “DIY”-ers?

[Edit] – we took a look this morning at the fixes executed by the various CS6 updates but didn’t find anything relating to AVCHD handling.

My original post is a last gasp trying to understand what’s going on – we’ve 99% isolated the issue to something about how CS6 specifically handles AVCHD but can’t seem to pinpoint it – we tried swapping out the CS6 codecs with CS5 codecs throughout the CS6 architecture but saw no change which is why we’ve been theorizing about some deep difference between how the two CS flavors handle AVCHD.

In the meantime we’ve got a lot of workarounds going but it’s a drag to have to avoid using AVCHD natively in any CS6 applications – we’ve been handling the material in CS5 and other apps, getting to clean frame sequences and going back to CS6 for initial camera tracking to finalize in Blender – but CS6 AE/AME are great apps so we sorely wish there’s something obvious we’re missing which we could correct and have a more transparent pipeline.

If you didn’t already, please check out the representative image I posted in my reply to Eric. Cheers.

Stephen Norrington
Artproject Independent Production

[Stephen Norrington]

Hi Eric, no, no CC Cloud, we are a “quarantined” facility ie: no constant internet connections, no subscription software – we are built around Blender and use CS5 and CS6 as support, no need to move to CC.

The strange thing about the issue I’m describing is that it’s very pronounced and yet we find no mention of it on any forums – our first thought was that it must be something to do with our studio but that doesn’t seem to be the case – if someone can confirm that there’s a difference between how CS5 handles AVCHD and how CS6 handles it, that will clear up a lot of the mystery – if CS5 and CS6 are identical in their AVCHD handling then we investigate other possible causes.

Representative comparison image attached (exposure blown-out to emphasize the issue): 7538_avchdbaddecodecs5cs6comparison2.jpg.zip

Stephen Norrington
Artproject Independent Production

[Stephen Norrington]

Noticed it and did most of our tests on 11.0.0.378 but have seen it in every other updated version we’ve tried, on many hardware configs – have never seen it in any version of CS5 on any hardware configs.

Stephen Norrington
Artproject Independent Production

[Stephen Norrington]

Hi Chris, thanks for that, yeah, we see some very slight disturbances, especially with the Luminance/Chroma switch enabled.

We’ve decided to go with 16bit PNG – openEXR is a sledgehammer to crack a nut for our archiving needs and the (slightly) open questions about its future compatibility give us pause – there seems little doubt that PNG will persist unchanged and consistently supported for the foreseeable future and its compressed file sizes are comparable to openEXR’s best efforts, in some (solid-areas) cases squeezing down a 400mb file to 500k while staying completely lossless, at least visually – a neat trick 🙂 – best, SN

Artproject Independent Production

[Stephen Norrington]

Ah yeah, nice one, we didn’t do that – the visual differences between original and saved are noticeable when A-B’d but fortunately minor – the greater concern is that whatever is being done to the file to drop its size by a third might result in a tech-gotcha somewhere in the future.

For example, I’ve heard dark mutterings that the Luminance/Chroma save setting can’t be read by Nuke which doesn’t matter to us here because we don’t use Nuke. But I can imagine a gotcha like that turning up in future versions of Keylight and AE and our expensive openEXR production archive will then be a headache (we’re engaged in a long-term production, ten years or more – footage shot today won’t be edited for perhaps a decade) – SN

Artproject Independent Production

[Stephen Norrington]

Hi Dave, thanks for the response, we ran a bunch of tests and were unable to determine exactly what changes were made to the material with the Luminance/Chroma save setting checked.

There is some change, some kind of compression (the file size drops by a third) but, oddly, it actually seemed to improve keying of source material that was compressed when originated. This all seems too good to be true but we’ve not been able to glean exactly what the Luminance/Chroma save setting does under-the-hood from ILM’s documentation.

The fear is that saving with the Luminance/Chroma setting enabled may merge parts of the image in a way that will come back to bite us in future iterations of AE and Keylight.

Best,
Stephen Norrington

Artproject Independent Production

[Stephen Norrington]

Thanks Walter, Todd, much appreciated and fully understood – no guarantees in life 🙂 – cheers, Stephen

Artproject Independent Production

[Stephen Norrington]

Hi Todd, thanks for that. What’s your feeling also about openEXR as an AE-viable future-proof archive format? It’s significantly smaller than TIFF and the AVCHD material I have today will ultimately go into comps involving 3D far down the road, on a version of AE five years or more from now.

Stephen Norrington

Artproject Independent Production

[Stephen Norrington]

Hi Joel,

Not sure I have a sensible suggestion for how you might handle your interview clips – my project is 99% VFX so the interplay of sound and picture is entirely constructed after the fact – with interview material I can see how you would want to keep (cleaned-up) sound and picture together as much as possible.

I’ll offer more of an overview: I’ve found that spending a bunch of time at the beginning creating acceptable edit media (comped VFX renders, cleaned-up sound files, down-rezzed pixel dimensions, compressed formats etc.) is far more efficient (for a one man operation) than employing all the “time-saving” bells and whistles that are provided by the Adobe suites.

Once I have my full-rez material represented by acceptable edit media I never go back to the full-rez until the very last step before delivery. At that stage there is also some time required to do the manual eyematch but it’s far less and far cleaner that doing it on the fly, with buggy machine help, scene by scene.

Also, the workflow I describe makes it easier to work around Adobe’s lack of backwards compatibility because there’s no project data interchange between the AE and PrPro steps ie: the intermediate file formats are just sound and footage, not project data thus not hindered by gotchas.

Of course, when I conform my final at the end I lay my sound up against it and it all fits perfectly. This is a legacy approach stemming from my years as a narrative film editor using actual 35mm film :-0 – so it may not be as applicable to your documentary task.

Summary: I’ve found the simple direct route is always faster that the complex pipeline despite the simple route feeling more laborious. The complex route feels less laborious because it has loads of attention-demanding steps and junctures but, in my experience, ends up taking longer and being less reliable.

Cheers,
Stephen Norrington

Artproject Independent Production