mac-avcapture: Use fallback frame rate by default for new devices #12749
+17
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Enables the video capture and capture card sources to automatically select an initial fallback framerate when a device is selected.
Motivation and Context
When a new device is selected, a best-possible frame rate is chosen for the initial configuration of the device. This has to be set in the source settings, as those are the "source of truth" for the properties and the device configuration.
The object has to be created explicitly first before setting the frame rate value. The source then has to be updated explicitly as well to ensure that the change will be picked up by the next iteration of the render thread to "tick" the source and thus make it configure a capture session with the fallback framerate set.
Ensures that a "good-enough" setup is used immediately and users can see that their chosen capture device is actually "working".
Note
Due to a bug with the frame rate property code, this will also make the property widget automatically switch the frame rate selection to "rational" mode.
The root cause for this is that the specific values for numerator and denominator used by CoreMedia do not match the values used by OBS (even though they effectively both represent the same frame interval), and it only does a naive numerical comparison of both values.
This will have to be fixed separately in the associated shared property UI code.
How Has This Been Tested?
Tested on macOS 26 with capture card source and video capture source:
Types of changes
Checklist: