rtmp-services: Add multitrack video configuration support

[palana]

Description

These changes are prerequisites for the upcoming multitrack video/Enhanced Broadcasting support, and add support for eRTMP multitrack video configuration URL (and related disclaimers) to rtmp-services (and libobs)

Motivation and Context

Twitch/Amazon IVS uses server side configuration for eRTMP Enhanced Broadcasting/multitrack video stream configuration, so users don't have to manually configure renditions being sent

ertmp_configuration_url (and ertmp_configuration_name) are exposed in the service json configuration to allow other services to adopt the same configuration mechanism without additional code changes

How Has This Been Tested?

This is in use in the Twitch Enhanced Broadcasting Beta

Types of changes

• New feature (non-breaking change which adds functionality)

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.

[RytoEX]

I am curious about the locale string here and if we can remove the service-specific one. No other notes/nits at this time.

[derrod]

Also would echo the sentiment that calling it ertmp is misleading as its not part of that spec, and is in theory protocol-agnostic, e.g. it could be used with MoQ in the future.

[murillo128]

Th PR title is misleading and I think some of the comments on the code.

While the intention may be to add configure multitrack video, this PR and the code in only implements setting a custom configuration URL for an RTMP provider .

Currently these seems locked to twitch and only configuring multitrack video but, if merged, I think this should be generalized (and "standarized") so it doesn't mention twitch and we allow to configure other stuff different than multitrack video.

[Lain-B]

One of these days we'll have to work on that big service update to make things easier for services to share features as well as to make things easier for individual services to customize (and get that RFC through), but this has my approval

[RytoEX]

Th PR title is misleading and I think some of the comments on the code.

While the intention may be to add configure multitrack video, this PR and the code in only implements setting a custom configuration URL for an RTMP provider .

Currently these seems locked to twitch and only configuring multitrack video but, if merged, I think this should be generalized (and "standarized") so it doesn't mention twitch and we allow to configure other stuff different than multitrack video.

I've adjusted the PR title.

Twitch is contributing the code, so it aligns with their implementation. That said, there is nothing stopping other platforms/providers from implementing this. See Twitch's Help Article on Multiple Encodes, specifically:

If you’re a third-party video tool or platform and want help, please get in touch.

None of the actual code mentions Twitch anymore. The only places that do are examples in the JSON schema and the strings in the services.json file in Twitch's entry, where they are appropriate.

@palana Please squash the commits here.

[palana]

@palana Please squash the commits here.

@RytoEX: done (also rebased on master)

[RytoEX]

@palana Please see @Warchamp7 's review comment on #10634.

[RytoEX]

Commit message nit:

rtmp-services: Allow loading Multitrack Video configuration from services.json

This commit message subject is too long.

Instead, use this:

rtmp-services: Allow loading Multitrack Video config from JSON

Add support for loading Multitrack Video configuration data from
services.json.

[palana]

Commit message nit:

rtmp-services: Allow loading Multitrack Video configuration from services.json

This commit message subject is too long.

Instead, use this:

rtmp-services: Allow loading Multitrack Video config from JSON

Add support for loading Multitrack Video configuration data from
services.json.

@RytoEX: done

[RytoEX]

Looks good to me.