OpenH264 screencapture encoding for webrtc accumulates latency
Categories
(Core :: WebRTC: Audio/Video, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox136 | --- | fixed |
People
(Reporter: pehrsons, Assigned: pehrsons)
References
Details
Attachments
(5 files)
Once started, click to view "Encoder Stats" and keep an eye on the "Avg Enc Time" which builds up.
| Assignee | ||
Comment 1•1 year ago
|
||
| Assignee | ||
Comment 2•1 year ago
|
||
| Assignee | ||
Comment 3•1 year ago
|
||
Its use is single threaded.
| Assignee | ||
Comment 4•1 year ago
|
||
Frames from screen capture are often large and with OpenH264 in screen content
mode, encoding them takes several times longer than encoding non-screen content.
This can accumulate a growing backlog of frames to be encoded. Libwebrtc doesn't
adapt fast to a high encoder latency, so limit the number of frames in flight
instead.
This patch also adds reporting of frames that have been dropped, either by
OpenH264 or by the WebrtcGmpVideoEncoder.
| Assignee | ||
Comment 5•1 year ago
|
||
If anything frame drops should not be prohibited when encoding screen capture,
since we don't want to downscale screen capture frames to keep text legible.
Comment 7•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/528daad05ba8
https://hg.mozilla.org/mozilla-central/rev/e673cfb778ea
https://hg.mozilla.org/mozilla-central/rev/bb3495397f18
https://hg.mozilla.org/mozilla-central/rev/bdb23a14a202
https://hg.mozilla.org/mozilla-central/rev/7f70d3a869d1
Description
•