obsproject / obs-studio

OBS Studio - Free and open source software for live streaming and screen recording
https://obsproject.com
GNU General Public License v2.0
58.52k stars 7.81k forks source link

"Enforce Streaming Service Encoder Settings" Checkbox disables Rate Control setting #3060

Open naanlizard opened 4 years ago

naanlizard commented 4 years ago

Platform

Operating system and version: Windows 10 OBS Studio version: 25.0.0

Expected Behavior

When "Rate Control" is set to VBR, stream kbps should vary as needed by the encoder

Current Behavior

With "Enforce streaming service encoder settings" checked, the stream behaves as if the Rate Control setting is set to CBR regardless of what it is actually set to

Steps to Reproduce

  1. Set stream service to any known service (NOT "Custom...")
  2. Set output mode to advanced, rate control to VBR, leave "enforce streaming service encoder settings checked.
  3. Start stream, observe CBR-like behavior
  4. Stop stream, uncheck "enforce streaming service encoder settings", start stream and observe VBR-like behavior

Additional information

Notably, "enforce streaming service encoder settings" does not do anything to the stream (afaik) when stream service is set to "Custom..."

notr1ch commented 4 years ago

Most services have a maximum bitrate limit, this cannot be enforced without use of CBR.

naanlizard commented 4 years ago

Can't the bitrate setting just be compared to the limit of whatever service, and use the smaller of the two? That seems like a straightforward fix

notr1ch commented 4 years ago

That's what "Enforce streaming service encoder settings" does. If the service has a bitrate limit, your bitrate is reduced to the maximum, and output set to CBR to ensure the stream remains within that maximum.

Assuming you're talking about x264, "CBR" in OBS is actually ABR with a VBV bitrate target, with padding (to ensure a smooth output rate). VBR is CRF with a VBV bitrate target, no padding. In both cases the VBV buffer size is 1 second, so you get bitrate constrained output, the difference being primarily the presence of padding.

The padding is necessary to avoid bandwidth fluctuations on both sides - eg going from 100kbps in a static menu to 6000kbps in a game could cause sudden spikes of bandwidth that result in packet loss.

energizerfellow commented 4 years ago

The enforcement of CBR is in no way communicated to the user as the rate control pulldown is still both visible and setable with enforcement enabled, which is why I think this issue was created in the first place.

How about hiding the rate control pulldown entirely unless the enforce checkbox is UNchecked?

naanlizard commented 4 years ago

The padding is massively wasteful though, and some services (at least, mine, but presumably most that aren't the big twitch/youtube/etc sites) would strongly prefer that the checkbox NOT behave this way, because it's confusing to users. For especially things like art/coding streams where there is not a lot of motion, this represents a ton of wasted bandwidth.

@energizerfellow has the right of it - it is not clearly communicated at all, it trips up users constantly.

I don't think forcing CBR for streams with the checkbox checked makes sense. If you know enough to switch to VBR, you probably know enough to make sure your internet (and the service) can handle the potential bandwidth swings.

I still suggest simply limiting the bitrate setting to the service's maximum when the checkbox is checked, and do not adjust the rate control setting based on the checkbox.

dodgepong commented 4 years ago

The padding is massively wasteful though

Depends on your definition of wasteful. The purpose of the padding is to maintain predictability for internet QoS systems. Without CBR, you could be streaming at a low bitrate, sure, but then suddenly you have a lot of motion on your stream and your bitrate spikes above what QoS systems have allocated you for, then you start dropping frames and your viewers get a bad viewing experience. So in that sense, I would argue that the "waste" is worth it for the value you're getting out of it.

naanlizard commented 4 years ago

Sure. I see why some users would want that. For what it's worth, for many years now we've had every user using vbr nearly, and for art streams at least it causes no problems and leads to smaller recordings and far lower bandwidth usage.

But the setting as it is is not clear and leads to confusion from our users nearly every time (we suggest settings to change, they do, almost always they miss the "enforce" checkbox being unchecked if it isn't specifically called out). If the goal of that setting is to force cbr on, then don't allow rate control to be set to anything other than cbr. I think that is a very strange bunch of things for that checkbox to be doing though, and it would make more sense to simply limit the bitrate setting instead when it is checked

RytoEX commented 4 years ago

The padding is massively wasteful though, and some services (at least, mine, but presumably most that aren't the big twitch/youtube/etc sites) would strongly prefer that the checkbox NOT behave this way, because it's confusing to users.

As @notr1ch and @dodgepong said above, enforcing CBR for streaming is the default behavior because it keeps network traffic predictable. I would imagine that service providers preferring/recommending VBR are not as common, but I don't have hard numbers on this subject. Could you please point us to services that specifically recommend VBR for their settings?

I don't think forcing CBR for streams with the checkbox checked makes sense. If you know enough to switch to VBR, you probably know enough to make sure your internet (and the service) can handle the potential bandwidth swings.

I can say with absolute confidence that a lot of users change settings and click buttons without knowing what they do. Even users that might know a thing or two about PCs might have no idea about how VBR affects network services.

I think that is a very strange bunch of things for that checkbox to be doing though, and it would make more sense to simply limit the bitrate setting instead when it is checked

The "Enforce streaming service encoder settings" does far more than just limit bitrate. It also enforces keyframe interval, max audio bitrate, x264 options, AVC profiles, b-frames, and output type. It's not just max video bitrate. It's essentially a way to try to prevent users from deviating from a service provider's preferred/recommended parameters. A variety of such parameters can be seen throughout plugins/rtmp-services/data/services.json.

Changing this setting to just limiting bitrate could adversely affect many of the services in our services list and their users.


I think it would be much safer if we did something like this:

  1. OBS specifies a new services.json flag to use in the "recommended" key (e.g., "rate control": "VBR", "rate control": "CBR")
  2. encourage service providers who want VBR enforced to specify that flag in their services.json entry
  3. if "Enforce streaming service encoder settings" is checked, and a service has specified they recommend VBR, enforce VBR
  4. if "Enforce streaming service encoder settings" is checked, and a service has specified they recommend CBR, enforce CBR
  5. if "Enforce streaming service encoder settings" is not checked, use the rate control method the user has specified
  6. if "Enforce streaming service encoder settings" is checked, but the flag is missing/omitted, enforce CBR to maintain the current behavior
  7. log whether or not "Enforce streaming service encoder settings" is checked and active

I think that this approach is more comprehensive. I may have an idea for giving users the option to only enforce bitrate limits while also keeping the current option for enforcing all encoder settings as a separate option. However, I'd like to make sure that either change would be accepted before trying to work on it.

naanlizard commented 4 years ago

As @notr1ch and @dodgepong said above, enforcing CBR for streaming is the default behavior because it keeps network traffic predictable. I would imagine that service providers preferring/recommending VBR are not as common, but I don't have hard numbers on this subject. Could you please point us to services that specifically recommend VBR for their settings?

Piczel.tv (mine) at a minimum. I'm not aware of others, but admittedly I don't go around checking. I suspect CBR is recommended by many (again, at least smaller services) as a legacy/inertia thing rather than considered opinion.

The "Enforce streaming service encoder settings" does far more than just limit bitrate. It also enforces keyframe interval, max audio bitrate, x264 options, AVC profiles, b-frames, and output type. It's not just max video bitrate. It's essentially a way to try to prevent users from deviating from a service provider's preferred/recommended parameters. A variety of such parameters can be seen throughout plugins/rtmp-services/data/services.json.

Changing this setting to just limiting bitrate could adversely affect many of the services in our services list and their users.

That makes more sense, but nowhere is that communicated to users (or, at the time, me when I was looking to find out what it did. Perhaps I overlooked it). Agreed that my suggestion then would be a bad change, thank you for clarifying.

Your suggestion of being able to enforce VBR by default is good - I would have suggested that from the beginning but it sounded like more work to me, so I tried for something more simple.

DrunKev commented 4 years ago

Enforce streaming service encoder settings is meant to enforce streaming service encoder settings.

Twitch guidelines are max of 6000kbps, keyframe interval to 2 and CBR so these values get set internally.

This is working as intended.

Can we close this?

naanlizard commented 4 years ago

I think the discussion has evolved beyond the initial ticket, but to simply say that everything is working as intended because twitch's settings are enforced on every service in the list seems to be missing the forest for the trees.

Edit: to rephrase, I think allowing services to specify that "enforce streaming..." should enforce VBR instead of CBR would be a good solution with no backwards compatibility concerns, I don't think.

RytoEX commented 4 years ago

Twitch guidelines are max of 6000kbps, keyframe interval to 2 and CBR so these values get set internally.

to simply say that everything is working as intended because twitch's settings are enforced on every service in the list

This is not accurate. OBS does not force every service to Twitch's recommended settings of max video bitrate of 6000kbps, and keyframe interval 2. As I explained above, OBS enforces maximum video bitrate and several other settings according to the items specified in the name/value pairs in the "recommended" object in service's entry in the services.json file. The functions that enforce these settings for non-custom RTMP services are apply_video_encoder_settings in plugins/rtmp-services/rtmp-common.c line 477 and apply_audio_encoder_settings in plugins/rtmp-services/rtmp-common.c line 526.

That said, I do believe that "Enforce streaming service encoder settings" is currently working as intended and that the issue as initially reported can be closed. The commits explaining why OBS forces CBR when using this feature are 7c8ef6f6efca06387705d6347cbd244f47db3f5e, 61d86d938a8a60eb26b6953c2ba2b43bb50d72ca, and 2801cf0f378e9f34f73ea19ff6bb3d72ea4920e5. There are broader questions of whether we should change this behavior or if we should allow services to recommend and force VBR when enforcing settings, but those are not in scope of the initial report. In my opinion, this either needs to be refocused or this should be closed and a new issue should be opened. However, I'd like to hear from @notr1ch or @dodgepong on this.

naanlizard commented 4 years ago

I'll open a new ticket wherever you think best to continue the discussion, and can even probably get a pull request made with a nudge in the right direction assuming it's a feature the project would like

dodgepong commented 4 years ago

The only change here that might be worthwhile would be disabling the settings that are already being controlled by the settings enforcer and including some sort of note in the UI so users understand why it's disabled.

mufunyo commented 4 years ago

I've felt that ever since it was first included all the way back in OBS Classic, while an understandable feature to minimise network congestion, having CBR with padding be almost impossible to disable functionality is not the way to go.

I'll go and have a big thonk about exposing rate control in a meaningful way that doesn't cause people to select the wrong options out of ignorance, but does allow things like CRF recordings (without padding) easily.

RytoEX commented 4 years ago

@mufunyo It's not impossible to disable. Currently, if a user is in Advanced Output Mode, they select VBR (or any other Rate Control) for streaming rate control, and they do not check the "Enforce streaming service encoder settings" checkbox, then OBS does not automatically set CBR. Am I missing something?

naanlizard commented 4 years ago

What needs to be done to make something like this happen -

OBS specifies a new services.json flag to use in the "recommended" key (e.g., "rate control": "VBR", "rate control": "CBR") encourage service providers who want VBR enforced to specify that flag in their services.json entry if "Enforce streaming service encoder settings" is checked, and a service has specified they recommend VBR, enforce VBR if "Enforce streaming service encoder settings" is checked, and a service has specified they recommend CBR, enforce CBR if "Enforce streaming service encoder settings" is not checked, use the rate control method the user has specified if "Enforce streaming service encoder settings" is checked, but the flag is missing/omitted, enforce CBR to maintain the current behavior log whether or not "Enforce streaming service encoder settings" is checked and active

I think that's a comprehensive and well thought out solution and would love to see it. Let me know where to start and I can probably get some programming time on it.

RytoEX commented 4 years ago

@naanlizard I had other commitments and I want buy-in from people who would decide if it gets merged before I spend time on it.

naanlizard commented 4 years ago

@RytoEX - I totally understand. I'm looking to spend some time coding this myself (or more accurately, have one of my devs contribute). I was hoping to get a few pointers on where they should start re: adding the new services.json flag, but perhaps we can figure it out on our own

naanlizard commented 3 years ago

With 26.1, how do the changes to the "enforce streaming..." checkbox relate to the VBR/CBR setting? Can we force VBR (or at least, does the default (unchecked "ignore" checkbox) not force CBR?

Thanks

naanlizard commented 2 years ago

bump, who do we agitate about this

Fenrirthviti commented 2 years ago

Amusingly, this conversation just came up again internally. I can't guarantee anything for v28, but the pain point is felt on our end as well, as we know this isn't ideal, so we are looking in to solutions.

naanlizard commented 2 years ago

Glad to hear. Happy to bounce ideas around, though I think what I laid out above is probably ideal, behavior wise

rhutsAMD commented 1 year ago

We are interested in enabling the this kind of behaviour as well for use with the AMF plugin 😊

naanlizard commented 3 months ago

Any hope of a fix for this any time soon? It's tedious to have to keep telling users to use "custom"