Transcoding AVCHD to ProRes?

[M Carter]

Indeed, sometimes learning even what parameters to test gets you off to a good start.

I've reached the point in my darkroom that I'm going to completely re-evaluate my ISO rating and development, and nail my usage down 3 B&W films and 2 developers. Reminds me of the days when testing actually cost money (I'll go through about 6 35mm rolls and 3 or 4 120 rolls, and a bunch of paper). So I'm very glad I have some starting points...

[Dogtown]

I would love to use AVCHD with my old macbook pro 2010, and with my late 2012 iMac, but working in Premiere Pro be it CS6, or CC, if I try and do FX ( Magic Bullet ) or color correction, even light work the AVCHD is so slow! So I always when working with AVCHD now transcode with Clipwrap, or 5dtoRGB, (mostly Clipwrap) and keep the transcode at 422.

If I do have the option and I know I'll be doing a grade or FX, with the C100 I'll record to and external recorder ProRes 422.

I believe in testing, but I also do my research and take advice from a lot of these amazing camera forums, it has saved me a lot of time and testing.

Now using the mercury playback engine is another topic and covered at adobe forums ( when using Premiere ) The CC Premiere Pro version supports Mercury playback, I found the older Premiere Pro CS6 was not supported on my iMac?  

 

Broatch Berry

Venice CA

screamingdime.com

[jgharding]

I've used C100 AVCHD native in Premiere for a couple of years with no problems.

You don't gain any grading latitude by transcoding to another codec even if it is uncompressed 16-bit or whatever, as the Mercury Engine is moving around in a 32-bit space anyway using acceleration to decode and render. Just be sure to render your final with "render at maximum bit depth" ticked and you'll be good.

Transcoding is for when you don't have a native engine or your computer can't handle the playback so need to make it iFrame.

I've A/B tested it with Premiere and unsurprisingly, there was no difference. Most of the ones where there's difference are people not ticking the right boxes on export.

That's my experience!

[joema]

13 hours ago, User said:

...Like for example in my situation, the Mercury Playback Engine has always caused issues on my system so I go with OpenCL. With Don Kotlos comments on ProRes being a more friendly codec on systems not using a GPU, it helps me understand and make important choices above and beyond my on knowledge and tests....

You have CS6 and I think Mercury Playback was only introduced on CS5. It probably got a lot more use via nVidia/CUDA than OpenCL/AMD, so maybe that accounts for the reliability issues you saw. Re ProRes, this helps performance due to eliminating the need for H264 decoding. Long-GOP encode/decode like H264 cannot be greatly accelerated by normal GPU methods so using Mercury hardware playback doesn't help that per se. However Mercury hardware playback makes a huge difference on effects. Since virtually all editing requires effects the net result is GPU acceleration makes a big improvement even though it doesn't accelerate encode/decode by itself.

ClipWrap can either rewrap AVCHD which does not transcode but is faster to convert, or it can transcode which is slower to convert but will run faster on the editor. In your situation I would suggest transcoding. The tradeoff is ProRes takes about 8x the space of AVCHD and also requires more I/O for that lower-density data. However it greatly lowers the CPU consumption of editing and improves responsiveness.

In general I would suggest moving from CS6 to some other editor, whether that is Premiere CC, FCPX, or Resolve. CS6 is really old, is not being maintained, and you will get better performance, reliability and features on any of those other editors.

[User]

Nice breakdown and explanation Joema. Good to finally have some solid insight... thanks!

I'm actually on PPro CC 8.2.0. And with regards to the Mercury Engine using 8.2.0, I remember feeling like there were stability issues so I kept using OpenCL. Maybe I should switch back to see how stable things are?

[User]

On 4/29/2016 at 9:30 AM, Policar said:

If you're concerned about super whites, definitely choose extended range to flatten the image and bring them back in legal range. That said, if 422 standard is 8 bit and you shot Canon Log you might be getting a bit too flat for an 8 bit finishing codec. Guessing it's not the end of the world, though.

Hope it goes well.

I'm about to start the process of transcoding the C100 MkII AVCHD material using 5DtoRGB. My settings will be:
ProRes 4.2.2
Rec709
Full Range
No Post Processing. Gamma 1.0

The C100 MkII material was shot in WDR picture profile so it won't be as 'flat' as C-log. As such, do you still recommend 'Full Range?' Like you said earlier, after transcoding, the material can still be tweaked to broadcast norms. Correct?

Cooling fans about to kick in...

[User]

x

[jgharding]

I'd upgrade to CC and save the transcoding trouble! :0

[User]

3 minutes ago, jgharding said:

I'd upgrade to CC and save the transcoding trouble! :0

Sorry if it wasn't clear, and thanks for the insight, but as mentioned twice in this thread, I am on CC.

I went ahead with the transcode to ProRes because of the 4.2.2 space and because I will grade and add effects. Moreover, I have had issues with the Mercury Playback Engine while using 8.2.0 (Creative Cloud 2015). Also because another member suggested that it makes round-tripping between other programs easier.

[joema]

14 hours ago, User said:

..I'm actually on PPro CC 8.2.0. And with regards to the Mercury Engine using 8.2.0, I remember feeling like there were stability issues so I kept using OpenCL. Maybe I should switch back to see how stable things are?

On my 2015 iMac 27, the Premiere CC options are Mercury Playback GPU Acceleration (OpenCL) and Mercury Playback Engine Software Only.  For nVidia GPUs you may also have a CUDA option for GPU acceleration. You have a 2013 MacBook Pro but there are many variants of that, some with integrated GPU and some with discrete GPUs. Either way it's probably worth trying Mercury Playback GPU acceleration if you are not using it.

[User]

23 minutes ago, joema said:

On my 2015 iMac 27, the Premiere CC options are Mercury Playback GPU Acceleration (OpenCL) and Mercury Playback Engine Software Only.  For nVidia GPUs you may also have a CUDA option for GPU acceleration. You have a 2013 MacBook Pro but there are many variants of that, some with integrated GPU and some with discrete GPUs. Either way it's probably worth trying Mercury Playback GPU acceleration if you are not using it.

Thanks Joema

2013 Macbook Pro Retina
Intel HD Graphics 4000 - VRAM (Total) 512MB
NVIDIA GeForce GT 650M - VRAM (Total) 1024MB

I used PPro CS6 for 3 years and found the Mercury Playback Engine to be unstable. I went with OpenCL.
I have been using CC 2015 (8.2.0). After installation (6 months ago), I remember getting the same buggy freezing action. So again I went with OpenCL.

I will have another try at Mercury on this machine but I'm not optimistic. I'll report back afterwards.

[User]

Transcode example using 5DtoRGB

Both jpegs were exported from PPro CC2015. No grading/ correction.
1st jpeg: Original AVCHD
2nd jpeg: Original AVCHD transcoded to ProRes using 5DtoRGB using 'Full Range'.
3nd jpeg: Original AVCHD transcoded to ProRes using 5DtoRGB using 'Broadcast Range'.
 

The difference between jpeg 1 and jpeg 2 is easily discernible.

The only perceivable difference between jpeg 2 and jpeg 3 is seen in the YC Waveform. Broadcast Range brings the 110 IRE down to 100 IRE. 

Comments?

[Policar]

7 hours ago, User said:

I'm about to start the process of transcoding the C100 MkII AVCHD material using 5DtoRGB. My settings will be:
ProRes 4.2.2
Rec709
Full Range
No Post Processing. Gamma 1.0

The C100 MkII material was shot in WDR picture profile so it won't be as 'flat' as C-log. As such, do you still recommend 'Full Range?' Like you said earlier, after transcoding, the material can still be tweaked to broadcast norms. Correct?

Cooling fans about to kick in...

Based on your above example, I got it backwards. I'd go with whatever pushes down the super whites so you can keep them when you go to After Effects etc.

[User]

3 hours ago, Policar said:

Based on your above example, I got it backwards. I'd go with whatever pushes down the super whites so you can keep them when you go to After Effects etc.

Why, does After Effects not see anything above 100 IRE?

[Policar]

46 minutes ago, User said:

Why, does After Effects not see anything above 100 IRE?

In my experience it sees it in float mode but not 8 bit or 16 bit. But float mode is quirky. Something to do with YUV to RGB conversion. Not sure. Not important if you're not using it, either.

[User]

18 minutes ago, Policar said:

In my experience it sees it in float mode but not 8 bit or 16 bit. But float mode is quirky. Something to do with YUV to RGB conversion. Not sure. Not important if you're not using it, either.

Hmmm.
I almost never use After Effects... though someone might bring these skills to the film down the road and I hope they wouldn't be limited as I have transcoded a fairly large chunk of material since beginning the render. I guess it can always rendered again.
I guess at the end of the day, I'm happy to see that with the 'Full Range' setting the IRE is touching 110 IRE and in PPro I've seen in the past that there is a percentage of highlight detail in that range retained. Maybe at 'Broadcast Range' (100 IRE) that detail may not be so easily accessible anymore. I don't know... ya know?

[jgharding]

C100 appears to capture over 100 into super. Using it in Premiere you can just pull it back, it's not a hard clip, that's probably the float engine at work. It's really useful. You'll probably lose that when you transcode I'd guess.

I wonder if "full range" in 5D2RGB is pushing that down into a 0-100 file, hence the look?

32-bit in AE sees it all, slows working down though. I often work in 8-bit, occasionally check 32, and render in 32.

On 04/05/2016 at 0:55 PM, User said:

Sorry if it wasn't clear, and thanks for the insight, but as mentioned twice in this thread, I am on CC.

I went ahead with the transcode to ProRes because of the 4.2.2 space and because I will grade and add effects. Moreover, I have had issues with the Mercury Playback Engine while using 8.2.0 (Creative Cloud 2015). Also because another member suggested that it makes round-tripping between other programs easier.

 

Ah I missed that, sorry. Yes if you're having trouble with Mercury I'm sure ProRes will be easier on the system.

[User]

5 hours ago, jgharding said:

C100 appears to capture over 100 into super. Using it in Premiere you can just pull it back, it's not a hard clip, that's probably the float engine at work. It's really useful. You'll probably lose that when you transcode I'd guess.

I wonder if "full range" in 5D2RGB is pushing that down into a 0-100 file, hence the look?

32-bit in AE sees it all, slows working down though. I often work in 8-bit, occasionally check 32, and render in 32.

Thanks JG. Appreciate the tips.

When I look a the ProRes transcodes done using 'Full Range' on the YC Waveform, the super whites riding up to 110 IRE. So I think that must be a good thing.

[User]

After a 7 day render turning 1TB into 6TB, I can say that scrolling around on the timeline with ProRes is so much more fluid vs. AVCHD. Night and Day.

[Axel]

On 4. Mai 2016 at 5:23 PM, User said:

Transcode example using 5DtoRGB

Both jpegs were exported from PPro CC2015. No grading/ correction.
1st jpeg: Original AVCHD
2nd jpeg: Original AVCHD transcoded to ProRes using 5DtoRGB using 'Full Range'.
3nd jpeg: Original AVCHD transcoded to ProRes using 5DtoRGB using 'Broadcast Range'.
 

The difference between jpeg 1 and jpeg 2 is easily discernible.

The only perceivable difference between jpeg 2 and jpeg 3 is seen in the YC Waveform. Broadcast Range brings the 110 IRE down to 100 IRE. 

Comments?

Yes, we had this before.

If your 8-bit camera records in broadcast range, it most probably means 16-235. The range between 236 and 255 is not clipped, it just doesn't show immediately because it's 'superwhite'. But the highlights can be recovered in your NLE by drawing 110 beneath 100, thereby remapping the original values by a gamma curve.

But:

If you let remap 5D2RGB the 235 of your recording to 1024 in 10-bit ProRes, you lose these 'illegal' values. That's what happens if you choose "Full Range" (sounds better, but isn't).

That's what your images show - blown out sun in full range.

Only very few 8-bit cameras record full range, among them the 5Ds, if I don't err. 

What about floating point?

The 10-bit of ProRes don't help much if a mere 8-bit image is the source. With 32-bit computing, an 8-bit image is treated as if it had a much higher bit depth. There are practically no 'rounding errors'. An 8-bit clip transcoded to ProRes remains an 8-bit image, there is no wizardry going on. Only with floating point precision you can avoid banding and other artifacts during grading - with AVCHD originals just as good as with ProRes copies. The latter are just more edit-friendly, and that's the extend of it.

There are some very good tutorials on the web that prove these simple facts, but I am on a train with a cell phone and won't search for them now.