[WIP] Services Overhaul

[tytan652]

This PR has a now RFC, so for now don't review the code if you don't want to. If the RFC gets accepted I will continue to work on this PR, if not it will get closed.

Closes #4469 , this PR will become a plugin if those changes are accepted.

Description

• Add some functions to properties and service API
• Clean and made the UI able to accept services plugin
  This change will break many things, those will be restored an other way
• Add obs-services plugin which adds services with a type for each one and support multiple protocols per service with a new JSON format
  This plugin is based on StreamFX encoder/ffmpeg{_manager, _factory, _instance}
  • Make the plugin not register some services if OBS is built without FTL or RTMPS
  • Add maximum, supported resolutions and recommended settings with a possibility to ignore each one (partially done)
  • Add a service updater ?
• Add obs-services2 plugin which add services with custom behavior like ingest
  • Make the plugin not register some services if OBS is built without FTL or RTMPS
  • Add maximum, supported resolutions and recommended settings
• Add obs-twitch and obs-restream plugin to restore OAuth services
• Add VOD Track back (is this RTMP(S) only ?)
• Add back settings verification between Service, Video and Output (maximum, resolutions, recommended) when saving changes
• Add a legacy behavior for rtmp-services rather than remove it directly
• Make OBS check for service protocol rather than service output
• Add documentation about the new JSON format
• Add "Show All" option back in the service list

Those change will break the old OAuth.

Motivation and Context

Since #4469 shall become a plugin, but actually OBS doesn't support external service plugin.
I could just provide changes to just make service plugin a thing, but this way could be really dirty.

So I wanted to do more like separate Twitch and Restream integrations as plugins, create a better plugin for JSON services and an another one for services who needs specific behavior.
So I decided to try to provide those changes.

There is a long way to make it, but I want to give a try.

How Has This Been Tested?

Types of changes

• 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.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[WizardCM]

I feel this'd be better off an as RFC.

[tytan652]

I'm reading the RFCs repo Readme to understand what you mean

[tytan652]

If I correctly understood, I should write a RFC about those changes, discuss it with developers to see if they approve or not in a PR in RFCs repo.
And then create this PR. Right ?

[WizardCM]

Essentially, yes. The idea behind an RFC is so that you don't waste your time on aspects that need to be completely rewritten based on feedback. That way when you submit a PR it has a higher likeliness of being merged because the requirements are set in advance.

[tytan652]

Okay, I will try to write a RFC.
I imagine, I shall close this PR (or I can let it as a open draft ?).

Edit: Maybe adding somethings about RFCs in CONTRIBUTING.rst would be a nice addition

[jp9000]

Before I begin this reply, I need to say I haven't even looked at the code. That's not why I'm replying right now. Why I'm replying is because I am frustrated. I am very frustrated that:

• No project leaders knew about this before development started,
• No project leaders were asked about this before development started,
• No project leaders knew about this while it was in development, and that
• No project leaders were ever consulted or worked with while this was in development.

Basically, this situation is the kind of situation where it's like, "Hey everybody, I overhauled everything, I hope you like it!" And they don't really realize what they've done. And it does not matter if it's a draft PR or not.

And I realize that might sound harsh. Don't get me wrong, the intent is likely very well-meaning. I will never devalue someone who is genuinely trying to make things better. I am very grateful for it no matter what. However, what you don't seem to understand is that doing things in this way -- working on some big change, overhaul, or some giant feature, with minimal to no interaction with project leaders -- can end up being hurtful to everyone involved.

Hurtful because what if it's not what we want? What if it has major flaws? What if it has a design we disagree with? What if it has bugs? We were never consulted at any point during the process. I never knew about it at least. Never knew that this was going to be worked on, or that it was even being worked on until just now, when I saw it appear in my inbox. And because we were never consulted at any point during the process, then unless all this code -- which you have spent your valuable time working on -- is absolutely perfect in every possible way, you are likely going to be very disappointed when you find that your code will either require significant changes, or worse, needs to be entirely scrapped.

And mind you, that's if the maintainers are able to justify spending time to review it. Especially while there are so many other things in the waiting to be reviewed. People ask me, "hey jim, why hasn't my code been reviewed yet? It's been months/years", and then they never seem to be aware of anything else going on with the project outside of their own code or the PRs. Code review is like, only a part of what goes on with the project.

And the truly frustrating thing that causes me so much grief is that my entire response right here, right now, fundamentally cannot be viewed as anything other than ungrateful. Because you put in all of your valuable time and effort into making something that may very well be great. And although I'm grateful for that, it puts me in such an awkward position, because I truly do want changes, and I want people to submit code. But if you're writing something that is a big change, and I am not consulted at any point during the process, especially before you start working on it, inevitably there's be something that'll go wrong, there'll be some issue, or there'll be bugs, and it could require a significant amount of my time to help you with this, just simply because I was never once consulted on it. Or, worse, I could just completely reject it, and everyone just ends up feeling bad and dejected. Or even worse still, I could just never get time to review it, and you'd be sitting there wondering why it seems like we don't care or something (and this last one is the most likely scenario).

I just.. I don't really know what to say that won't come off as ungrateful. All I can do is just kind of sit at my desk, with defeated, baggy eyes, and look up at you with a sad, pleading face. In that very moment, I'm not thinking of the thick stack of papers that you just plopped onto my desk -- your valuable work, that you spent so much effort on. Instead, I can only say, "I see. I'll try to get to you as soon as I can -- if I can, sir." ..and then I just move my eyes back to what I was working on, feeling a deep pit growing in my stomach, knowing very well that this person will likely end up hating me later, as I move on to the next thing on my desk and try to prioritize things to the best of my ability.

Please don't hate me for this response, please don't see this as ungrateful. Instead, learn from it. In the future, interact with us before making a big change. Work with us. Fill out an RFC. Talk with project leaders in Discord if you're able. See what we think, how we feel. Ask us what we'd like to see or how we would like to approach some big change, or whether we want some big new feature. Then, once we say, "alright, that sounds good, go for it," or whatever, then start your work, and work with us while you do so. That is the best way that big changes will make it through. And even then, it can still be hard, and that's something you'll need to acknowledge, and persevere through.

As of right now, I'm not sure if I can go through with reviewing this any time soon. I guess it's just yet another increment to the PR count again. I'm not sure when I'll be able to justify spending time going over every single line in it. I don't think I can justify spending time reviewing this any time soon. What'll probably happen is the same thing that happens to all the surprise overhauls/changes -- it'll likely sit in the PR queue, waiting for who knows how long, until finally, I somehow manage to get time to look at it. And by that time, it'll probably have countless git conflicts, and I'll just probably die inside, knowing that the person who wrote it will likely have completely vanished or have lost all their will to work on it again by that point. Or they'll have forgotten all the code.

[tytan652]

If it need a RFC for this, then don't review it for now, it's my fault.

Sorry for not noticing the RFC step, but don't worry I will not vanish, I really want to be able to provide a PeerTube service plugin as third-party.
But I really made many missteps in the process (like not doing a RFC and not talk about it in the discord).
I really feel dumb about this.

PS: I'm actually filling a RFC.
Edit: I will talk about it in the discord before putting a PR for the RFC.

[jp9000]

You are absolutely not dumb at all. In fact, if I were pretty new to open source and contributing for my first time, I'd probably make the same mistake at least once, so you definitely shouldn't feel dumb about it. It probably doesn't help that most people don't really know the maintainer's perspective. And my reaction was probably a bit over the top. I think I've just been overwhelmed with a lot of the things going on behind the scenes lately. I apologize for that.