Add RFC: Redesign Outputs, Accounts and Auth system

[Xaymar]

Description

An RFC to replace/extend the current Output/Account/Auth system with a more moduler and extendable one that allows for some of the features that people have asked for out of the box.

Motivation and Context

The current way requires outside companies to either ship their own OBS Studio or hope that the Maintainers are willing to merge their changes - which is often unlikely. This system removes that burden from maintainers and instead moves it back to the company that wants to add their service.

Link to RFC

https://github.com/Xaymar/rfcs/blob/output-account-auth/accepted/0008-output-account-auth.md

[Xaymar]

Mockup of the new Output UI

Switching outputs with unsaved changes will spawn a Yes/No/Cancel request where:

• Yes: Switch to another output, don't save/apply any changes.
• No: Switch to another output but save/apply any changes.
• Cancel: Don't switch.

[UserNaem]

I have a few questions.
First:

How do I know which of these tabs are for livestreams, which are for recordings and which are for replay buffers? If I don't explicitly label them, they'll probably show placeholder names like "New output (1)", "New output (2)".

Second:
The current obs-studio UI allows re-using the same encoding sessions for more than one output, i.e. stream, record and replay buffer all with one video encoder, use libopus for FTL and aac for local recordings. How are you going to communicate to the user their ability to re-use an existing encoding session for multiple outputs?

Let's pretend I have no idea how to use OBS. How do I get this "(Use YouTube encoder)" button to show up?
And what if I edit the "YouTube" preset in such a way that it can no longer be used for this output, i.e. switch encoder to ProRes so I can no longer livestream with it?

Third:
What will happen to the Controls dock in the main window? If you add a new button for every single output, it might grow too long, and become a mess to navigate. While most users would probably end up with anywhere between 1 and 5 buttons, some edge-cases might emerge and use as many as 10+.

[Xaymar]

How do I know which of these tabs are for livestreams, which are for recordings and which are for replay buffers?

Recording and Replay Buffer are not made non-unique by this RFC, so you would simply have to name them Recording and Replay Buffer (their default names).

If I don't explicitly label them, they'll probably show placeholder names like "New output (1)", "New output (2)".

They would show up as OutputName, so a Recording output that is created will have a default name of Recording (in the users language) that can be changed if the user desires to do so.

The current obs-studio UI allows re-using the same encoding sessions for more than one output, i.e. stream, record and replay buffer all with one video encoder, use libopus for FTL and aac for local recordings. How are you going to communicate to the user their ability to re-use an existing encoding session for multiple outputs?

See mockup, third image. Audio encoders can't be selected in this RFC and are something for another RFC entirely.

What will happen to the Controls dock in the main window?

Start Recording and Start Replay Buffer will stay the same, as the RFC does not make these non-unique outputs. They can only exist once, unless another RFC or PR comes along and allows multiple of them. Furthermore, outputs now have a category field that allows them to be described as recording outputs. The UI could use this to classify a certain output as recording or not for recording.

As for the niche case where you want to start a specific output, that is better covered in another RFC. As a general idea, a dropdown could be added next to the Start X button to allow specifying which outputs are meant by each button, or which outputs to start exactly.

As for Decklink and NDI output, those would be 'Streaming', not recording. They may be used for recording, but they do not record by themselves, so they are streaming. Edit: FFmpeg output is also considered a streaming one, as it is capable of more than just recording.

[Xaymar]

Added entry for specifying supported audio and video codecs. If the returned list is empty or only contains the passthrough entry, audio and video settings tab disappear. This is useful for NDI, Decklink, FFmpeg and WebRTC, which have internal encoders.

[UserNaem]

Edit: FFmpeg output is also considered a streaming one, as it is capable of more than just recording.

FFmpeg output can output to URLs or files, but in the current obs-studio UI it always uses the recording and replay buffer "slots", leaving the streaming "slot" available.

As for the niche case where you want to start a specific output, that is better covered in another RFC.

So, uh, if I set up multiple recording outputs, the "Start recording" button won't let me pick which one to use? How is that any different from creating multiple profiles, then?

[Xaymar]

FFmpeg output can output to URLs or files, but in the current obs-studio UI it always uses the recording and replay buffer "slots", leaving the streaming "slot" available.

That is correct. It could be considered an additional recording output, if necessary. In that case it would just be enough to set the category to 'recording' instead.

So, uh, if I set up multiple recording outputs, the "Start recording" button won't let me pick which one to use? How is that any different from creating multiple profiles, then?

This doesn't replace profiles. This adds multiple parallel outputs and fixes our current problem that outside companies have to depend on obs maintainers to add their service to OBS Studio. Profiles have a perfectly valid reason to stay, and should be preferred if you intend to use a specific set of outputs.

Edit: Also per my previous answer, you can only have one Recording output. This RFC does not make recording non-unique.

[Xaymar]

Slightly redesigned the RFC, added some notes that were discussed here, and some additional unresolved questions.

[WizardCM]

How do I know which of these tabs are for livestreams, which are for recordings and which are for replay buffers? If I don't explicitly label them, they'll probably show placeholder names like "New output (1)", "New output (2)".

IMO: icons. I'm also not a fan of super tall, fixed-width buttons for this, and using a horizontal scrollbar is a pain to navigate. May be worth asking around, "if you could have as many outputs configured for a single profile as you want, what would it max out as?" Should there be a "master output" where you configure the core stuff (resolution, etc) and then the child outputs override only as necessary?

I worry the current design is too complicated for a new user. Personally, I'd like to see the current 3 outputs provided as presets, so the user knows what they're getting into. You start with 3 (Streaming, Recording, Replay Buffer), and you can delete/add as you see fit from there.

I REALLY like the idea of each of the outputs having a Simple toggle, but I'd actually do it differently: an "Advanced" checkbox in the bottom left corner (therefore not the first option in each output). Simple mode should expose everything a normal user would need, whereas Advanced would expose the stuff that normally shouldn't be tweaked, but might need to be for specific usecases. I even think Custom FFMPEG Output should be hidden further, but that may be a discussion for a later date.

Part of the core reasoning for redesigning outputs is its extensibility. Sure, you may want to be able to add more encoders or codecs, but there's a more important use case: third party outputs like DirectShow, NDI, etc, etc, etc. All of these should be configurable from this single location. In terms of NDI for example, it also supports filters that output specific scenes. This outputs UI should allow at least a read-only view of which sources have configured NDI Output filters, and which ones are currently enabled.

In terms of the Controls dock, I actually think having a user-configurable dock called Outputs would make sense here. Regular users get to keep the current dock with Recording, Streaming, and Replay Buffer, and users who have a huge combination can get a basic UI to create buttons, switches and dropdowns for each of their outputs to easily see the status & control them. This could even be an advanced mode of the Stats dock.

[Xaymar]

IMO: icons. I'm also not a fan of super tall, fixed-width buttons for this, and using a horizontal scrollbar is a pain to navigate.

See the RFC, which defines Icons. I couldn't get Qt to show them unfortunately, so the mockup doesn't have any.

You start with 3 (Streaming, Recording, Replay Buffer), and you can delete/add as you see fit from there.

The RFC doesn't prevent this, and this would most likely be the default setup anyway. A single RTMP output (or a twitch/Youtube/etc output created from the autoconfiguration wizard) and everything is ready.

an "Advanced" checkbox in the bottom left corner (therefore not the first option in each output).

That does sound better.

[Xaymar]

So from what I've gathered, the main problems are:

• Big icons instead of a list for outputs. This was a personal preference, and it works quite well, but if it is not wanted another design will have to do. Maybe a simple boring list with a small icon will be enough instead.
• Support for NDI and DirectShow. This relies on Outputs having their own settings, which is already shown here. As long as the output has properties, nothing will change.
• Advanced dropdown vs checkbox. I admit this was me trying to merge another RFC into this one, which allows for more than just "Simple" or "Advanced" options. But the checkbox is the better option for now.
• The RFC covers too much for it to be accepted.

Going forward:

• I will strip down the RFC to the bare minimum necessary for this to be accepted.
  • Existing structures will stay the same.
  • Just modifying the frontend.
• Once accepted, will actually implement these for a 25.x or 26.0 release.

[RayBenefield]

Any movement on this? The ability to have multiple video tracks would be amazing as well as the restreaming opportunities.

[Xaymar]

Closing in favor of different future RFCs.

[karlthepagan]

A smaller and relatively MUCH SIMPLER feature has been linked into this RFC and subsequently squashed. Scope creep is killing a nice to have feature: Scene Items which are only visible on the preview (and perhaps visible or not to other filters).

https://ideas.obsproject.com/posts/935/option-to-hide-source-from-stream was closed as duplicate in favor of https://ideas.obsproject.com/posts/41/multiple-video-outputs-selective-recording-iso-recording

Please note the feature creep which is being foisted upon the Scene Item Visibility feature request. The final product created for outputs and auth should be developed independently of the request for per-stream filtering. What I need is per-scene item visibility. This is an underlying render architecture change which would allow filtering per existing output (NDI Filter, Virtual Webcam Filter, Output Streaming) without a UI redesign, without multiple stream encoders, and without an auth architecture change blocking the development of the visibility feature.

[Xaymar]

A smaller and relatively MUCH SIMPLER feature has been linked into this RFC and subsequently squashed. Scope creep is killing a nice to have feature: Scene Items which are only visible on the preview (and perhaps visible or not to other filters).

The original idea for this RFC was to refactor the Authentification and Streaming Services, which derailed into a refactor of everything related to Outputs. I have not yet had time to write new RFCs, aside from #35 and #34.

[karlthepagan]

Thanks for the response Xaymar. I don't have any problem with this RFC, but wanted to link back to the source suggestions to help users following the breadcrumbs. I will work on organizing a new RFC and explore use-cases that support it.

Thanks for your work.