-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
obs-webrtc should default to main profile #10821
Comments
@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. |
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. 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. |
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. 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. |
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.
Even if that were the case, as we are in beta right now, I am focused specifically on regressions, which this is not. |
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
Anything else we should know?
No response
The text was updated successfully, but these errors were encountered: