How do I prevent a crash when interacting with Blu-Ray videos?

I have a new M1 Pro Mac and I installed ffmpeg using brew. I also have a Blu-Ray ISO (contains .m2ts files) on standby to be converted to .mkv.

Previously on a Intel mac, I used this command and it worked fine, shrinking the size of the original file by a lot:

ffmpeg -i file.m2ts -c:v copy -crf 28 -c:a flac ~/desktop/mynew.mkv

When I do this on my M1; where I expect the 'encoding' to be faster, I get an astounding KERNEL PANIC!

I'm pretty sure ffmpeg isn't corrupted. I used homebrew to install it on macOS 12.0.1 (21A559). The same command with a mp4 in place (test.m2ts -> test.mp4) does not crash. Performing cp on said .m2ts file (cp test.m2ts ~/desktop/a.m2ts) causes a panic. I have discovered that the problem is how each computer handles the .m2ts file. Same file on Intel and M1, except it causes a crash on M1.

So, what can I do in this situation? Do I wait for another Monterey update to fix this? I've also read that playing an HDR video causes a panic, however playing a Blu-Ray disc in VLC causes no crash.

For those interested in the Panic Log, here is a pastebin link of a crash caused by FFMPEG: https://pastebin.com/f1gemPQ2

and here is a crash with symbolication enabled, but caused by me OPENING the folder with m2ts: https://paste.ee/p/n65io

Solution 1:

"panicString" : "panic(cpu 3 caller 0xfffffe002580c9e4): vm_object_iopl_request: missing/bad page in kernel object @vm_pageout.c:9356

From your initial panic report, it seems that you are hitting a synchronous panic during a request to the virtual memory subsystem to create a new I/O universal page list. This, alone, doesn't tell us enough. We need to gather further information to get nearer to the root cause.

Zooming out for a moment: You are clearly encountering a bug in macOS because – by definition and design! – it must be impossible for an unprivileged user to induce a kernel panic, especially one with 100% reproducibility like this. This bug is ultimately Apple's fault. Without additional debugging (which requires custom tools and access to Apple's proprietary source code), you are unlikely to determine root cause and are guaranteed to not be able to effect a true fix to the underlying issue (which would require making a change to xnu and/or other codebases). This is not surprising, as both Monterey and the M1 Pro are new and there are often bugs at release time.

This means that, for now, your best bet is to

1. Gather as much information as you can,
2. Report the bug to Apple with all of the information from #1, and
3. Try to find a short-term workaround while Apple investigates and fixes this bug.

The first step in gathering more information is to make your panic report more useful. This means two things:

• Don't omit the list of loaded KEXTs (or any other information) from your report; every line in a panic report was intentionally put in because it can contain an important and subtle clue about the root cause.
• We need to collect a new panic report with kernel symbolication enabled so that the backtrace can tell us what call chain led to the VM panic.

To enable symbolication:

1. Run the following Terminal command:

   sudo nvram boot-args="keepsyms=1"

   Make sure to copy-paste this so that you're entering straight quotes rather than curly/“smart” quotes. (If you get a general error, you will first need to disable System Integrity Protection. You can re-enable it after you're done with this investigation.)

2. Reboot your machine. The next time this panic occurs, your report will have a symbolicated backtrace. Please amend your question with a new link to it.