ZeroHertzAdapterMode: handle key frame requests.
Under zero-hertz mode, provided that a frame arrived to the
VideoStreamEncoder, the receiver may experience up to a second
between incoming frames. This results in key frame requests getting
serviced with that delay, which is undesired.
What's worse is also the fact that if no frame ever arrived to the
VideoStreamEncoder, it will not service the keyframe requests at all
until the first frame comes.
This change introduces VideoSourceInterface::RequestRefreshFrame
which results in a refresh frame being sent from complying sources.
The method is used under zero-hertz mode from the VideoStreamEncoder
when frames didn't arrive to it yet (with changes to the zero-hertz
adapter).
With this change, when the frame adapter has received at least one
frame, it will conditionally repeat the last frame in response to the
key frame request.
go/rtc-0hz-present
Bug: chromium:1255737
Change-Id: I6f97813b3a938747357d45e5dda54f759129b44d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242361
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35562}
diff --git a/video/video_source_sink_controller.cc b/video/video_source_sink_controller.cc
index 810a4ff..cf3b649 100644
--- a/video/video_source_sink_controller.cc
+++ b/video/video_source_sink_controller.cc
@@ -75,6 +75,12 @@
return source_ != nullptr;
}
+void VideoSourceSinkController::RequestRefreshFrame() {
+ RTC_DCHECK_RUN_ON(&sequence_checker_);
+ if (source_)
+ source_->RequestRefreshFrame();
+}
+
void VideoSourceSinkController::PushSourceSinkSettings() {
RTC_DCHECK_RUN_ON(&sequence_checker_);
if (!source_)
