b4e96d48a2
This change introduces a new FrameCadenceAdapter class which takes the role of being a VideoFrameSinkInterface<> instead of VideoStreamEncoder. The FrameCadenceAdapter will see its functionality grow in future CLs and eventually enable screenshare capture sources to have zero hertz as the minimum capture frequency. This CL moves logic related to UMA collection and constraints into the adapter. The adapter has two major modes. Future functionality is planned to be added under the WebRTC-ZeroHertzScreenshare field trial. Unit tests are added that verify passthrough operation when WebRTC-ZeroHertzScreenshare isn't specified or disabled. Just specifying the WebRTC-ZeroHertzScreenshare field trial isn't enough to activate the feature, but the caller has to additionally configure screen content type, minimum FPS 0, and maximum FPS > 0 for the new mode. go/rtc-0hz-present Bug: chromium:1255737 Change-Id: I1799110ed40843152786ad80df10acfb83a608b1 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236682 Commit-Queue: Markus Handell <handellm@webrtc.org> Reviewed-by: Henrik Boström <hbos@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Stefan Holmer <stefan@webrtc.org> Reviewed-by: Niels Moller <nisse@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35315}
How to write code in the api/ directory
Mostly, just follow the regular style guide, but:
- Note that
api/code is not exempt from the “.hand.ccfiles come in pairs” rule, so if you declare something inapi/path/to/foo.h, it should be defined inapi/path/to/foo.cc. - Headers in
api/should, if possible, not#includeheaders outsideapi/. It’s not always possible to avoid this, but be aware that it adds to a small mountain of technical debt that we’re trying to shrink. .ccfiles inapi/, on the other hand, are free to#includeheaders outsideapi/.
That is, the preferred way for api/ code to access non-api/ code is to call
it from a .cc file, so that users of our API headers won’t transitively
#include non-public headers.
For headers in api/ that need to refer to non-public types, forward
declarations are often a lesser evil than including non-public header files. The
usual rules still apply, though.
.cc files in api/ should preferably be kept reasonably small. If a
substantial implementation is needed, consider putting it with our non-public
code, and just call it from the api/ .cc file.