Skip to content
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

(30.1.2) WHIP streaming will cause serious picture damage when a tiny number of packets are lost. #10564

Open
MarcoMayCry opened this issue Apr 18, 2024 · 5 comments

Comments

@MarcoMayCry
Copy link

MarcoMayCry commented Apr 18, 2024

Operating System Info

macOS 14

Other OS

Windows11

OBS Studio Version

30.1.2

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/CJnSlQPXikGyq54D

OBS Studio Crash Log URL

No response

Expected Behavior

(OBS 30.0.2) Normal WHIP live broadcast can be performed under slight packet loss environment (<5%).
image

Current Behavior

(OBS 30.1.2) Serious screen blur will occur when performing WHIP live broadcast in a slight packet loss environment.
image

Steps to Reproduce

  1. Start WHIP streaming
  2. Set 3%~5% packet loss
  3. Play live stream

Anything else we should know?

This is a known bug in the libdatachannel library v0.20.1 (the version that the latest version of obs relies on). This will cause the NACK retransmission packet to be damaged, which will lead to a blurry screen or a green screen in a slight packet loss environment.
The current libdatachannel library v0.20.2 version has fixed this bug, see: paullouisageneau/libdatachannel#1118.
Can this change be incorporated in the latest obs version?

@MarcoMayCry MarcoMayCry changed the title (30.1.2) WHIP live broadcast will cause serious picture damage when packets are lost. (30.1.2) WHIP streaming will cause serious picture damage when a tiny number of packets are lost. Apr 18, 2024
@dlwlr3ma
Copy link

nice, i am facing the same question, how to solve it??

@RytoEX
Copy link
Member

RytoEX commented Apr 18, 2024

Can this change be incorporated in the latest obs version?

We always investigate dependency updates between versions.

@MarcoMayCry
Copy link
Author

Can this change be incorporated in the latest obs version?

We always investigate dependency updates between versions.

Thanks, hope this fix can be merged soon

@MarcoMayCry MarcoMayCry reopened this Apr 19, 2024
@kaitlynia
Copy link

kaitlynia commented Apr 29, 2024

Wow, I am incredibly relieved to see this issue posted here. I thought somewhere along the way, either from OBS to MediaMTX, or from MediaMTX to my custom WHEP client, I was getting corrupted frames. But no, it's just a bug with OBS! Only here to report that I am having the same issue, and it tends to be quite common unless I have a nearly-perfect connection.

EDIT: Thought I could provide more examples of this type of corruption. Sometimes it's specific regions of the frames and other times it's spread throughout. Seems I have it worse than OP though 😢

image
image

@MarcoMayCry
Copy link
Author

哇,看到这里发布这个问题我感到非常欣慰。我认为在整个过程中,无论是从 OBS 到 MediaMTX,还是从 MediaMTX 到我的自定义 WHEP 客户端,我都遇到了损坏帧的。但不是,这只是 OBS 的一个错误!只是在这里报告我遇到了同样的问题,而且它往往很常见,除非我有近乎完美的连接。

编辑:我想我可以提供更多此类犯罪的例子。有时它是框架的特定区域,有时它遍布整个框架。看来我的情况比OP还糟糕😢

图像 图像

Indeed, that's the case. Unless there is absolutely no packet loss on the network, there will be video corruption. The specific nature of the corruption depends on the location of the lost packets within the video frame. If it occurs in an I-frame within H.264, it will lead to artifacting across a Group of Pictures, whereas with AV1, it might result in an inability to decode, causing a freeze.
I expect that the new version of OBS will fix this issue. Currently, it seems that all users utilizing WHIP are experiencing this anomaly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants