3f42fdf19f
This reverts commit 3babb8af238a531cbff27951604b09bb78b762cd. Reason for revert: - Causes regressions to transceivers, see https://crbug.com/1291956 for more information, including tests to reproduce the issue. This CL is not a pure revert. While it reverts everything else, it does keep the new enum value (kProfilePredictiveHigh444). This is as to not break Chromium which already depend on it. It is not listed in the kProfilePatterns though so the enum value should never be applicable. Original change's description: > Added support for H264 YUV444 (I444) decoding. > > Added Nutanix Inc. to the AUTHORS file. > > PS#1 is a reland of "Added support for H264 YUV444 (I444) decoding." https://webrtc-review.googlesource.com/c/src/+/234540 > > Bug: chromium:1251096 > Change-Id: I99a1b1e4d8b60192ff96f92334a430240875c66c > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235340 > Reviewed-by: Niels Moller <nisse@webrtc.org> > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > Commit-Queue: Harald Alvestrand <hta@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#35684} # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:1251096, chromium:1291956 Change-Id: Ib4d8ea4898f9832914d88e7076e6b39da0c804ca Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249791 Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Auto-Submit: Henrik Boström <hbos@webrtc.org> Reviewed-by: Henrik Boström <hbos@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35835}
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.