dff792591f
Replaces this with 2 methods instead, adding clarity. ClearAdaptationStats - Resets the adaptations statistics to 0. This is done, when the degredation is reset, for example when the preference is changed to/from BALANCED. UpdateAdaptationMaskingSettings - Updates the settings for adaptation statistics reporting. This way we don't report quality adaptations if quality scaling is not enabled (same for resolution/fps scaling). The adaptation counting inside the SendStatisticsProxy is now done in a struct that counts the totals, and then masks out these counts based on the adaptation settings. The MaskedAdaptationSteps uses optionals to hide the values we shoudn't report, while the AdaptationSteps always hold the real totals. All tests have been updated to use the Reset/Clear method as needed. Now that AdaptationCounters and AdaptSteps use the same structure, AdaptationCounters was moved to api/video and replaces AdaptSteps. The AdaptReason enum is also redundant now, and will be removed in a follow-up CL. R=hbos@webrtc.org Bug: webrtc:11392 Change-Id: Iaed6488581325d341a056b5bbf76a01c19d6c282 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/171685 Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Henrik Boström <hbos@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Commit-Queue: Evan Shrubsole <eshr@google.com> Cr-Commit-Position: refs/heads/master@{#31083}
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.