@DDRBoxman @tt2468 Would you be in support of defaulting it to Main instead of High? I consider this a bug, in one day I had 3 distinct debug sessions around this.

Changing a default is not feasible for now it would change everyone H264 settings against their will.

@tytan652 Can we detect if they are simple mode/have profile set explicitly?

Not if it matches the encoders default, this is a behavior we are working on changing.

I'm just explaining the situation with defaults.
But let me be clear, High or Main, I think a H264 decoder should be able to read both, or a trans-code should happen if the receiver can't handle it.

OpenH264 apparently only supports baseline profile.

@notr1ch I don't believe that is true anymore https://github.com/cisco/openh264/releases/tag/v2.0.0

Not all features of High are supported, but I haven't had any issue with main in a few years.

@tytan652 Forcing transcodes isn't best for user. I would like to to be useful for users who are self hosting/don't have the money to pay for transcodes.

It is also up to the user to apply the right settings themself if they don't want to transcode.
For now, we can't change default either if we agree of not on the change.

Edit: Maybe for simple mode, there can be a discussion (even if I think High is a default for a reason) but not for advanced mode.

This doesn't sound like something that is new to 30.2, so it's not a regression that would be addressed in 30.2.x. This also sounds more like a change/feature request than a bug report. OBS isn't doing anything wrong here. If users are self-hosting, I expect them to handle the quirks/needs of doing so.

@RytoEX Agree it isn't a regression! I disagree that it is not a bug.

Users are surprised/not happy with the default behavior. What really should happen is OBS should respect the Answer from the server. We are actually being told by the server that it only supports baseline/main. We just don't respect that request today.

In the future I should fully support the Offer/Answer model, that is a lot more code/logic though.

Users are surprised/not happy with the default behavior. What really should happen is OBS should respect the Answer from the server. We are actually being told by the server that it only supports baseline/main. We just don't respect that request today.

If WebRTC/WHIP has such a mechanism, then we could respect that restriction, yes. Personally, while I understand why you might see it as a bug, I still don't see it as a bug, but a missing implementation on the OBS side.

What qualifies something as a bug in OBS? Why do we not consider producing/sending invalid H264 for a remote not a bug?

I am not trying to be pedantic, but this is the definition I have. A software bug is a problem causing a program to crash or produce invalid output.

I don't want to see this issue deprioritized because it is mislabeled as a feature. I am happy to go and implement the full O/A model so that OBS sends the proper profile. The fix in the linked PR just has a much smaller blast radius and helps users today.

Why do we not consider producing/sending invalid H264 for a remote not a bug?

In this case, because as far as I can tell, the user can set a valid configuration and for some reason has not done so. It hasn't been demonstrated to me that the default configuration itself is an invalid configuration, only that it is not supported by the specific use case outlined.

I don't want to see this issue deprioritized because it is mislabeled as a feature.

Even if that were the case, as we are in beta right now, I am focused specifically on regressions, which this is not.