8f319a3472
This reverts commit fab3460a821abe336ab610c6d6dfc0d392dac263. Reason for revert: fix downstream instead Original change's description: > Revert "Reland "Add plumbing of RtpPacketInfos to each AudioFrame as input for SourceTracker."" > > This reverts commit 9973933d2e606d64fcdc753acb9ba3afd6e30569. > > Reason for revert: breaking downstream projects and not reviewed by direct owners > > Original change's description: > > Reland "Add plumbing of RtpPacketInfos to each AudioFrame as input for SourceTracker." > > > > 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} > > TBR=kwiberg@webrtc.org,stefan@webrtc.org,ivoc@webrtc.org,minyue@webrtc.org,chxg@google.com > > Change-Id: I652cb0814d83b514d3bee34e65ca3bb693099b22 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: webrtc:10668, chromium:982260 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146712 > Reviewed-by: Alessio Bazzica <alessiob@webrtc.org> > Commit-Queue: Alessio Bazzica <alessiob@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#28671} TBR=alessiob@webrtc.org,kwiberg@webrtc.org,stefan@webrtc.org,ivoc@webrtc.org,minyue@webrtc.org,chxg@google.com Change-Id: Id43b7b3da79b4f48004b41767482bae1c1fa1e16 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: webrtc:10668, chromium:982260 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146713 Reviewed-by: Alessio Bazzica <alessiob@webrtc.org> Commit-Queue: Alessio Bazzica <alessiob@webrtc.org> Cr-Commit-Position: refs/heads/master@{#28672}
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.