1896575 - Backport upstream fix for screencast glitches under Plasma 6

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect)

Description

[Jan Grulich]

Backport fix for https://issues.webrtc.org/issues/338232699.

Upstream fix: https://webrtc-review.googlesource.com/c/src/+/349881.

With this fix we are able to drop buffers that are marked as corrupted, because they usually only carry metadata (cursor position) and we would fail to extract the frame content from them, which can cause glitches when sharing a screen.

Comment 1

[Jan Grulich]

Attachment: Bug 1896575 - WebRTC backport: Video capture PipeWire: drop corrupted PipeWire buffers r=pehrsons

This is a simple backport of an WebRTC upstream change.

Upstream commit: cfbd6b0884db2eab893831e7bde5cfe640fe52db

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4efa281b9b91
WebRTC backport: Video capture PipeWire: drop corrupted PipeWire buffers r=pehrsons,webrtc-reviewers

Comment 3

[Aron Cseh]

https://hg.mozilla.org/mozilla-central/rev/4efa281b9b91

Comment 5

[Andreas Pehrson [:pehrsons]]

Marking this as a sec-bug also, even though it's been public for a while, since it looks suspicious to have bug 1904615 be a sec-bug and link here.

Comment 6

[Daniel Veditz [:dveditz]]

This wasn't considered a sec issue by either the WebRTC or Chrome teams. Our version can be public, too.

Marking this as a sec-bug also, even though it's been public for a while, since it looks suspicious to have bug 1904615 be a sec-bug and link here.

That's fine: only folks with editbugs permission or who could already see that bug will see the linkage. We consider that an acceptable tradeoff between giving away information and having enough breadcrumbs that involved folks can ask for access to related bugs when they need it. Bug mentions in comments are always visible, of course.

That said, a security bug duped to a non-security bug does raise tracking issues that should be resolved.

1. if the dupe is not a security problem after all then we can unhide it
2. if the dupe IS a security issue then either
   a. hide the public bug if it contains clues about the security bug
   b. re-open the dupe and make it "depend on" the public bug instead

2.b. makes sure we are tracking a security bug for advisories and bounties etc.. In 2.a. the tracking moves to the formerly-public bug

Comment 7

[Andreas Pehrson [:pehrsons]]

(In reply to Daniel Veditz [:dveditz] from comment #6)

That's fine: only folks with editbugs permission or who could already see that bug will see the linkage.

That all sounds good, but I'll note I checked in a private tab when the sec bug had been duped to the non-sec bug, and I was able to see the linkage from the non-sec bug.