1f2f5dc951
2 main reasons: 1. Packet sizes are much different thus a lost audio packet should not be treated similar to a lost video packet. In low bandwidth/traffic policing scenario, the number of send packet is few, thus the computed loss can be imprecise. 2. Given a candidate bandwidth estimate, the objective function (how good the candidate is) is computed by recomputing loss rate = send rate/estimate bandwith + inherent loss. It means the objective function is byte based rather than packet based. Potential risk: the current algorithm params are tuned based on packet count, thus it might not work with byte count, which is much higher than packet count. The change is under field trial and disabled by default. Bug: webrtc:12707 Change-Id: I8b832e7920d2b4cadcd4a072b3a4d4f26a213a20 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325065 Reviewed-by: Per Kjellander <perkj@webrtc.org> Commit-Queue: Diep Bui <diepbp@webrtc.org> Cr-Commit-Position: refs/heads/main@{#41013}
WebRTC is a free, open software project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.
Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.
The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others.
Development
See here for instructions on how to get started developing with the native code.
Authoritative list of directories that contain the native API header files.
More info
- Official web site: http://www.webrtc.org
- Master source code repo: https://webrtc.googlesource.com/src
- Samples and reference apps: https://github.com/webrtc
- Mailing list: http://groups.google.com/group/discuss-webrtc
- Continuous build: https://ci.chromium.org/p/webrtc/g/ci/console
- Coding style guide
- Code of conduct
- Reporting bugs
- Documentation