webrtc/api/video/video_source_interface.h
Markus Handell 2e0f4f0f37 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}
2021-12-21 19:52:56 +00:00

107 lines
4.4 KiB
C++

/*
* Copyright (c) 2016 The WebRTC project authors. All Rights Reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
* tree. An additional intellectual property rights grant can be found
* in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
#ifndef API_VIDEO_VIDEO_SOURCE_INTERFACE_H_
#define API_VIDEO_VIDEO_SOURCE_INTERFACE_H_
#include <limits>
#include <vector>
#include "absl/types/optional.h"
#include "api/video/video_sink_interface.h"
#include "rtc_base/system/rtc_export.h"
namespace rtc {
// VideoSinkWants is used for notifying the source of properties a video frame
// should have when it is delivered to a certain sink.
struct RTC_EXPORT VideoSinkWants {
struct FrameSize {
FrameSize(int width, int height) : width(width), height(height) {}
FrameSize(const FrameSize&) = default;
~FrameSize() = default;
int width;
int height;
};
VideoSinkWants();
VideoSinkWants(const VideoSinkWants&);
~VideoSinkWants();
// Tells the source whether the sink wants frames with rotation applied.
// By default, any rotation must be applied by the sink.
bool rotation_applied = false;
// Tells the source that the sink only wants black frames.
bool black_frames = false;
// Tells the source the maximum number of pixels the sink wants.
int max_pixel_count = std::numeric_limits<int>::max();
// Tells the source the desired number of pixels the sinks wants. This will
// typically be used when stepping the resolution up again when conditions
// have improved after an earlier downgrade. The source should select the
// closest resolution to this pixel count, but if max_pixel_count is set, it
// still sets the absolute upper bound.
absl::optional<int> target_pixel_count;
// Tells the source the maximum framerate the sink wants.
int max_framerate_fps = std::numeric_limits<int>::max();
// Tells the source that the sink wants width and height of the video frames
// to be divisible by `resolution_alignment`.
// For example: With I420, this value would be a multiple of 2.
// Note that this field is unrelated to any horizontal or vertical stride
// requirements the encoder has on the incoming video frame buffers.
int resolution_alignment = 1;
// The resolutions that sink is configured to consume. If the sink is an
// encoder this is what the encoder is configured to encode. In singlecast we
// only encode one resolution, but in simulcast and SVC this can mean multiple
// resolutions per frame.
//
// The sink is always configured to consume a subset of the
// webrtc::VideoFrame's resolution. In the case of encoding, we usually encode
// at webrtc::VideoFrame's resolution but this may not always be the case due
// to scaleResolutionDownBy or turning off simulcast or SVC layers.
//
// For example, we may capture at 720p and due to adaptation (e.g. applying
// `max_pixel_count` constraints) create webrtc::VideoFrames of size 480p, but
// if we do scaleResolutionDownBy:2 then the only resolution we end up
// encoding is 240p. In this case we still need to provide webrtc::VideoFrames
// of size 480p but we can optimize internal buffers for 240p, avoiding
// downsampling to 480p if possible.
//
// Note that the `resolutions` can change while frames are in flight and
// should only be used as a hint when constructing the webrtc::VideoFrame.
std::vector<FrameSize> resolutions;
};
inline bool operator==(const VideoSinkWants::FrameSize& a,
const VideoSinkWants::FrameSize& b) {
return a.width == b.width && a.height == b.height;
}
template <typename VideoFrameT>
class VideoSourceInterface {
public:
virtual ~VideoSourceInterface() = default;
virtual void AddOrUpdateSink(VideoSinkInterface<VideoFrameT>* sink,
const VideoSinkWants& wants) = 0;
// 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
#endif // API_VIDEO_VIDEO_SOURCE_INTERFACE_H_