4d9df38d82
This CL changes the API for webrtc::VideoEncoder. There is a legacy method called SetRates(). This is indicated as being deprecated, but there seem to be a number of usages still left. Then there is the new SetRateAllocation() method which takes a VideoBitrateAllocation instance instead of a single target bitrate. This CL adds a new version of SetRates() which moves all the existing parameters in a RateControlParameters struct, and adds a bandwidth allocation signal. The intent of this signal is to allow the encoder to know how close to the target it needs to stay. If the encoder rate is network restricted, it will need to be more aggressive in keep the rate down and possibly drop frames. If there is some margin for overshoot, it might do different trade-offs. Furthermore, the frame rate signal is changes from an integer to a floating point type in order to get more precise rates at low frame rates and the return type has been changed to void since the only use of the previous values to log it and that is better done inside encoder where the error condition originates. The intent is to properly deprecate the "old" SetRates() / SetRateAllocation() methods, send out a PSA and then remove them in two weeks. Changes required by users should be trivial, as using the new headroom signal is optional. Bug: webrtc:10155, webrtc:10481 Change-Id: I4f797b0b0c73086111869ef4ee5f42bf530f5fde Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/129724 Commit-Queue: Erik Språng <sprang@webrtc.org> Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org> Cr-Commit-Position: refs/heads/master@{#27314}
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.