Fix: Build Compatibility Issues in XCode 26.4 with macOS plugins

[andrewsoncha]

Description

Adds explicit type conversion within mac plugins:

• mac-capture
• mac-syphon
• mac-videotoolbox
• mac-virtualcam
  With the newest XCode 26.4 version, the compiler raises an error when there is an implicit type conversion between types with different sizes. Because of this, the code for the above plugins raise a compile error when compiled using the latest Apple Clang 21.0 and XCode 26.4.
  While there are many reasons for why doing type conversion between types with different sizes may be bad, the cases where they are used within the above plugins are well within range of the smaller type or are simple enum values.

Motivation and Context

The current obs-studio master branch fails to build with Apple Clang 21.0 and XCode 26.4 due to compile errors. The error has been reproduced by another member of the community (@WizardCM) The compile errors all come from implicit conversion of types within the source code of the the above mentioned plugins.

How Has This Been Tested?

Used Cmake to build the macos preset and used Xcode to compile. More specifically, followed the instructions here.
Used

cmake --preset macos

to generate a xcode project and used

xcodebuild -configuration Debug -scheme obs-studio -parallelizeTargets -destination "generic/platform=macOS,name=Any Mac"

to build the XCode Project and confirmed that there were no compile errors with the OBS source code.

While after applying the changes there are no more compile/build errors within the OBS source code, there is now a build error with the included qt library file, more specifically the obs-studio/.deps/obs-deps-qt6-2025-08-23-universal/lib/QtCore.framework/Headers/qyieldcpu.h file.
The error message is as follows:

While I was able to find this forum thread and apply changes listed there to the qyieldcpu.h and have it finally build without error, I was not able to include the changes to the included qt library in the pull request.

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[jcm93]

If I'm not mistaken, you should also remove the changes to obs-websocket in your commits, since those changes have already landed with 3a9cf4a.

[PatTheMav]

Just to confirm, the "The code has been tested" checkbox is set, so I assume all the changed paths have been confirmed to produce the same results as before?

[andrewsoncha]

Yes. The code builds without any compile errors and the functionality related to macOS in the resulting program still functions the same as before.

[PatTheMav]

Yes. The code builds without any compile errors and the functionality related to macOS in the resulting program still functions the same as before.

Sorry, I should've been more clear in my ask. Can you confirm that, e.g.:

• The nanosecond timestamp provided by AudioConvertHostTimeToNanos indeed yields the same number as the old code?
• The values passed to build_sprite_rect in syphon.m are identical?
• The numbers passed as MaxKeyFrameInterval and ExpectedFrameRate in encoder.c have numerically the same value (so what was 30.0 should now be 30), did you test this with uncommon fractional frame rates (e.g. 30/7).

It'd not be the end of the world if outcomes change, but we'd need to know if things have potentially changed to figure out if those are desirable or undesirable changes.

[andrewsoncha]

Upon testing, yes the values passed are the exact same from before and after the change.

• The nanosecond timestamp provided by the AudioConvertHostTimeToNanos in mac-audio.c is the exact same.
• The values passed to build_sprite_rect in syphon.m are identical.
• In encoder.c, when given a fractional frame rate in the settings that do not divide neatly (such as 30/7), the exact floating point values of the expected_framerate are round down to an integer in actual_framerate (4.78... => 4). The functionality of the VideoToolbox encoder is not affected by this.
• In other places where changes have been made (for example the virtualcam plugin), the values are the same.

[PatTheMav]

Thank you. I don't have the capability to test the DAL-related changes personally and I'd also rather have some one confirm my suggested changes rather than just accept them as "correct" outright.