Description
This PR adds supports for Simulcast to the obs-webrtc output. Simulcast allows for multiple quality levels to be sent over one track in WebRTC.
RFC 8853 is a technical description. For a less technical explanation Wowza, Dolby and LiveKit have all written articles on it.
This PR starts with adding a Spinbox when WHIP is selected. This allows the user to choose how many layers to send in total. The acceptable range (for now) is 1-4.
The Height/Width/Bitrate is scaled from the users global choice. So depending on the users choice.
- 1 Layers (
- 100% Height/Width/Bitrate
- 2 Layers
- 100% Height/Width/Bitrate,
- 50% Height/Width/Bitrate
- 3 Layers
- 100% Height/Width/Bitrate
- 66% Height/Width/Bitrate
- 33% Height/Width/Bitrate
- 4 Layers
- 100% Height/Width/Bitrate
- 75% Height/Width/Bitrate
- 50% Height/Width/Bitrate
- 25% Height/Width/Bitrate
A server may wish to only accept a subset of the layers offered. Today if the user rejects any layers we throw an error and say how many layers were accepted. The user can lower the amount of layers they are sending and try again. Services in their documentation will be expected to tell users how they want video encoded and how many layers they are willing to accept.
Motivation and Context
- Low Latency - Decoding/Re-encoding adds too much latency for interactive content
- Make self hosting easier - Running ffmpeg is costly and difficult to scale
- Streamers more control - If streamers can generate transcodes they control the quality
- E2E Encryption/Prevent Modification- Streamers can distribute keys to viewers and servers can't modify video anymore.
Some questions that have been asked by reviewers already.
What about Enhanced Broadcasting? - Simulcast is part of an existing standard that already sees a billion minutes per day so it is here to stay and is already deployed massively. I would like to see Enhanced Broadcasting in the JSON blob be able to specify the protocol. When a user starts a enhanced broadcasting session it should be able to switch between RTMP/WebRTC/$x. I think both flows can/should exist because they serve different purposes.
UI/UX Considerations - A single opt-in is non-intrusive and respects the user. It would be good to get feedback from all OBS WebRTC users (Dolby, LiveKit, Cloudflare etc...) that this is a sound decision though.
How Has This Been Tested?
This has been tested with the nvenc, qsv, and x264.
I have tested this against Twitch, Broadcast Box, LiveKit and Dolby.
Types of changes
- New feature (non-breaking change which adds functionality)
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.