Can't Change (Certain) Clip Attributes on Proxy Media

Hello,

I've made some proxy files from source originals and unmounted the drive containing the source originals so I am just working with the proxy files. Certain settings in the Clip Attributes page make no change to the proxy file, in particular, pixel aspect ratio and Image Flip/Rotation have no affect on the proxy file. This feels like a bug rather than a desired behaviour.

If you rotate the image before creating the proxy, the proxy will be rotated, but then you can't rotate it back. If the image has had pixel aspect ratio adjusted before creating the proxy, the proxy will revert to square pixel and you can't change it to the desired ratio.

I have tested this on 17.2.2 Studio on Windows 10 and 17.2.2 on macOS Mojave.

EDIT: I've just done another test, which was transcoding out of resolve in the deliver tab, and then linking these files as proxies and I get the same behaviour.

It actually makes sense to me. The Proxy is rendered with those settings baked in.

It actually makes sense to me. The Proxy is rendered with those settings baked in.

Except when it doesn't though, like with the pixel aspect ratio. And rendering with the changes is fine, but you then can't alter it. I see the proxy work flow as a way to be mobile and not have to have the raw with you at all times, and if you can't change the proxies without access to the raw, that seems like a problem.

It’s important to get it right the first time. If you don’t, then you need to re-generate. Pixels don’t change their aspect ratio mid-stream, or over the lifetime of the file.


Sent from my iPad using Tapatalk

It’s important to get it right the first time. If you don’t, then you need to re-generate. Pixels don’t change their aspect ratio mid-stream, or over the lifetime of the file.


Sent from my iPad using Tapatalk

Not entirely sure what you mean. If something is shot cinemascope, even if you flag it as cinemascope in clip attributes, the proxy is created as square pixels. Also, there are situations where you might miss something initially, like a camera needing to being inverted to shoot something due to ground clearance. Once the proxy is created, you can't then flip it in clip attributes. you can flip individual files in the timeline, sure, but if they've shot an entire slate like that, it's better to fix it in the clip attributes.

What you're saying also doesn't work in a proper offline workflow, where you don't necessarily have access to the original files, just the proxies.

Also, if I make a change to a proxy file on the sequence (like needing to squeeze it to get correct pixel aspect ratio) and then render out from the master files, it's going to overcompensate and be double squeezed.

I’ll have to do some testing myself to see if I’m clear on what you mean.

You mention “sequences.” Are you coming from Premiere? I could never get non-square PAR’s to work with proxies there, so maybe there’s a cultural difference.


Sent from my iPad using Tapatalk

I’ll have to do some testing myself to see if I’m clear on what you mean.

You mention “sequences.” Are you coming from Premiere? I could never get non-square PAR’s to work with proxies there, so maybe there’s a cultural difference.


Sent from my iPad using Tapatalk

It's hard to imagine a situation where you wouldn't want your proxies to match the source files. My fix for the moment is transcoding out of resolve, and bringing them into a new project and not linking them to the raw, and then re-conforming at the end, but this seems slightly backwards and not the dreamy offline/online workflow I imagined when they announced proxies.

It would be great to hear from someone at BMD to see if this is in fact a bug to be ironed out or if there is some rationale behind it that I'm missing.

I see the proxy work flow as a way to be mobile

Oooh, no. You can't do this job on a Laptop, so mobile is...just no.

Proxies are a way to ease the playback difficulty on lower spec'd machines. That means the originals are always available.

Not a universal view, I admit. But...it always works.

I see the proxy work flow as a way to be mobile

Oooh, no. You can't do this job on a Laptop, so mobile is...just no.

Proxies are a way to ease the playback difficulty on lower spec'd machines. That means the originals are always available.

Not a universal view, I admit. But...it always works.

Hey Jim,

Offline editing is actually my job! Working with just the proxies is actually the norm in this line of work. Even with an incredibly well spec'd machine, working with multiple streams of 4k+ camera raw isn't feasible. Mobile doesn't just mean laptop, it means being able to move around without need to carry around tb's worth of raw.

I'm seeing the same problem. I'm using a Zcam E2 F6. Shooting an anamorphic project (Vazen full frame 1.8x) using 6k, 5k and 4k. The camera generates it's own proxies which I've imported. My timeline connects to the proxies and plays them back fine. But changing the clip attributes has no effect on the proxies.
Does anyone know of a solution to this?

I'd like to join this thread to report the same issue.

In my case I generated the proxies, then I realised all my clips needed to be rotated 180 degrees. I can change the attribute of the original clip but when proxies are being used, this is not reflected in the playback. If I disable proxies, then the clip is rotated as expected.

Only solution (I know) is to re-render the proxies. I feel it should be corrected.

(Yes, I'll remember to rotate the clips BEFORE I make the proxies next time but that's not the point!)

That would make for a nice feature request in the subforum.
As things are now, you need to apply all Clip Attributes before making proxies.

There’s a FR I entered to change proxies so that nothing is baked in other than the codec and new resolution.

Let me find it, Joe.

edit: Found it: viewtopic.php?f=33&t=196681#p1021435

I tried to find it. Turns out I didn’t write an actual FR. So I guess I will now!

it should be the link I posted on the post before yours

That request is the opposite of what I’m suggesting. It asks to bake MORE attributes into proxies. That way madness lies.

I see - I'm probably misunderstanding things here. Who is saying that attributes should be baked into proxies? I don't think this is what Uli is recommending?

I can’t quite tell for certain what Uli is suggesting - the link he posted to his feature request just points back to the same report - but from his saying

Currently, DR does not check for changes in the Clip Attributes of an original to apply them to externally generated proxies. This way the Proxy Generator is less useful than it could be.

I thought he meant he wanted the external proxy generator to do as the internal one does and check for changes in clip attributes.

More likely he’s suggesting the same thing I’m suggesting but it’s written in (to me) a confusing way.

Well, IMHO, the external proxy generator should copy all Clip Attributes you may have added before using it to the proxy attributes. But I can understand that it was developed to be used only before you bring your footage in, so this was not considered.

Regarding proxies created from within DR, they should always get the Clip Attributes synced with changes on the original or vice versa. Clip Attributes are metadata, they are not baked in before you render. So, they shouldn't be baked in to proxies either.

Clip Attributes are metadata, they are not baked in before you render. So, they shouldn't be baked in to proxies either.

That's my thought exactly. DR is simply not considering that metadata when a proxy is involved at the time being.

I’m still not understanding your point of view Uli. If clip attributes aren’t baked in then why would the proxy generator need to know about them?

OK, I must have been a bit tired already, it was late.

The perfect solution would be if the Proxy Generator knows about them and offers the option to bake them in when you use the "Extract Proxies" function. As the manual describes, that's meant for exchange with others. So, they would probably not like to get proxies which are upside down (think camera hanging from a gimbal), wrong speed or aspect ratio. I admit that things can get complicated, since those proxies should not be used in DR then. You would need to have two kinds of proxies and establish a clean workflow.

In a perfect world, all team members would use DR and proxies would get their Clip Attributes from the project in exchange with the ones of the originals. I'm sure BM would like such a perfect world too

I wasn't aware of that function, Uli, but it would make sense to me that "clip attributes" metadata applied to the original clip is then taken into consideration when exporting Proxies through DR.

I think we are all on the same page here: nothing should be baked into proxies but the clip attributes should be considered across the whole platform, including when exporting/playing proxies.

The problem is that such metadata are not recognised by other NLEs or DAWs, so they need to be baked in for folks outside of DR.

I see - I guess an option to bake those attributes (which would require a re-render I suppose) could be added then?

Option 1: export the files "as is" (that can be simply done by browsing the files though)
Option 2: export with attributes - requires a re-render (what about other attributes, remote grades etc? Maybe have several options to choose from?)
Option 3: export with attributes as metadata (for use within DR)

Number 2 would be just a render as individual files with the effects baked in, set to the size and codec you want. Grades and such don't belong to Clip Attributes.

By definition, proxies are visually equivalent versions of original footage except that the quality may be somewhat degraded. They’re just transcodes of the original footage.

Anything beyond this is not a proxy in anyone but Resolve’s terminology.

So a proxy with the footage flipped is not a proxy - even though Resolve does this.

Footage that’s had more than a transcode applied to it is really a pre-render or render in place. It’s an intermediate output. Like a precomp in after effects.

One of the best things about Proxies vs Optimized Media is you can make them outside of Resolve. Really far outside - as in in-camera or in a recorder. This is only possible if proxies are nothing more than transcodes. Once a project’s metadata is needed they’re no longer self contained in this way.

BMD really needs to get rid of this baking attributes into proxies stuff or much of the benefit of proxies is lost.

I've reported this issue to BMD and I've got a reply saying that this is the intended behaviour (in my case that if I change the "clip attribute" AFTER creating the Proxy, the Proxy does not reflect that).

I will challenge that HOWEVER I was offered a workaround I wasn't aware of: rotate the clips via the INSPECTOR and not the clip attribute. That rotates BOTH the original AND the proxy. And can be applied in bulk.

So that finally opens up the option to make external proxies via a separate system - at least for me.

I thought I'd mention here.

Cheers
Tony

Thanks for telling us this. It’s always been clear to me that Resolve is behaving as designed - however there’s no benefit to the user from this design, there’s an alternate design that doesn’t have these shortcomings and, perhaps worst of all, the only way we find out that BMD has no intention of addressing these shortcomings is by someone with special access “leaking” the information.

This is also an excellent example of where Resolve is more complicated than other NLEs with little or no benefit to the user from the added complexity.

This is also an excellent example of where Resolve is more complicated than other NLEs with little or no benefit to the user from the added complexity.

Even on Avid, we just create all the Proxies manually, apply a temporary LUT (or color management) to get reasonable pictures), key in data burns when the editor wants it, and solve issues like anamorphic/pixel size on our own. It's not that hard. Once all the editing is done (and locked), we just force a relink to the original files and start color correcting. It's been this way for a long, long time.

Complex projects where different cameras use different aspect ratios or sizing have the potential to be a trainwreck, no matter what. The best solution I know is try to avoid that, or at least prepare for it and make a lot of notes so it can be fixed on down the line for final color. We've done projects that mixed 35mm film, 16mm film HD video, 4K video, tiny GoPro cameras, all kinds of stuff, and were eventually able to tame it. But automatic Proxies would not be able to compensate for a mess that big.

The automatic Proxy Generator will work for a lot of simple situations, but it won't work well when there's a big mix of formats and standards.

oh forget about that, the "workaround" doesn't work on "already existing multicam timelines". The inspector on the clip on the media pool doesn't have effect on the displayed image.

But if I add another copy of the very same clip on the very same timeline, then it works.

it's so frustrating.

edit: it does but it has a mind of its own. Sometimes it rotates, sometimes it does not. It looks very broken. I'm reporting this to BMD...

I'm sharing the file with you too - maybe someone has an idea. It's better watched offline.

https://1drv.ms/v/s!AukePwK7XyEPhPAjfUz ... Q?e=r5E0Uf

This whole notion that if there’s a workaround to something not working then there’s no need to fix the issue is… unworkable. The more the user base grows the more it becomes intractable to communicate how to use Resolve. And the more workarounds required - new ones are discovered with great frequency - the harder it is to learn Resolve. I’m amazed so many people here push back against this.

This whole notion that if there’s a workaround to something not working then there’s no need to fix the issue is… unworkable. The more the user base grows the more it becomes intractable to communicate how to use Resolve. And the more workarounds required - new ones are discovered with great frequency - the harder it is to learn Resolve. I’m amazed so many people here push back against this.

I totally agree with you on this, I have come across a number of 'quirks' that I sometimes wonder why they weren't fixed a long time ago.

Consistency is the key in any major software, and so it irritates me when I have to press "D" in the Edit Page to disable a clip, but "CTRL + D" in the colour page to disable a node.

And then to zoom in on a Fusion viewer you scroll your mouse wheel, and yet in the Colour page viewer you do CTRL + scroll wheel....or is it the other way round ?!?!?

And then there's markers / flag colours that are in different orders in the Fairlight Page and the Edit Page, where 's the consistency gone ?!?!?....sorry....I had to let it out...

And then to zoom in on a Fusion viewer you scroll your mouse wheel, and yet in the Colour page viewer you do CTRL + scroll wheel....or is it the other way round ?!?!?

Ahah, I did notice that and it's so annoying!!

BMD has replied to my reply, rotating clips in the inspector is only possible for items in the timeline (actually, it works if the clip is in the preview monitor as well) so the "workaround" does not apply.

The "new" workaround is to create the proxies AFTER Clip Attribute has been changed. Again, it implies some sort of clairvoyance here.
I don't know, it doesn't feel right to me. But hey, I guess I'll have to live with this. They said they'd forward the comment to the team, I mentioned this thread for their reference.

FWIW I have my own workaround, for Mac OS.

I hit "Show in finder" on the problem clip, then open it with quick look (spacebar). In the top right corner, there's a rotate image icon, hitting that will rotate the shot, pretty sure just by changing the metadata but it works. Once finder saves that change, I can usually go back to DV and it will auto update the clip, but if not, I'll use the "Relink proxy" function.

It's a dumb workaround but it does the trick for me. I've also become accustomed to just selecting everything immediately after import and applying a mass attributes update with "0 degrees", since my camera thinks it's smart and flips them from time to time.

You know, I have been thinking the same thing - "would just changing the metadata of the footage fix my problem?"

I need something that works for Windows too but I'm sure there is an app to do that. Thanks.

And then to zoom in on a Fusion viewer you scroll your mouse wheel, and yet in the Colour page viewer you do CTRL + scroll wheel....or is it the other way round ?!?!?

Actually Fusion has being doing it like that way before ever coming to resolve, so for fusion users its the other way around. The color page is wrong. But the change is easy to make in preferences for those who want it differently, so you can choose any modifier or not modifiers and only scroll wheel to zoom in fusion.

You know, I have been thinking the same thing - "would just changing the metadata of the footage fix my problem?"

I need something that works for Windows too but I'm sure there is an app to do that. Thanks.

But they should include the metadata to the clips generated in the Proxy Generator as well... or they do, but just some of it which is even worse. The Color Space of the clip is included (color management works well with proxies), but the image rotation tag is not (R5 c includes image rotation in the .crm, used proxy generator on a different machine before importing the footage in Resolve and the image rotation tag is gone with the proxies). Gotta test also with some anamorphic clips to see what's the behaviour there - oh wait, but this is exactly where the problem lies with the way Resolve handles proxies.

Just testing out the suggested workaround to rotate the proxy clips in Finder on Mac, and this is the best workaround for image rotation problem so far. You can easily select all the proxy clips and right click-quick actions-rotate 90deg left to batch rotate them all, then I just moved them clips to another location and relinked and now works great. Hopefully you find similar for windows.

But they should include the metadata to the clips generated in the Proxy Generator as well... or they do, but just some of it which is even worse.

I don't know what happens, I know it doesn't work
Internal proxy generators do work (BUT won't consider an attribute change done after the proxy was generated) - standalone generator does NOT consider the rotation so it's useless.

BMD says "it's by design". I gave up.

Unfortunately I haven't found anything yet.
"LossLess cut" does work but not in batches. All the apps I tested work via ffmpeg and ffmpeg seems to require to make a copy of the file. In short: It seems that I cannot just change the rotation metadata.

I mean: I can but by writing the file again. And when you have many gigs of files, it's not what you want to do, even in batch

I'll keep searching!

Completely agreed.
Last Thursday I created another batch of proxies (900GB of canon raw footage), this time within Resolve with image orientation applied. However, the proxies again didn't come out with the image orientation applied.

I guess it's due to the fact that I moved our project library on BM Cloud, and then I generated proxies not by right clicking in media pool/Generate Proxy Media, but rather through BM Cloud Storage Syncing settings - which I guess activates their proxy generator in the background, because you can still edit while it generates proxy media but that again doesn't apply all the metadata. "It's by design", yeah right.

And boy am I glad I've got my MacBook to rotate those proxies, by the sound of your batch rotation problems...

I have a Mac Mini which "shares" the SSD with the content.

Maybe I should just plug the SSD on it, rotate the files and then go back to Windows

(Y) That should def do the trick then for this one time.

The same issue. wasting time while changing orentation in the inspector tab. I can see some older topics with the same problem back to 2021. Shame it haven't been improved since.

Another quirk I stumbled upon.

We shot a project on 1.8x anamorphics, and I created my own proxies/transcodes with the original clip dimensions so I can keep those for archive purposes instead of braw files, and kept them in the "Proxy" folder so it relinks automatically.

- A Cam was UMP 12k shot in 8k (desqueezed to 1.33x in camera, then 1.8x in resolve, as UMP doesn't support 1.8x in camera)
- B Cam was BMCC 6k shot in 4k (desqueezed to 1.8x in camera)

After transcoding the B-cam proxies keep the right parameters, so 1.8x desqueeze and work well.
The A-cam proxies revert to 1.33x, but the clip attributes dialogue window says 1.8x. No way to actually desqueeze those proxies properly.

UPDATE:
If I import the same trasncoded UMP clip in Resolve as its own file (so not a braw proxy), it actually desqueezes properly to 1.8 on the import, just like it was set when transcoding the files. I can also set other ratios no problem from the Clip Attributes. BMD?

This is BY DESIGN. It’s a problematic design as you see. But it’s working as they intend it to.