7968530418
There are edge cases where the caching of encoder info will cause issues. For instance if a sub-encoder fails en Encode call and falls back to some other implementation, or if the fps targets shift due to SetRates() triggering new layers to be enabled. This CL forces a complete rebuild on every call to GetEncoderInfo(). It also adds new logging of when the info changes, as debugging issues can be very time consuming if we can't tell that happened. Bug: webrtc:11000 Change-Id: I7ec7962a589ccba0e188e60a11f851c9de874fab Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/160960 Commit-Queue: Erik Språng <sprang@webrtc.org> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29938}
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.