This reverts commit 209ac5fd95.
Reason for revert: Breaks WebRTC autoroll presubmit:
https://chromium-review.googlesource.com/c/chromium/src/+/3134502
Example failure https://ci.chromium.org/ui/p/chromium/builders/try/mac-rel/775468/overview
../../buildtools/third_party/libc++/trunk/include/__memory/unique_ptr.h:725:32: error: allocating an object of abstract class type 'testing::NiceMock<blink::(anonymous namespace)::MockTransformableVideoFrame>'
return unique_ptr<_Tp>(new _Tp(_VSTD::forward<_Args>(__args)...));
^
../../third_party/blink/renderer/platform/peerconnection/rtc_encoded_video_stream_transformer_test.cc:69:26: note: in instantiation of function template specialization 'std::make_unique<testing::NiceMock<blink::(anonymous namespace)::MockTransformableVideoFrame>>' requested here
auto mock_frame = std::make_unique<NiceMock<MockTransformableVideoFrame>>();
^
../../third_party/webrtc/api/frame_transformer_interface.h:36:19: note: unimplemented pure virtual method 'GetPayloadType' in 'NiceMock'
virtual uint8_t GetPayloadType() const = 0;
^
Original change's description:
> frame transformer: make GetPayloadType pure virtual again
>
> after chrome was updated in
> https://chromium-review.googlesource.com/c/chromium/src/+/3103323
>
> BUG=webrtc:13077
>
> Change-Id: I7e5ff6aaae81c5dcfbaa41b09ef01bc95bb7251a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230143
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Philipp Hancke <philipp.hancke@googlemail.com>
> Cr-Commit-Position: refs/heads/main@{#34877}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:13077
Change-Id: I6b2e4e2804890c857f1f832a6a4faa614ec026c4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230920
Reviewed-by: Olga Sharonova <olka@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Olga Sharonova <olka@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34891}
Note that api/ code is not exempt from the “.h and .cc files come in
pairs” rule, so if you declare something in api/path/to/foo.h, it should be
defined in api/path/to/foo.cc.
Headers in api/ should, if possible, not #include headers outside api/.
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.
.cc files in api/, on the other hand, are free to #include headers
outside api/.
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.
eb89027733