RFC 39: Service overhaul

[tytan652]

This is made to allow people that want to view the implementation through the PR review system. The draft state has no meaning besides preventing the merge button to exist.

Description

This PR is related to obsproject/rfcs#39, it does not include:

• changes about output settings which replace network settings
• CI replacement for the services JSON checks

This PR overhaul services to replace the unique rtmp-common/rtmp-custom combo by a service per streaming services and one for custom (and also internal service per protocol).

This PR provides:

• Move dock state to profile (required for service integrations plugin)
  • Replacement of UI: Work around Qt dock restore crash obsproject/obs-studio#8135
• Add to services the API to indicate if it use "1 audio track"/"1 track + 1 archive track"/"multiple audio track"
• Move service integration outside of the UI as plugins (obs-restream, obs-twitch and obs-youtube)
  • The UUID system in those plugins is mostly for future-proofing
  • Note that Browser docks were already quite crash-prone on Linux if you test on it
• Add API in Services API to enabled multi-protocol per service support and avoid "H264 only" API.
• Deprecated APIs that are too much "H264 only"
• Add bandwidth test related API in the Services API
• Add a broadcast flow API in the frontend API for service like YouTube and third-parties
• Add obs-browser related function in the frontend API
• Migrate old rtmp-common/rtmp-custom to the new services in a new file
• Add CI to keep obs-services JSON parser and its JSON schema aligned

If I forgot to mention something that you think is necessary, tell me.

Twitch with integration:

YouTube with integration:

Custom service:

Motivation and Context

How Has This Been Tested?

Types of changes

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

• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (a change to documentation pages)

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 but it needs to be tested by more people than myself because it's big.
• All commit messages are properly formatted and commits squashed where appropriate. (Tell me if think there is more to squash)
• I have included updates to all appropriate documentation.

[DatCaptainHorse]

Thought I'd do some quick tests as this looks interesting 🙂
I can take a look at the new Service API and try making a plugin for Neighy, if that's more helpful as this is quite short 😅

Clean install from CI, ran in portable mode.
UI seems to work without issues from my usage, below is a small table of streaming protocols I tried
✅ - Didn't spot issues
➖ - Protocol not supported by service
❌ - Something broke

Streaming	WHIP	RTMP	RTMPS	Notes
Neighy (Custom...)	✅	➖	➖	None
Twitch	✅	✅	✅	Twitch WHIP URL (1)

Note references:

1. WHIP ingest for Twitch

Update: Found a tiny bug, with "Override Service Settings" enabled, opening settings brings up the warning popup each time.

Update 2: Did a quick Neighy service using the Service API, no real issues encountered, below is a screenshot of added service 🙂

• Only "issue" was the "maximum bitrate" used in Twitch service, I referenced that service and found out it just forces the encoder bitrate, I feel that should limit the upper value instead of setting the bitrate forcefully?

[tytan652]

• Only "issue" was the "maximum bitrate" used in Twitch service, I referenced that service and found out it just forces the encoder bitrate, I feel that should limit the upper value instead of setting the bitrate forcefully?

Thanks for the update, note if you edit a message I'm not notified.

This behavior is not introduce by neither the RFC or the implementation.
Around this feature, I only replaced "H264 only" functions.

For the "Update 2", I will fix that when I can.