Does anybody have the same problem and/or a possible solution:
Imported clips from original c300 MKII mxf files via Canon FCP plugin. When stopping playback the levels of my C300 mkII Canon log2/cine-gamut footage jumps up a little and then down again.
the levels jump up a little when starting skimming and down again when stop skimming
It is the same brightness shift in both scenarios.
Doesn't matter if there is, or is not, a LUT or effects applied, always does it.
The interesting bit is if I open one of the original MXF clips in Compressor and apply a ProRes transcode to it, I see the same brightness shift in the preview window on the right result side.
Something has changed how XF-AVC footage is interpreted. I just don't know if it is a bug, a bad upgrade to 10.4.9 (though I have deleted pref, deleted re-installed FCP, Motion and Compressor) or only happens in Mojave which I'm still on.
Addition: I just noticed that FCP allows now for XF-AVC log footage to be optimised, meaning you can select the clips and choose Transcode>Optimised. This was not possible before!
AND after you do this the brightness jump is gone because FCP now uses the ProRes version which doesn't have the problem.
It seems that Apple changed the way XF-AVC log footage is processed, but still don't understand why? Would be nice to get a word from Apple or Canon on this.
I experimented with workarounds and I worked out 3 options:
Ignore the brightness jump because the exports use the correct values.
Optimise all original clips - doubles storage so not ideal and a short term solution.
Transcode all to Prores using compressor and then relink to those and delete the XF-AVC Quicktime files.
Will be interesting to see how this issue develops. Might be one that never gets explained and you just learn how to live with it
...original c300 MKII mxf files...When stopping playback the levels of my C300 mkII Canon log2/cine-gamut footage jumps up a little and then down again...
Using the file that soundbite uploaded, I see the problem in 10.4.9 on Catalina, not just Mojave. It does not happen with 10.4.6 or 10.4.8. It happens whether clip is imported using "leave files in place" or copied to library. I have Apple Pro Video Formats 2.1.2 installed.
It does not happen if the timeline is rendered to cache, either manually via CTRL+R or automatically via background render.
However that is based on testing with soundbite's clip which I think is either a capture or a rendered Quicktime file -- not the original camera MXF. Why the behavior would persist in a captured or re-encoded file, I have no idea.
Using the media inspection tool Invisor shows several metadata fields are flagged with "unknown kind of value". Can anyone upload a short original C300 MXF file? If that is a tree-oriented format we'd need the ZIP'd folder tree holding that short clip, in order to ensure all sidecar metadata was present.
Fortunately I have a card with 1 35s clip on it from yesterday which i have zipped up from the root CONTENTS and dropped in the same folder. It's about 1.7gb..
Thanks for doing that. I downloaded and tested the original MXF and confirm it's a bug unique to 10.4.9. It happens whether imported to library or with "leave files in place". Using color space override in Inspector>Settings does not help. In some previous problems that was a workaround.
A possible workaround is externally re-wrapping the material using EditReady2, then importing with "leave files in place". I tested that and it seems to work. Re-wrap is very fast since it's not transcoding. This also rolls up all the metadata into the single video file, enabling proper import with "leave files in place". Aside from this problem, that's a common workflow for certain tree-oriented media: www.divergentmedia.com/editready
Another workaround is fully render the timeline to cache, either via CTRL+R or background rendering. Obviously it will only render the timeline if there's some effect on the material, but for log material there's always a color effect of some kind.
It also doesn't happen if using ProRes proxies, but it happens if using H264 proxies. However it's not burned into the H264 proxies because if those are copied to a proxy-only library, it doesn't happen there.
It is fixed thanks but it transpires that the true state of the colour grade was actually the one showing when playing or adjusting (ie the lighter more washed out state) not the darker state when static.
As the static grade was the one that seemed to export it was reasonable to assume the opposite so now I have to go back and regrade a whole bunch of clips from scratch.