Enabling Hardware Decoding Causes Media Source to Freeze and Crash OBS on Exit (Intel Mac) · Issue #7958 · obsproject/obs-studio (original) (raw)
When testing the bug on an Apple Silicon (M2) Mac, there was no crash. Switching to an Intel Mac and taking the same steps to reproduce the bug does result in a crash after starting and stopping recording. Upon further inspection of the OBS Studio Log, a line mentions that "CBR support for VideoToolbox encoder requires Apple Silicon. Will use ABR instead." However, in the lines under, rate_control is set to CBR in the [VideoToolbox advanced_video_stream: 'h264']: settings, and CBR is set to on in the [CoreAudio AAC: 'Track1']: settings. Changing the rate_control variable in the encoder.c file leads to a change in behavior of the crash: the app no longer crashes after starting and stopping recording. Instead, the app freezes when exiting, and the user must force quit. Given the above statements, the bug is potentially connected to the fact that on Intel Macs, CBR is still being used rather than an alternative encoding method.
By default, selecting CBR in the VideoToolbox encoder results in this path:
| if (strcmp(rate_control, "CBR") == 0) { |
|---|
| compressionPropertyKey = |
| kVTCompressionPropertyKey_AverageBitRate; |
| can_limit_bitrate = true; |
That is ABR. You can see that the properties set are identical to if the user had explicitly selected ABR.
| } else if (strcmp(rate_control, "ABR") == 0) { |
|---|
| compressionPropertyKey = |
| kVTCompressionPropertyKey_AverageBitRate; |
| can_limit_bitrate = true; |
If on macOS 13+ and on Apple Silicon, this path runs:
| if (__builtin_available(macOS 13.0, *)) { |
|---|
| #if __MAC_OS_X_VERSION_MAX_ALLOWED >= 130000 |
| #ifdef __aarch64__ |
| if (true) { |
| #else |
| if (os_get_emulation_status() == true) { |
| #endif |
| compressionPropertyKey = |
| kVTCompressionPropertyKey_ConstantBitRate; |
| can_limit_bitrate = false; |
That is CBR.
We simply don't change the logged value of rate_control.
That said, the Steps To Reproduce do not mention recording as a required step to crash, so I do not see how this is related.