Blackmagic Forum

When collaborating in Resolve 18 we are having major issues with proxies. We often shoot mixed frame rates and conform footage to a single frame rate (primarily for slow motion).

When collaborating using the cloud, we have tried to all share the same proxies, which obviously would be the best workflow (and how we always worked in Premiere team projects). But in Blackmagic, every user that tries to connect to those central proxies has original media and the proxies out of sync. It seems an issue with how Resolve is reading the timecodes of the media.

We have resorted to each user needing to create their own local proxies. But the problem continues, once one editor is finished working on the timeline and hands off to any other editor, now the locally generated proxies do not sync again. So we must generate NEW local proxies any time an editor opens a project. It's ridiculous!

This actually doesn't seem to a specifically a problem with Resolve 18 as we experienced some out of sync proxies even with 16 and 17. But now that Resolve has launched the Cloud specifically for collaborating, the bug is very obvious. It just seems to be a problem with how resolve interprets the timecode for any footage that has used clip attributes to conform to a different frame rate.

I can't be the only one that conforms high frame rate footage, uses proxies, and collaborates with other editors.. but I am surprised I can't find any information on this problem. Am I missing something? Is there some hidden option somewhere that tells Resolve to ignore timecode of the clips and sync at frame zero instead?

On a side note, we can not use Proxy Generator since BM did not include the option to change clip attributes in the app. Seems like a huge oversight.

Hi Chris,

We have the same issue with our proxy workflow.
The only way we can avoid regenerating proxies on each PC is to change the clips' frame rate back to the original, relink proxies and then change the frame rate back to project settings, which is a huge pain and waste of time.
I 100% agree that Proxy Generator needs a feature to set the frame rate for proxy files.

+1 for a resolution to this.

My colleagues and I just signed up for Davinci Cloud accounts and this is a big issue for us.
We need the ability to relink proxies when the playback frame rate has been changed.

+1 for a resolution too!

If any of you is going to NAB, tell them directly! I'm very sure that remote collaboration will be the big thing for BM there.

ckilkus wrote:When collaborating in Resolve 18 we are having major issues with proxies. We often shoot mixed frame rates and conform footage to a single frame rate (primarily for slow motion).

Because changing Clip Attribute speed also changes timecode, it's going to create workflow problems. My advice is: don't do that. Create all the proxies FIRST, then change the attributes afterwards.

Speed changes are often problematic. You might get better conform results if you just did the speed changes as a speed effect on the timeline. That should stay locked in terms of Media Management or a conform. I would approach each speed change as an effect and render it prior to final delivery, and then worry about optimizing the look and so on.

I seem to remember this is a problem with Premiere as well, but I'm not 100% sure.

Well, I'd say if BM is serious about remote collaboration, they need to find a way that at least any changes to Clip Attributes have to be applied from proxies to originals and vice versa.
Speed changes on the timeline should get across anyways.

Is this another example where clip attributes get baked into proxies and then Resolve ignores the clip attributes when using proxies to try and avoid double-application of the attribute?

Yep, seems so. DR should keep attributes as attributes either way, and keep them consistent.
They are supposed to be metadata, even if just internal ones, aren't they?
Something you do in the timeline should be baked in on render, of course. Proxy generation should be a separate process. Generating proxies on the Deliver page is just a kludgy workaround, and there's a good reason why you can't trigger proxy generation from the timeline.

Proxy generation should be blind to attributes. If it were there’d be no problem generating proxies from the timeline and beyond resolution and codec there’d be no difference handling proxies vs sources.

Baking attributes into proxies adds a fatal level of complexity.

I didn't suggest baking attributes, of course not. Just communicating them.
Just one use case: You have shot your originals upside down, maybe hanging low from a support. Now you turn them around and generate proxies. IMHO, those should not be generated with any correction baked in, but they should automatically get the same attributes. That's all we need.

Right now proxy generation bakes in attributes like rotation. If that no longer happened then proxy generation would have no need to know anything about attributes.

I’m guessing you mean the same thing. No need for GENERATION to know about attributes. Of course in displaying the file attributes would be used. The good part is they’d be used in exactly the same way whether using original or proxy files.

Yes, we mean the same thing, Joe.