when exporting to mxf op1a xdcam, i still get these weird artifacts here and there, mostly in the highlights. right now i work with davinci color management (DWG), HD, but it also happens with regular davinci yrgb projects.
blocks.JPG (11.75 KiB) Viewed 2281 times
this is problematic, and frustrating, as this format is the broadcast standard.
I'm really on the verge of something, don't know what. but a render should just be reliable. no matter what. this has been happening way too often. i'm not talking about one system, it happens all over the office. mostly windows, has to be said. but it is really getting on my nerves now.
Last edited by Rick van den Berg on Wed Mar 31, 2021 5:44 pm, edited 1 time in total.
I never use the format myself. I don't recall anyone ever reporting that kind of glitch on RED clips. I've never seen it myself using cDNG, BRAW or ProRes. Only when going from H.264 to H.264. Change either from or to, and it works for me.
My Biases:
You NEED training. You NEED a desktop. You NEED a calibrated (non-computer) display.
Hi We are seeing this as well. When exporting to mxf op1 xdcam on windows. Resolve 17.1.1 This is critical! We are about to move our whole facility to 17 and must have the ability to deliver this format. I remember something very similarly happened on V16.1.1 if I recall correctly. And they fixed it in the next version.
Hi, We did some more exploring, apparently this bug is in Resolve 17.1.1 We did some tests and we found that V17.0 does not create these artefacts. But With 17.1.1 it is consistent. Since this codec if required for delivery to many broadcasters this issue is critical.
In the link below attached logs from V17.1.1 and from 17.0 right after export. Also there is a mxf sample with the artifacts and a NFO file.
We contacted support few days ago and got no answer.
Please address this problem BMD team. We really want to move on to the new and awesome V17.
I got "blocky" artifacts (not like these, but still blocks) when I was rendering mp4 file with h.264... With "Key Frames" on automatic. I never leave it on auto and put it on 1 (behaves like 0), and no problems since.
It's totally out of my league, but could it be the same "kind" of problem with Key Frames too (with the option not accessible from the export menu but still behaving like it's on "auto" or something like this)?
We have the same problem here, lot's of artefac, glitches and weird motion effect. It appends only with a MXF OP1a with an xdcam setting. It is really critical because all broadcasters ask for this format.
For now, we use Media Composer for deliveries, that is a shame
I compared the new MXF file from 17.1.1 with the old MXF file from 17.0 and I found one difference that might help solve the problem. The export settings was the same in both files "MXF OP1A" "XDCAM MPEG2".
Interesting. We got a reply from BM support. They were managed to replicate the issue and it moved to the development department. Hopefully it will be fixed in the next update.
mac studio m1 ultra, 17.4, also still happening. Yes i can render to another format first and decode it with other software, but how am i supposed to trust any render if this keeps happening? Color managed, YRGB, and it happens with all kinds of footage. i dont think this is something innocent as it is still the industry standard for delivery. It's also really sneaky as it mostly appears for just 1 frame so it's easy to overlook it. And it's not a specific system issue since i literally used 20 different ones lately. this is really bad....
Issue still happens on 17.4.6 We made several tests it only happens on M1 machines (Monterrey). We tested on Windows 11 (intel) and Macbooks (intel) and the issue did NOT happened. It only creates artifacts when we have graphics (external - created in After effects etc), it does not happen with live footage from any of the cameras we have. Any news about this? It's frustrating if we really have to go to Media Encoder for the final delivery