Anaerin
New Member
Okay, this is going to seem weird, but bear with me here.
With OBS being used in many more professional situations, and consolidating streams from multiple sources (WebRTC call ins and the like), My idea/suggestion is a headless version of OBS that can be used in a VPS, on a virtual machine or Docker/Kubernetes image. It would take a "Configuration file" exported from desktop OBS (for instance), and support RTMP/RTSP sources (both in and out) along with source monitoring, and have a remote control system (like Websockets, for instance).
So you could have a fallback scene when your source goes offline, and scenes with a variety of sources for call-ins (through obs.ninja or similar systems/services). Or if covering something like a WAN party or multiplayer setup, each player can have their own instance capturing and feeding to a central headless aggregator which then streams to <streaming service of choice>. This would mean you could use a low-cost, high bandwidth cloud host to combine many lower-bandwidth streams, rather than having to have a high-bandwidth feed of your own somewhere. You could also use it as a very low-latency video conference system, where the OBS instance acts as a central server, taking in multiple feeds and arranging them, then sending the single combined feed back to all the participants.
Adding this architecture change would also potentially make cross-platform development easier, and allow alternative frontends (looking at you, SLOBS) to work a lot better, with a client/server API.
With OBS being used in many more professional situations, and consolidating streams from multiple sources (WebRTC call ins and the like), My idea/suggestion is a headless version of OBS that can be used in a VPS, on a virtual machine or Docker/Kubernetes image. It would take a "Configuration file" exported from desktop OBS (for instance), and support RTMP/RTSP sources (both in and out) along with source monitoring, and have a remote control system (like Websockets, for instance).
So you could have a fallback scene when your source goes offline, and scenes with a variety of sources for call-ins (through obs.ninja or similar systems/services). Or if covering something like a WAN party or multiplayer setup, each player can have their own instance capturing and feeding to a central headless aggregator which then streams to <streaming service of choice>. This would mean you could use a low-cost, high bandwidth cloud host to combine many lower-bandwidth streams, rather than having to have a high-bandwidth feed of your own somewhere. You could also use it as a very low-latency video conference system, where the OBS instance acts as a central server, taking in multiple feeds and arranging them, then sending the single combined feed back to all the participants.
Adding this architecture change would also potentially make cross-platform development easier, and allow alternative frontends (looking at you, SLOBS) to work a lot better, with a client/server API.