cbf5122333
When requested_resolution uses a different aspect ratio than the source the encoder will restrict the frame without changing its aspect ratio, e.g. a 60x30 input frame that is restricted to 30x30 results in 30x15, not 30x30. While this logic works correctly in isolation, if the source also adapts the frame size based on the sink_wants.requested_resolution that is signaled back to the source, then the source will produce stretched 30x30 prior to the encoder which happily sends 30x30 not knowing any wiser. This is incompatible with the spec[1] and makes this WPT[2] fail. The correct behavior is to NOT signal the requested_resolution back to the source, the encoder already configures the correct resolution so this isn't actually needed and the source shouldn't need to know this API. In order not to break downstream projects, the new behavior is landed behind a flag and both behaviors are tested with TEST_P. This unblocks launching scaleResolutionDownTo API on Web. Migrating from old to new code path and deleting the flag is a follow-up AI: webrtc:366284861. [1] https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-scaleresolutiondownto [2] https://chromium-review.googlesource.com/c/chromium/src/+/5853944 # Relying on previous green runs for confidence due to purple bots atm, # see b/367211396 NOTRY=True NOPRESUBMIT=True Bug: webrtc:366067962, webrtc:366284861 Change-Id: I7fd1016e9cc6f0b0b9b8c23b0708e521f8e12642 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362541 Reviewed-by: Henrik Andreassson <henrika@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/main@{#43024}
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/.- Avoid structs in api, prefer classes.
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.
Avoid defining api with structs as it makes harder for the api to evolve. Your struct may gain invariant, or change how it represents data. Evolving struct from the api is particular challenging as it is designed to be used in other code bases and thus needs to be updated independetly from its usage. Class with accessors and setters makes such migration safer. See Google C++ style guide for more.
If you need to evolve existent struct in api, prefer first to convert it into a class.