04e1bab1b3
This interface has a couple of issues. Primarily for me, it makes it difficult work with the paced sender as we need to either temporarily release a lock or force a thread-handover in order to avoid a cyclic lock order. For video in particular, its behavior is also falky since header sizes can vary not only form frame to frame, but from packet to packet within a frame (e.g. TimingInfo extension is only on the last packet, if set). On bitrate allocation, the last reported value is picked, leading to timing issues affecting the bitrate set. This CL removes the callback interface and instead we simply poll the RTP module for a packet overhead. This consists of an expected overhead based on which non-volatile header extensions are registered (so for instance AbsoluteCaptureTime is disregarded since it's only populated once per second). The overhead estimation is a little less accurate but instead simpler and deterministic. Bug: webrtc:10809 Change-Id: I2c3d3fcca6ad35704c4c1b6b9e0a39227aada1ea Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173704 Commit-Queue: Erik Språng <sprang@webrtc.org> Reviewed-by: Stefan Holmer <stefan@webrtc.org> Reviewed-by: Ali Tofigh <alito@webrtc.org> Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org> Reviewed-by: Per Åhgren <peah@webrtc.org> Cr-Commit-Position: refs/heads/master@{#31185}
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.