obsproject
UI: Add audio properties to GetClientConfiguration request
Description
Instead of transparently resampling audio to match GetClientConfiguration's request send information about local audio settings to GetClientConfiguration
Currently this is only checked in OBS Studio after a configuration has already been received, which doesn't allow for potentially different configurations in case e.g. iOS support is not necessary for this particular stream
Motivation and Context
The Twitch iOS app (and/or HLS playback on iOS in general?) requires audio to be stereo or mono; with this change the requested number of channels from the go live config is being honored, so users can still set up their recordings to contain audio in whichever speaker layout they desire, while the format for streamed audio adheres to service requirements
How Has This Been Tested?
Verified audio settings are part of the GetClientConfiguration request
Types of changes
- Tweak (non-breaking change to improve existing functionality)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation.
@derrod @tt2468 Please take a look at the commits I just pushed. I added a new function to libobs to get the required audio information and updated the PR to use this new function. If this looks OK, I can squash commits to tidy this up.
Yeah this seems fine to me.
Thanks @derrod. I've squashed the 3 commits into 2 and pushed the changes. This should be good to go now.
I believe @Warchamp7 's concern here, communicated off-thread, is that this only fixes this issue for the Multitrack Video path (Twitch Enhanced Broadcasting), meaning that users who attempt to stream normally without Multitrack Video will still run into this issue with iOS viewers. I'll let him elaborate on his concerns.
Confirming the above summary from Ryan. This PR specifically adds the ability to query the information from libobs and includes it in the autoconfig POST data, which is fine on it's own. However I want to be sure that the followup to this is not a solution that only applies when using Multitrack Video.
Multitrack Video should leverage a general fix such as services recommendations being updated to support this data, or it can display an error for the user to fix themselves (As in many other cases)
Confirming the above summary from Ryan. This PR specifically adds the ability to query the information from libobs and includes it in the autoconfig POST data, which is fine on it's own. However I want to be sure that the followup to this is not a solution that only applies when using Multitrack Video.
Multitrack Video should leverage a general fix such as services recommendations being updated to support this data, or it can display an error for the user to fix themselves (As in many other cases)
We haven't decided yet on how to followup, but if we make another attempt at resampling we'll try to target both multitrack video and non-multitrack video
Confirming the above summary from Ryan. This PR specifically adds the ability to query the information from libobs and includes it in the autoconfig POST data, which is fine on it's own. However I want to be sure that the followup to this is not a solution that only applies when using Multitrack Video.
Multitrack Video should leverage a general fix such as services recommendations being updated to support this data, or it can display an error for the user to fix themselves (As in many other cases)
@Warchamp7 Given that this only adds the data to the POST data, is this acceptable to merge?