9973933d2e
This reverts commit 24192c267a40eb7d6b1850489ccdbf7a84f8ff0f. Reason for revert: Analyzed the performance regression in more detail. Most of the regression comes from the extra RtpPacketInfos-related memory allocations in every `NetEq::GetAudio()` call. Commit 1796a820f60cb9429bf4bcf13a40a41794ac8fb0 has removed roughly 2/3rds of the extra allocations from the impacted perf tests. Remaining perf impact is expected to be about "8 microseconds of CPU time per second" on the Linux benchmarking machines and "15 us per second" on Windows/Mac. There are options to optimize further but they are unlikely worth doing. Note for example that `NetEqPerformanceTest` uses the PCM codec while the real-world use cases would likely use the much heavier Opus codec. The numbers from `OpusSpeedTest` and `NetEqPerformanceTest` suggest that Opus decoding is about 10x as expensive as NetEq overall. Original change's description: > Revert "Add plumbing of RtpPacketInfos to each AudioFrame as input for SourceTracker." > > This reverts commit 3e8ef940fe86cf6285afb80e68d2a0bedc631b9f. > > Reason for revert: This CL causes a performance regression in NetEq, see https://bugs.chromium.org/p/chromium/issues/detail?id=982260. > > Original change's description: > > Add plumbing of RtpPacketInfos to each AudioFrame as input for SourceTracker. > > > > This change adds the plumbing of RtpPacketInfo from ChannelReceive::OnRtpPacket() to ChannelReceive::GetAudioFrameWithInfo() for audio. It is a step towards replacing the non-spec compliant ContributingSources that updates itself at packet-receive time, with the spec-compliant SourceTracker that will update itself at frame-delivery-to-track time. > > > > Bug: webrtc:10668 > > Change-Id: I03385d6865bbc7bfbef7634f88de820a934f787a > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139890 > > Reviewed-by: Stefan Holmer <stefan@webrtc.org> > > Reviewed-by: Minyue Li <minyue@webrtc.org> > > Commit-Queue: Chen Xing <chxg@google.com> > > Cr-Commit-Position: refs/heads/master@{#28434} > > TBR=kwiberg@webrtc.org,stefan@webrtc.org,minyue@webrtc.org,chxg@google.com > > Bug: webrtc:10668, chromium:982260 > Change-Id: I5e2cfde78c59d1123e21869564d76ed3f6193a5c > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145339 > Reviewed-by: Ivo Creusen <ivoc@webrtc.org> > Commit-Queue: Ivo Creusen <ivoc@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#28561} TBR=kwiberg@webrtc.org,stefan@webrtc.org,ivoc@webrtc.org,minyue@webrtc.org,chxg@google.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: webrtc:10668, chromium:982260 Change-Id: Ie375a0b327ee368317bf3a04b2f1415c3a974470 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146707 Reviewed-by: Stefan Holmer <stefan@webrtc.org> Commit-Queue: Chen Xing <chxg@google.com> Cr-Commit-Position: refs/heads/master@{#28664}
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.