Add RFC: Service Overhaul

[tytan652]

I'm sorry to have stupidly pushed a PR about this suddenly without talking about it with you. So now I tried to write this RFC, it's not perfect, but we are here to discuss about it.

This RFC is now split into two RFCs. They are both quite dependent of each other.

RFC 39: Service Overhaul

Summary

• Highly dependent of RFC 45
• Can potentially became dependent of RFC 47
• Make OBS able to accept third-party service plugins
• Attribute a id for each services rather than a common one
• A service can be provided with multiple protocols
• Separate Twitch, Restream and YouTube integration and make them plugins

Motivation and Context

With those changes, developer will be able to create third-party service plugins. And also service integrations will be separated as plugins.

Link to RFC

[henke37]

Services kinda suck in OBS. They can't setup outputs directly. They can't offer extra features such as the RPC of rtmp. In fact, rtmp doesn't even have a formal password/key system! Each service should be able to do its own rtmp setup as desired.

I hope that this redesign helps combat this problem.

Another aspect that is missing is services being able to pick which server to use given certain conditions.

[tytan652]

The plugin obs-services will mainly register services which uses stream key.

obs-services2 is meant to be used to implement services with specific behavior, right now there is Dacast, and many one with ingest.

Edit: Also there is also the ability to create and use third-party service plugin. Which can help for really specific case. Edit2: They can sorta set up output with recommended settings stuff

[henke37]

"Sorta set up" isn't good enough for me. I'd like the service to be an output factory, taking control from centralized code for maximum control over the output.

[tytan652]

They can't offer extra features such as the RPC of rtmp. In fact, rtmp doesn't even have a formal password/key system! Each service should be able to do its own rtmp setup as desired.

• RPC falls under obs-outputs RTMP implementation, not services. Please don't mix up outputs with services.

• I don't know if obs-outputs or even stream services follow the RTMP specification. But if it's not in the spec, in my opinion there is no "obligation" to implement it.

• I don't know when the team decided to need a "representative" from the stream services when it comes to make PR with purpose to add a services. But there was a period where they were not put by "representatives".

• But if they really needed to implement it a certain way they were free to push a PR or ask for an addition of a mechanism to add third-party plugins if they don't want to be stuck with OBS release cycle.

[henke37]

Correct, RPC in RTMP would be a feature of the output plugin. But the service should be able of encapsulating it in the form of a nice usable api. Which includes providing the login.

[tytan652]

They are already usename and password in the service API, I think they are just not used except for Dacast and Custom services. But I don't know if RPC is implemented.

[henke37]

RPC is not implemented in the rtmp client that obs uses. At least not in a good reusable way. I'm honestly more concerned about websocket based apis and such. It'd be very nice if obs could do stuff like subscriber alerts without the aid of 3rd party websites.

[tytan652]

It'd be very nice if obs could do stuff like subscriber alerts without the aid of 3rd party websites.

Not implemented imperatively in OBS, but in a plugin meant to supply a complete integration of the stream service. I think those type of things, could be one of the use case of the possibility to add a third-party service plugin by the user.

[tytan652]

Update: This RFC draft is split into two RFCs. I put them in the same PR because they are dependent of each other. If you want me to separate them in two PR tell me.

PS: It's also easier to work on both of them at the same time.

[tytan652]

The RFC 38 is quite well proven with a try of implementation of the API and not the UI logic for now here.

Right now the only visible benefit is services not shown if FTL or RTMPS are not built with OBS.

I don't make it a PR for because it needs discussion before making it.

[tytan652]

Since https://github.com/obsproject/obs-studio/pull/5047 is merged I can really begin the phase 4 after making some rebase.

[jp9000]

My apologies for the trouble there. Hopefully we can move things forward more easily now that it's merged.

[tytan652]

Update about phases:

• Phase 1 has now his PR even if was not a good idea, next time I will talk about it to @jp9000 beforehand
  • https://github.com/obsproject/obs-studio/pull/5104
• Phase 2 is just missing the docs and waiting for RFCs and Phase 1 review
  • https://github.com/tytan652/obs-studio/compare/rfcs_phase_1...tytan652:rfcs_phase_2

[DDRBoxman]

I'll start off by saying that eve though there is some interdependency between these two RFCs they should be two separate PRs.

Currently both of these RFCs are lacking in details and seem to hand wave large changes that will end up being made alongside these changes.

I've put a number of comments above as a start.

[tytan652]

Thank you for your reviews

I'll start off by saying that eve though there is some interdependency between these two RFCs they should be two separate PRs.

Like I said in the first comment:

If you want me to separate this info two PR tell me.

So just tell me explicitly and I will do it.

I will look your other reviews later today.

[RytoEX]

If you want me to separate this info two PR tell me.

So just tell me explicitly and I will do it.

Yes, please split these two RFCs into two PRs. If one relies on the other, or they must both be considered or merged together, note that in the PR descriptions.

[tytan652]

PR split, commit will be squash later and phases are moved elsewhere.

[tytan652]

Additional to my comments, it's worth also noting some of the other things OAuth services do - Twitch is probably the main example here, it has a dropdown that allow a user to choose which Javascript plugins to inject. The OAuth plugin then injects that. I'm unsure if we should leave that up to the plugin developer to figure out, or if we should provide some sort of "when chat dock has loaded" event.

obs-twitch will have the same feature implemented through a dropdown in the property view and OBS_FRONTEND_EVENT_SERVICE_UPDATED that will change the script.

I will soon add what I add in the front-end API in a more detailed way, based on the exiting PR about adding BrowserDock API.

[tytan652]

I think figuring out how to split this up into smaller pieces that we can incrementally build on instead of a giant overhaul would be a good thing to look into.

We can't since service integration is too tied to the UI and the UI is too tied to rtmp-services.

Edit: Once you touch a piece, you need to replace a whole block.

[DDRBoxman]

It's probably worth doing an investigation to see if there are parts of the UI we can decouple as a prerequisite before the service overhaul. Smaller changes help lower the risk and allow easier review.

[tytan652]

It's probably worth doing an investigation to see if there are parts of the UI we can decouple as a prerequisite before the service overhaul.

Beside the YouTube Actions UI form, most of the service UI is refactored from Qt to PropertiesViews. So there is not much to decouple.

[tytan652]

I made a cleanup around old review conversations, some of them were closed with a comment some not because the RFC has really changed since then.

[Fenrirthviti]

Based on feedback on this thread, and in off-thread discussions, the project maintainers agree that this RFC needs to be scaled back and broken up in to smaller parts to approach in a more incremental way.

The project largely agrees with the end goal of what this RFC is proposing: a more customizable, flexible, and pluggable state for services and outputs in OBS.

However, the size and scope of the current approach makes these changes difficult, if not near impossible, to do a complete review and provide specific feedback. It is so large in scope that it is unapproachable to others seeking to review it, and is not likely to be accepted in the current state.

It was not an easy decision, but if we want to start making progress towards this goal, a new approach is necessary.

To that end, a better approach would be to split out the changes in to separate RFCs/PRs. We suggest a split along the following topics:

• Start by taking the YouTube, Twitch, and Restream integrations and make them pluggable. This would be an invisible change to the user.
• Once complete, evaluate where the overlap is between those plugins, and migrate functions in the OBS API to reduce duplication. Again, invisible to the user, no UI changes.
• Once parity has been reached with current implementation, start work towards refactoring a new UI and adding functionality as distinct and separate tasks.

We again thank everyone for their work on this RFC, and we hope that with these changes we can reach some of its goals sooner rather than later.