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}
This commit is contained in:
Markus Handell
2021-12-21 19:14:58 +01:00
committed by WebRTC LUCI CQ
parent 875df7e140
commit 2e0f4f0f37
11 changed files with 325 additions and 37 deletions

View File

@ -97,6 +97,10 @@ class VideoSourceInterface {
// RemoveSink must guarantee that at the time the method returns,
// there is no current and no future calls to VideoSinkInterface::OnFrame.
virtual void RemoveSink(VideoSinkInterface<VideoFrameT>* sink) = 0;
// Request underlying source to capture a new frame.
// TODO(crbug/1255737): make pure virtual once downstream projects adapt.
virtual void RequestRefreshFrame() {}
};
} // namespace rtc