Improve UI behavior when available codecs/settings change

[hoshinolina]

Description

When a codec becomes available or unavailable (e.g. if a plugin is added or removed), make it possible to correct the setting in the UI. Currently, when this happens, it can be impossible to change to a different encoder/setting entirely, leaving the profile broken.

Motivation and Context

I stumbled upon this in the context of #8529, but the fixes apply more generally. If the x264 plugin (which is a separate RPM Fusion package in the Fedora world) is installed, OpenH264 is hidden from the simple encoder settings, but if x264 is the only encoder choice, there's no way to "change" the codec in the combo box, so the codec in the profile config remains stuck at OpenH264 while the UI says the codec is x264. Conversely, if the x264 plugin is removed, the profile becomes invalid and unusable, but there's no way to correct the codec in the simple encoder settings UI if OpenH264 becomes the only option. This also applies to the advanced settings when x264 is removed (the combo box defaults to OpenH264 but it's not evident this can be saved without flipping through the codecs at least once).

In addition, if the recording codec is set to x264 and the plugin is removed, the UI refuses to save settings because the recording codec combo box is unselected. However, if the quality is set to "same as stream", then that setting is actually irrelevant. Fix it so that the error only appears if the quality is not "same as stream" (at which point the combo box clearly prompts the user to select a codec).

Although this change was discovered in the context of #8529, it should apply to other scenarios too with e.g. hardware codecs becoming available or unavailable for whatever reason.

Note: This still requires the user to go through a trip into codec settings when a codec choice is invalidated (recording/streaming will fail to start until this). I think this is better behavior than silently changing settings on startup, since then simply opening OBS with an incomplete install could change the user's profile without their knowledge, and the change would stick after the installation issue is resolved, which is unexpected silent behavior. I think it's better to explicitly tell the user there's a problem with their existing config, and require them to open up the settings, even if the only thing they have to do then is click "apply" to actually commit to the new default.

How Has This Been Tested?

Local build & tested all the scenarios of removing and adding back the x264 plugin.

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.

[Fenrirthviti]

This is a good description of the problem (and definitely something on our radar as an issue worth fixing) but as this is difficult to test on Windows, how exactly does this change the UI flow? The description of the change describes the problem, but not what this solution actually does or how it solves the problem.

[hoshinolina]

Before: If the encoder is unavailable, opening the settings dialog would show another (available) encoder already selected, but the setting cannot be saved ("Apply" is grayed out). After: The "Apply" button is active as soon as you open the settings dialog (indicating that something already changed to fit constraints), and clicking it or OK will set the encoder to the new default (which is already what was visible to the user in the settings pane). The second commit is just a trivial bugfix to stop it from prompting you about an incorrect setting when the setting is hidden and irrelevant. It just resolves a confusing situation. If you want to test this, the easiest way is to just edit the profile config file manually and set any of the encoder settings to an invalid/nonexistent identifier. ~~ Lina

[Warchamp7]

We should use the existing SetInvalidValue method to set the dropdown to the invalid encoder value. That should allow users to change the dropdown value and QueryAllowedToClose should be amended to check that those dropdowns have valid values.