frontend: Scale simple output recording audio bitrate by channel count

[nickvonkaenel]

Description

In Simple output mode, the recording audio bitrate was hardcoded to 192 kbps regardless of channel layout. The intention of this based on the git log was to ensure a high enough quality for recording regardless of the streaming setting. It didn't account for recordings with more than 2 channels where 192 kbps will not suffice.

This change replaces the hardcoded 192 value with a value calculated by scaling proportionally from the stereo reference (192 kbps) using the active channel count, snapping to the closest bitrate supported by the selected encoder (AAC or Opus).

Stereo recordings are unchanged (192 * 2 / 2 = 192 kbps).

Motivation and Context

Currently, users recording in 5.1 or 7.1 formats will have degraded audio encoding (~32 kbps per channel) unless they switch to advanced mode. This does not seem like ideal behavior, especially since it's not clear this is happening based on the UI. By scaling the encoding quality depending on the channel count, we can ensure a quality experience.

How Has This Been Tested?

Built on Windows 11 and tested by recording a capture with 6 channels in simple mode, confirming that the bitrate was increased as expected.

Types of changes

• Tweak (non-breaking change to improve existing functionality)

Checklist:

• I have read the contributing document.
• My code has been run through clang-format.
• My code follows the project's style guidelines
• My code is not on the master branch.
• My code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[tt2468]

Are there any other examples of applications which implement this behavior? I mainly ask because users with specific bitrate requirements may encounter this as unexpected behavior. I definitely would myself.

Perhaps it would be good to provide some kind of label in the UI providing a simple calculation of real audio track bitrate, so that the user is aware of this scaling. cc @Warchamp7

I do agree with the choice to implement this scaling via the UI code, as it preserves existing behavior for features like Enhanced Broadcast.

[nickvonkaenel]

That's a good point. Hiding this value has caused confusion for me and others I work with. If it were exposed in the interface as 192 then I would have just changed it. I thought it was based off the streaming setting and couldn't understand why it was so low for surround formats.

I would be in favor of just exposing the recording bitrate in the UI instead of my change, and perhaps considering a higher default such as 320 which at least wouldn't be terrible for 5.1

[notr1ch]

IMO simple mode should be a "just works" mode for people who don't understand encoder and bitrate and just want OBS to set sensible values for them, so in this case, I think exposing it as an option does more harm than good. I'd be fine with the approach taken in this PR.

[mihawk90]

Are there any other examples of applications which implement this behavior?

I happened to come across a similar discussion in a PR for a Jellyfin music player:

finamp-app/finamp#1524

TLDR We decided we didn't want to take away control from the user by hardcoding any kind of formula. Instead we went for a setting so users can decide how they want to handle multitrack audio themselves.

Obviously this is a slightly different usecase (music listening vs. recording), but that's just my 2c on it.

[nickvonkaenel]

Perhaps the default setting could be "auto" which does the scaling in this pr but it's still able to be changed by the user to a specific bitrate. That would alleviate the confusion imo.

I understand making the simple mode a simple experience, but if the bitrate is hidden I would expect it to be hidden for both recording and streaming. Right now it's only exposed for streaming with the hardcoded value for recording.

[pkviet]

LGTM apart from the cosmetics.
I don't remember why I did not change the default for simple output.
I agree with R1ch that there should be no options in Simple output; it is the purpose of Advanced Output to expose fine-grained control.

[nickvonkaenel]

Added spacing after the bitrate selection block.

[Warchamp7]

Looks good to me aside from the codestyle fixes.

[nickvonkaenel]

Looks good to me aside from the codestyle fixes.

Fixed in be9fac4

[nickvonkaenel]

Would it be possible to revisit this?

[Warchamp7]

Needs squash but ready to go

[nickvonkaenel]

Needs squash but ready to go

Squashed

[RytoEX]

clang-format will need to be fixed.