- Posts: 668
- Joined: Wed Nov 04, 2015 7:43 pm
Thu Jan 21, 2021 7:30 pm
Got some BRAW from an Ursa Mini Pro G2.
Trying to render out some dailies to DNxHR LB in MXF OP1a container, with just one CST node, and a few data burn-ins.
The shooter indicated that they noticed for some of their overcranked shots, the camera had displayed a "dropped frames" warning.
When Resolve gets to such clips, it throws an error message of the form: "The clip name-of-clip.braw could not be decoded correctly. Please check if the clip is still available on the drive."
It's definitely on the drive. OK, well, so in 16.1, we got "Support for a preference to stop renders when a frame or clip cannot be processed." Unchecking that box in User Preferences doesn't really let Resolve skip the dropped frame; it doesn't throw the error, but the renders just drop to 0 fps and the ETA for the job increases indefinitely.
OK, so next I try generating optimized media for all the clips to be rendered, to DNxHR HQX in native format. Overkill for quality, but I had the disk space to do it. The optimized media is generated fine, but even checking "Use optimized media" for the renders still has the renders stop in the same way. So I trash all of the optimized media.
What finally worked was caching the Color page output to DNxHR HQX and "using render cached images."
I'm guessing the checkbox in User Preferences is supposed to let Resolve steamroller over dropped frames, but it's useless if it just goes to 0 fps.
This was occurring on:
Didn't test in Resolve 17 yet, but curious as to whether this was definitively addressed in 17, or if there's a 16.2.9 due out that could address this before the golden master of 17.
Trying to render out some dailies to DNxHR LB in MXF OP1a container, with just one CST node, and a few data burn-ins.
The shooter indicated that they noticed for some of their overcranked shots, the camera had displayed a "dropped frames" warning.
When Resolve gets to such clips, it throws an error message of the form: "The clip name-of-clip.braw could not be decoded correctly. Please check if the clip is still available on the drive."
It's definitely on the drive. OK, well, so in 16.1, we got "Support for a preference to stop renders when a frame or clip cannot be processed." Unchecking that box in User Preferences doesn't really let Resolve skip the dropped frame; it doesn't throw the error, but the renders just drop to 0 fps and the ETA for the job increases indefinitely.
OK, so next I try generating optimized media for all the clips to be rendered, to DNxHR HQX in native format. Overkill for quality, but I had the disk space to do it. The optimized media is generated fine, but even checking "Use optimized media" for the renders still has the renders stop in the same way. So I trash all of the optimized media.
What finally worked was caching the Color page output to DNxHR HQX and "using render cached images."
I'm guessing the checkbox in User Preferences is supposed to let Resolve steamroller over dropped frames, but it's useless if it just goes to 0 fps.
This was occurring on:
- DaVinci Resolve Studio 16.2.8.005
- CentOS Linux 7.9.2009 (Core)
- HP Z8 G4
- 1x Intel® Xeon® Gold 6136
- 48 GB (6x8 GB) DDR4-2666 ECC Registered RAM
- 1x GeForce GTX 1080 Ti
- NVIDIA driver 450.80.02
Didn't test in Resolve 17 yet, but curious as to whether this was definitively addressed in 17, or if there's a 16.2.9 due out that could address this before the golden master of 17.
https://www.sethgoldin.com