Custom configuration for multitrack-enabled services is only supposed
to be available for the "rtmp_custom" service type, as that's also
the condition for the corresponding text input to become visible in the
settings dialog.
When a user switches their desired service from the custom service back
to another service that also supports multitrack, the custom service
configuration is still present and will be applied even though it
should only be effective for the custom service.
This change makes the simple decision to ignore any available custom
multitrack configuration if the service is not "rtmp_custom" and
requires an "auto_config_url" to be available in that case. Otherwise
the "rtmp_custom" service requires an "custom_config" to be available.
That way the implementation reflects the behavior of the settings dialog
and will not lead to the present unexpected behavior, including:
* The custom configuration is "merged" with the config ID provided
via the "auto_config_url".
* A non-custom service might fail to configure because the custom config
is applied and might be missing required fields.
* A non-custom service might succeed to configure because the custom
config is applied and has all required fields, but the service was
meant for an entirely different service.
Additionally the unused "MultitrackVideoDeveloperModeEnabled" function
was removed. For simplicity's sake, all legacy code paths that allowed
interference or custom overrides with the service configuration for
established services are removed.
If such functionality is still desired, it needs to be reimplemented in
a service-agnostic way, taking the possibility of other multitrack-
capable services into account.
When using custom RTMP output with a JSON config that omits
encoder settings, settings.dump() produces "null" which
obs_data_create_from_json cannot parse. Fall back to
obs_data_create() for null/non-object settings so encoders
use their defaults.
Additionally, when bitrate_interpolation_points is absent,
the code unconditionally set interpolation_table_data as
empty arrays. This caused build_dbr_interpolation_table to
wipe the default linear table, leaving DBR enabled but
unable to adjust bitrates during congestion. Only set the
interpolation data when all encoders provide it, otherwise
fall back to the default linear 0-to-max interpolation.
The bitrate interpolation points are sent in JSON configuration and
need to be forwarded to `create_video_encoders()`. Also remove the
`HandleIncompatibleSettings()` handler because there are no longer any
incompatible settings.
This removes the need to provide an undocumented launch argument to
enable custom RTMP service configurations to use multitrack encoding
and also provide a custom configuration.
"Enable network optimizations" in the Advanced Settings is referred to
as `NewSocketLoop` in the code. This feature was incompatible with
multitrack video but now works properly. Remove it from the
incompatible settings check.
VAAPI encoders deviate from other encoders (e.g. AMF, NVENC) with
the "profile" setting being an integer instead of a string. With
enhanced broadcasting, "profile" is signalled as a string. Convert
the string-based profile to the appropriate integer-based profile
for VAAPI encoders as a workaround, until VAAPI supports string-based
"profile" (if ever).
