2fec64484f
There are now multiple ways to configure VP9 L1Tx: - Legacy API: configure legacy SVC and disable encodings, this gets interpreted as disabling spatial layers (non-standard API hack). - Standard API: configure scalability_mode. This can be done either with a single encoding or multiple encodings. As long as only one encoding is active we get a single L1Tx ssrc, same as legacy API. Due to a bug, the ApplySpatialLayerBitrateLimits() logic which tweaks bitrates was only applied in the legacy API code path, not the standard API code path, despite both code paths configuring L1Tx. The issue is that IsSimulcastOrMultipleSpatialLayers() was checking if `number_of_streams == 1`. This is true in legacy code path but not standard code path. The fix is to look at `numberOfSimulcastStreams == 1` instead, which is set to the correct value regardless of code path used. This CL adds comments documenting the difference between `number_of_streams` and `numberOfSimulcastStreams` to reduce the risk of more mistakes like this in the future. Bug: chromium:1455039, b:279161263 Change-Id: I69789b68cc5d45ef1b3becd310687c8dec8e7c87 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308722 Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40287}
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.