646fda0212
This implements RTCAudioSourceStats and RTCVideoSourceStats, both inheriting from abstract dictionary RTCMediaSourceStats: https://w3c.github.io/webrtc-stats/#dom-rtcmediasourcestats All members are implemented except for the total "frames" counter: - trackIdentifier - kind - width - height - framesPerSecond This means to make googFrameWidthInput, googFrameHeightInput and googFrameRateInput obsolete. Implemented using the same code path as the goog stats, there are some minor bugs that should be fixed in the future, but not this CL: 1. We create media-source objects on a per-track attachment basis. If the same track is attached multiple times this results in multiple media-source objects, but the spec says it should be on a per-source basis. 2. framesPerSecond is only calculated after connecting (when we have a sender with SSRC), but if collected on a per-source basis the source should be able to tell us the FPS whether or not we are sending it. Bug: webrtc:10453 Change-Id: I23705a79f15075dca2536275934af1904a7f0d39 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/137804 Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#28028}
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.