There is an issue whereby duplicated or black frames caused by decode failures will cause Compressor to show the RequestCVPixelBufferForFrame error. The same input file in FCP will cause the export to abort, but no error is given.
One scenario I'm investigating is apparently caused when using Resolve Studio to transcode BRAW to ProRes on an M1 Ultra Mac Studio. It might also be caused in other scenarios involving different hardware and software.
In the cases I've examined, it manifests as duplicated or black frames in a ProRes input file. If you set FCP Settings>General>Time Display to "Frames", then go to that approximate location in the timeline and play it for about +/- 15 sec around that point, you will see that problem.
In this particular case, the problem is not caused by FCP or Compressor, but by whatever camera or application that produced the file. The source file is damaged, and the error is just how Compressor reacts to that.
So there is the side where the damaged file is *produced* (Resolve, camera, utility, etc) and the side where the file is *read* (FCP, Compressor, etc). In my tests thus far, the production of the damaged file seems limited to BRAW and Resolve Studio 18.6x on M1 Ultra. There is a random nature to it, and it may happen once per 15 minutes. or 3-4 times every 5 min. However, there are likely various possible causes of an internally malformed video file.
In general, there is no real fixable bug in FCP or Compressor -- the input file is damaged. If it's just a few frames, you may be able to edit the source file and then re-import the media file. A good way to edit those without re-encoding or otherwise altering the file is using the CMD+Y (split) mode of Quicktime Player. See the available documentation and video tutorials about that.
But once that damaged spot is in the input file, Compressor will fail at that same point every time. With FCP it's harder to tell since in my case it doesn't throw an error, just prematurely halts the export.
It is possible to view the errors in more detail by using the MacOS terminal "log show" command. However, this produces lots of output and is best viewed with a purpose-built text editor like BBEdit.
E.g, if you suspect Compressor will hit the error, have this command ready to run in terminal, and test it beforehand. Then, the moment the error happens, quickly run this command and inspect the output using BBEdit, etc. It exports the previous 60 seconds of all system log messages to an output file.
sudo log show --last 60s > ~/Documents/LogShow60s_OutputFile.txt
Search for portions of these errors. The other ones will be grouped nearby. They imply the ProRes hardware accelerator was trying to read a frame, and it apparently hung, likely due to the damaged input file.
"cannot be rendered"
"kernel: (AppleProResHW) ERROR: AppleProResHW hangRecovery(): TLimit reports back 0 outstanding"
"ProMSRendererTool: (ProCore) An error was generated when rendering the frame"
