obsproject
Add RFC: Add notion of protocol
RFC 45: Add notion of protocol
Summary
- Add notion of service protocol in libobs and OBS Studio
- Outputs for streaming are registered with their compatible protocol and codecs
- Only codecs compatible with the output and the service are shown
- Audio encoder can be choosen if various compatible
- Will be extended with RFC #39
Motivation and Context
Create a better management of outputs, encoders and services with an approach focused on protocols.
It seems like a needless feature to let users select which implementation of a protocol they want. And that's the only feature here that can't trivially be moved to the output objects.
Big rewrite of the RFC, thank you @henke37 for the (maybe wrong word) spur.
I was stuck thinking about protocol and output being separate thing but having them together is better and more lightweight codewise.
Added HEVC for services in rtmp-services with HLS protocol.
~~Edit: I may add something about enforcing codecs for codec-agnostic protocol in the services.json through JSON Schema.~~
Re-edit: Done
Remove "codec agnostic" related content, some output require to be prepared to enable a new codec.
In addition to codec compatibility, we might want to have a flag in the services file to indicate compatibility with HDR (None/PQ/HLG/Both).
Services may support HEVC or AV1 codecs for improved compression, but do support HDR delivery or tonemapping to SDR, which would result in viewers receiving a clipped version of the video. Furthermore they may support only one of the HDR formats (e.g. PQ but not HLG).
While the number of services supporting HLS or SRT/RIST ingest is currently limited, in the future there may also be outputs such as WHIP or MoQ/WARP that support more than H.264.
In addition to codec compatibility, we might want to have a flag in the services file to indicate compatibility with HDR (None/PQ/HLG/Both).
Services may support HEVC or AV1 codecs for improved compression, but do support HDR delivery or tonemapping to SDR, which would result in viewers receiving a clipped version of the video. Furthermore they may support only one of the HDR formats (e.g. PQ but not HLG).
While the number of services supporting HLS or SRT/RIST ingest is currently limited, in the future there may also be outputs such as WHIP or MoQ/WARP that support more than H.264.
All of this is out of scope of this RFC, it is more related to RFC #39 but selecting a color format is literally a trial and error in OBS as it always was, the user can apply unusable settings in advanced video. This needs a major refactor of settings that can only be done after (maybe while) RFC #53 which is after 39.
Entering FCP. We've merged the initial PRs, but any further adjustments necessary are still welcome. Once the open conversations are resolved, we will merge this.
