ULPFEC causing framerate issues on Chrome, in an RTMP-provided, WebRTC-published stream

[trysdyn]

Describe the bug
If you have ULPFEC enabled on an application, and ingest a stream on that application via RTMP, that stream will have massive framerate issues (roughly 3fps) on the newest Google Chrome (131.0.6778.140). Chromium on Linux does not appear to be impacted; Chrome on Windows is.

This issue started in the past week somewhere, with a Chrome update. It might be a Chrome bug but I'm uncertain.

To Reproduce
Steps to reproduce the behavior:

1. Have an application configured with ULPFEC enabled on the WebRTC publisher; and an RTMP provider. This application may need to bypass video to trigger the bug; my server cannot do transcoding for me to test otherwise.
2. Push a stream to this application using RTMP. I'm using OBS for this
3. View this stream's WebRTC publisher in an OvenPlayer on newest Google Chrome. The Ovenplayer demo works for this
4. Witness an extremely low framerate

All of these components (ULPFEC, RTMP ingest, WebRTC playback, newest Chrome on Windows) are required to replicate. It's that specific of an issue.

Expected behavior
Smooth framerate

Server (please complete the following information):

• OS: Archlinux
• OvenMediaEngine Version: 0.17.2
• Branch: Release artifact

Player (please complete the following information):

• Device: PC
• OS: Windows 10
• Browser Google Chrome
• Version 131.0.6778.140

Additional context
Replicated by two other individuals as part of a video production project. Verified to impact only Chrome, only with ULPFEC enabled, only if the publish side is WebRTC and only if the provider is RTMP.

I understand my symptoms looks exactly like a stream with bframes in it. I promise you I have bframes disabled :)

I apologize for the extremely weird and specific bug report. I'm very confused by this as well.

[getroot]

Thanks for the report. I'll look into this, but it might take some time. In the meantime, I'd recommend disabling the ulpfec feature. H.264 + ulpfec isn't very efficient anyway. Consider using webrtc/tcp as well.