search

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
57.22k stars 7.72k forks source link

obs-webrtc should default to main profile #10821

Open Sean-Der opened 3 weeks ago

Sean-Der commented 3 weeks ago

Operating System Info

Windows 11

Other OS

No response

OBS Studio Version

30.2.0-beta1

OBS Studio Version (Other)

No response

OBS Studio Log URL

N/A

OBS Studio Crash Log URL

No response

Expected Behavior

Multiple users when testing OBS WebRTC reported playback errors. I was having a hard time reproducing them until I realized that the H264 profile was unset. It was defaulting to High and was causing playback issues. Browsers sometimes use OpenH264 which doesn't support H264

Current Behavior

Video playback with OBS + H264 by default isn't reliable

Steps to Reproduce

  1. Stream using WebRTC and don't change any encoder settings
  2. Video playback will be erratic/unreliable

Anything else we should know?

No response

Sean-Der commented 3 weeks ago

@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.

tytan652 commented 3 weeks ago

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

Sean-Der commented 3 weeks ago

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

tytan652 commented 3 weeks ago

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.

notr1ch commented 3 weeks ago

OpenH264 apparently only supports baseline profile.

Sean-Der commented 3 weeks ago

@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.

Sean-Der commented 3 weeks ago

@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.

tytan652 commented 3 weeks ago

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.

RytoEX commented 3 weeks ago

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.

Sean-Der commented 3 weeks ago

@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.

RytoEX commented 3 weeks ago

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.

Sean-Der commented 3 weeks ago

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.

RytoEX commented 3 weeks ago

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.