FCP to Color for Consolidate, then DaVinci

[Rosario Balistreri]

Hi!

I'm writing here because it's a forum made by professional people, opposite of other minor forum that are plenty of videographers that "didn't note the difference between ProRes LT and HQ".

I worked this year with many RED One projects and usually I edited offline with ProRes Proxy, then recapture with L&T of Final Cut Pro in Native R3D without handles, so the capture step was fast because it "rewrap" only edited frames and not all the clip.
Then I sent to Apple Color for grading, accessing at original red data, as explained in the whitepaper.

Now i'm switching to Resolve and there are also many projects shot on DSLR.
I'm writing a workflow for maximize the quality of the transcoding (using 5DtoRGB) and not L&T of Final Cut.
In this way I have to having in my hard drive a 6 minute clip also if I used three frames of it.

I tough to send the timeline from FCP to Color, Add all to the render queue and render again in Apple ProRes 4444. So it's like generating new files with only the frames that were edited, "deleting" unused frames, then resend to FCP and now export the XML for DaVinci.

In this way I have 5% of disk space used but my question is:
Passing through Color and recompressing it (from Apple ProRes 4444 to Apple ProRes 4444, so same codec) will reduce the quality of the footage or not?
I'm thinking also to use this workflow for a first light for having much possibilities with the two nodes only of Lite version of Davinci.

So:

editor edits in Premiere (I suppose), export xml, I'll import xml into final cut, creating the file list to convert (make online with 5DtoRGB is better then other quicktime-based converters), convert all needed files, reconnect the timeline, send to color, (do a first light), render also untouched clips just for carry only used frames, send to fcp, export xml, import in davinci, having fun with grading.

Let me know and excuse me if I made some grammar errors, it's late and i'm italian =)

 

[Tim Sutherland]

Color is unnecessary, what you want is the media manager function of FCP. It will create a new project and render out only used portions of each clip if that's what you tell it to do.

Tim

 

[Rosario Balistreri]

Color is unnecessary, what you want is the media manager function of FCP. It will create a new project and render out only used portions of each clip if that's what you tell it to do.

Tim

Yeah! Thanks, i usually use "Create offline" and then batch capture, but in this case your suggestion is better...

But what about the recompression? It's practically lossless or I could have gamma shift or other artifacts?

I can't test it these days because i'm working on something that take me all the days, so if there is someone that know the answer could be good, else I'll wait to have some free time to test =)

 

[Alexander Ibrahim]

You can also just render in source mode in Resolve.

That gives you a bunch of files from sources, just like rendering in Color.

My question is how much footage are we talking about here?

I have a whole feature shot on a DSLR as original camera footage and converted to ProRes HQ (via 5DtoRGB), plus a lot of work files and scouting data on a single 2TB HD, with 800GB free.

On another note ... I won't be using 5DtoRGB anymore. I am happier with the results from doing the conversion in Resolve (Source mode ... useful.) plus I can do a one light. (Why do we still call it a "one light" anyway. How about "base grade"?)

 

[Rosario Balistreri]

You can also just render in source mode in Resolve.

That gives you a bunch of files from sources, just like rendering in Color.

My question is how much footage are we talking about here?

I have a whole feature shot on a DSLR as original camera footage and converted to ProRes HQ (via 5DtoRGB), plus a lot of work files and scouting data on a single 2TB HD, with 800GB free.

On another note ... I won't be using 5DtoRGB anymore. I am happier with the results from doing the conversion in Resolve (Source mode ... useful.) plus I can do a one light. (Why do we still call it a "one light" anyway. How about "base grade"?)

In this way I can stay away from Color, the consolidate could be done directly in this way in Resolve, fine!
As I'm limited to two nodes, there is a faster way to "consolidate what I graded up to now" then render in source mode, export the XML and reimport it immediately?
Thanks for the suggestions!

EDIT: it's for a webseries, 7 episodes of 20 minutes each one, hundreds of clips I think

I call this step "first light", but basegrade is also a proper term...

 

[Marc Wielage]

Why do we still call it a "one light" anyway. How about "base grade"?

Leftover from classic film lab tradition, referring to workprints made with one overall correction. There's also a "best light," where you match each scene as an overall -- better than a one-light, but not a final.

True one-light transfers are generally only done for tests, at least for film shoots.

 

[Thomas Worth]

You can also just render in source mode in Resolve.
On another note ... I won't be using 5DtoRGB anymore. I am happier with the results from doing the conversion in Resolve (Source mode ... useful.) plus I can do a one light. (Why do we still call it a "one light" anyway. How about "base grade"?)

Keep in mind that Resolve is subject to the exact same problems as every other piece of software that relies upon the Apple H.264 decoder. Blackmagic still use the legacy QuickTime API in Resolve for working with H.264 footage.

This really is a workflow killer, because you can edit properly chroma smoothed H.264 in Premiere CS5.5 for example, but once you export your XMLs it's up to the next application in the workflow to live up to the same quality as the MainConcept decoder used in CS5.5. Resolve's isn't as good, relying instead on QuickTime for format support other than uncompressed and DV/DVCPRO (like the original Linux Resolve).

I am working on a way to address this using 5DtoRGB. I would avoid having Resolve decompress H.264 at all costs.

If you want to test this for yourself, yank QuickTimeH264.component out of /System/Library/QuickTime, restart Resolve and see if it can decode H.264 footage. If it can't, then it's using the Apple H.264 decoder.

 

[Rosario Balistreri]

So now my workflow is:
Import XML in FCP, get file names, convert manually or in batch with 5DtoRGB and relink files. Then consolidate in FCP (or directly in Resolve with the first grade) from 5DtoRGB prores (so H264 shouldn't be a problem), reimport and start with the real grading.
Any other advise?

Sometimes happened that I reimported some graded footage with black levels around 10% and whites to 90%... There is a "check" that I didn't see?

Thanks for reply

Ros

 

[Alexander Ibrahim]

Keep in mind that Resolve is subject to the exact same problems as every other piece of software that relies upon the Apple H.264 decoder. Blackmagic still use the legacy QuickTime API in Resolve for working with H.264 footage.

This really is a workflow killer, because you can edit properly chroma smoothed H.264 in Premiere CS5.5 for example, but once you export your XMLs it's up to the next application in the workflow to live up to the same quality as the MainConcept decoder used in CS5.5. Resolve's isn't as good, relying instead on QuickTime for format support other than uncompressed and DV/DVCPRO (like the original Linux Resolve).

I am working on a way to address this using 5DtoRGB. I would avoid having Resolve decompress H.264 at all costs.

If you want to test this for yourself, yank QuickTimeH264.component out of /System/Library/QuickTime, restart Resolve and see if it can decode H.264 footage. If it can't, then it's using the Apple H.264 decoder.

Uh ... I don't think Resolve uses the Quicktime API.

I know for example that it renders ProRes 4444 even though I have only FCP 6 on the system it is installed on. (Quicktime itself only renders ProRes 422 and ProResHQ ... it will not render ProRes4444 or ProResLT, but Resolve will.

I'm not going to yank QT components though on a working system.

 

[Alexander Ibrahim]

As I'm limited to two nodes, there is a faster way to "consolidate what I graded up to now" then render in source mode, export the XML and reimport it immediately?

That's called Resolve.

The full license of Resolve lets you use unlimited nodes. Its just $995

 

[Florian Stadler]

Throw all camera original media into Resolve Media Pool, load XML in conform and you're in business. No need to go through any other program.

 

[Rosario Balistreri]

Uh ... I don't think Resolve uses the Quicktime API.

I know for example that it renders ProRes 4444 even though I have only FCP 6 on the system it is installed on. (Quicktime itself only renders ProRes 422 and ProResHQ ... it will not render ProRes4444 or ProResLT, but Resolve will.

I'm not going to yank QT components though on a working system.

Maybe Resolve has an exact copy of FCP7 Prores encoder?

That's called Resolve.

The full license of Resolve lets you use unlimited nodes. Its just $995

Yeah, i'm saving money for it, but now i'm a student and I can't reach 1000$ in short time.
Considering that I'm studying in another city there are also a lot of costs.

That's why i'm searching a workaround, not a crack

 

[Thomas Worth]

Uh ... I don't think Resolve uses the Quicktime API.

Moving QuickTimeH264.component out of /System/Library disables H.264 decoding in Resove. This is a QuickTime decoder. Therefore, it's reasonable to assume Resolve is using QuickTime to decode H.264.

Also, rendering H.264 files imported directly into Resolve display the same characteristics as H.264 files imported into other programs using Apple's H.264 decoder. Apple's decoder produces a unique look that is easily recognized in comparison to other H.264 decoders like MainConcept's.

As I mentioned before, you're welcome to test this yourself if you don't believe me.

My recommendation is to NOT import H.264 footage directly into Resolve until this is fixed. Otherwise, you'll see artifacts like the ones in the attached image (I had to zip it so it wouldn't be automatically recompressed into JPEG upon upload).

 

[Thomas Worth]

Maybe Resolve has an exact copy of FCP7 Prores encoder?

It's possible they've licensed ProRes from Apple and built it into Resolve.

Now they need to license a better H.264 decoder.

 

[Rosario Balistreri]

Moving QuickTimeH264.component out of /System/Library disables H.264 decoding in Resove. This is a QuickTime decoder. Therefore, it's reasonable to assume Resolve is using QuickTime to decode H.264.

Also, rendering H.264 files imported directly into Resolve display the same characteristics as H.264 files imported into other programs using Apple's H.264 decoder. Apple's decoder produces a unique look that is easily recognized in comparison to other H.264 decoders like MainConcept's.

As I mentioned before, you're welcome to test this yourself if you don't believe me.

My recommendation is to NOT import H.264 footage directly into Resolve until this is fixed. Otherwise, you'll see artifacts like the ones in the attached image (I had to zip it so it wouldn't be automatically recompressed into JPEG upon upload).

Thanks for testing!
So 5DtoRGB is a must now and I was mind-prepared to this

Now I'm trying to put off Prores in flavor of Cineform...
I'm so tired of Gamma shifts... Now I've also to do varius LUTs for YouTube, Mac and PC H264, DVDs, BDs and so on...

I'll try surfing on the net

 

[Thomas Worth]

I'm so tired of Gamma shifts... Now I've also to do varius LUTs for YouTube, Mac and PC H264, DVDs, BDs and so on...

You shouldn't have to do this. As long as you keep everything in its native color space (Rec 709), you shouldn't have shifts -- especially coming out of Resolve.

I wouldn't test this with QuickTime plugins in the browser, though. You CAN get shifts with QuickTime depending on how your videos are encoded for delivery. I encode videos I intend to upload to YouTube with high-bitrate H.264. Testing with Flash or VLC beforehand will give you a good idea of what the gamma will look like on other users' systems. Of course, we can never trust QuickTime to show the video properly so there will always be instances where one user sees the video differently on their browser because they're using the QuickTime plugin.

 

[Rosario Balistreri]

It seems that the problem is on YouTube server-side. Newest conversion to WebM could be the problem.
Because the H264 files are correctly viewed on my Mac but after putting them on YouTube they are darker.
I've to do some tests when ASAP...

Thanks for the advice

 

[Thomas Worth]

It seems that the problem is on YouTube server-side. Newest conversion to WebM could be the problem.
Because the H264 files are correctly viewed on my Mac but after putting them on YouTube they are darker.
I've to do some tests when ASAP...

What software are you using to compress to H.264?

And what program are you using to view on the Mac? QuickTime Player? Have you tried viewing the files in VLC? You might try that and see if they look different in VLC vs QuickTime Player.

 

[Rosario Balistreri]

I usually use Compressor 3 with custom H264 bitrate at 24mbits.

When I play the video I open it with "space" and it looks lighter and like FCP, if I open with QP10 it looks darker like on YouTube.
From Davinci it looks like the lighter one...

 

[Alexander Ibrahim]

Moving QuickTimeH264.component out of /System/Library disables H.264 decoding in Resove. This is a QuickTime decoder. Therefore, it's reasonable to assume Resolve is using QuickTime to decode H.264.

Also, rendering H.264 files imported directly into Resolve display the same characteristics as H.264 files imported into other programs using Apple's H.264 decoder. Apple's decoder produces a unique look that is easily recognized in comparison to other H.264 decoders like MainConcept's.

As I mentioned before, you're welcome to test this yourself if you don't believe me.

My recommendation is to NOT import H.264 footage directly into Resolve until this is fixed. Otherwise, you'll see artifacts like the ones in the attached image (I had to zip it so it wouldn't be automatically recompressed into JPEG upon upload).

Well I won't test it myself now ... because its a system that's actually doing production now. I'll take your word for it, that you've tested it yourself.

That is disappointing news.

I suppose I'll keep using 5DtoRGB for now.

Are the Adobe tools using another h.264 decoder? If so I can probably transcode there.