mirror of
https://github.com/mollyim/webrtc.git
synced 2025-05-16 15:20:42 +01:00
![]() Max encoder bitrate in WebRTC and OpenH264 are different settings. In WebRTC it is a cap for encoder target bitrate whilst in OpenH264 it is a peak bitrate. I.e. OpenH264 is allowed to produce bitrate up to iMaxBitrate for short time interval. That is not what WebRTC expects. https://webrtc.googlesource.com/src/+/5ee6967c4edc667688d736c27db6f2e7be00dd0a disabled encoders re-initialization on min/max bitrate change. Reinit of some HW encoders takes hundreds of milliseconds and causes video freeze. I missed that max bitrate is used by OpenH264. This caused regression described in webrtc:11543. This change sets iMaxBitrate=UNSPECIFIED_BIT_RATE (which is the default value). Settings iMaxBitrate=UNSPECIFIED_BIT_RATE disables the frame dropping logic based on that parameter. But the encoder still will drop frames based on buffer fullness, https://source.chromium.org/chromium/chromium/src/+/master:third_party/openh264/src/codec/encoder/core/src/ratectl.cpp;l=806-807 Bug: webrtc:10773, webrtc:11543 Change-Id: I728be49e0df8a0d9a8f4438299e4c7b4c1497a78 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174745 Reviewed-by: Erik Språng <sprang@webrtc.org> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> Cr-Commit-Position: refs/heads/master@{#31192} |
||
---|---|---|
.. | ||
include | ||
test | ||
DEPS | ||
h264.cc | ||
h264_color_space.cc | ||
h264_color_space.h | ||
h264_decoder_impl.cc | ||
h264_decoder_impl.h | ||
h264_encoder_impl.cc | ||
h264_encoder_impl.h | ||
h264_encoder_impl_unittest.cc | ||
h264_simulcast_unittest.cc | ||
OWNERS |