Closed Bug 1942245 Opened 1 year ago Closed 1 year ago

OpenH264 screencapture encoding for webrtc accumulates latency

Categories

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

Unspecified
All
defect

Tracking

()

RESOLVED FIXED
136 Branch
Tracking Status
firefox136 --- fixed

People

(Reporter: pehrsons, Assigned: pehrsons)

References

Details

Attachments

(5 files)

Its use is single threaded.

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.

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.

Pushed by pehrsons@gmail.com: https://hg.mozilla.org/integration/autoland/rev/528daad05ba8 Simplify and Modernize WebrtcGmpVideoCodec code. r=aosmond https://hg.mozilla.org/integration/autoland/rev/e673cfb778ea Remove GmpInitDoneRunnable from WebrtcGmpVideoCodec. r=aosmond https://hg.mozilla.org/integration/autoland/rev/bb3495397f18 Remove DataMutex from mInputImageMap. r=aosmond https://hg.mozilla.org/integration/autoland/rev/bdb23a14a202 Limit the number of images in flight in webrtc gmp encoder. r=aosmond https://hg.mozilla.org/integration/autoland/rev/7f70d3a869d1 Always allow frame drops in libwebrtc encoders. r=webrtc-reviewers,ng
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: