GCC refactoring
Description
This PR refactors the GCC implementation using the new API introduced in #300. Currently, users are responsible for creating a SendSideController, reading CCFB reports from the attributes, and passing them to the SendSideController. This does not include pacing, which needs to be handled separately. Since the new controller does not need to read or pace outgoing packets, we no longer need the cumbersome callback API to get a pointer to the bandwidth estimator.
This refactoring also cleans up the architecture of the bandwidth estimator. It no longer uses the weird pipelining structure and no longer uses any concurrency. This should also fix/close some of the open issues and PRs like #271, #299, #260, #221, #296.
This should not be merged before #300 is merged. A follow-up PR to this one will clean up the old pkg/gcc directory to use this version.
Codecov Report
Attention: Patch coverage is 55.21327% with 189 lines in your changes missing coverage. Please review.
Project coverage is 70.39%. Comparing base (
73f7ccf) to head (7db4a7e).
Additional details and impacted files
@@ Coverage Diff @@
## master #306 +/- ##
==========================================
- Coverage 71.69% 70.39% -1.31%
==========================================
Files 79 92 +13
Lines 4742 5164 +422
==========================================
+ Hits 3400 3635 +235
- Misses 1203 1389 +186
- Partials 139 140 +1
| Flag | Coverage Δ | |
|---|---|---|
| go | 70.29% <55.21%> (-1.41%) |
:arrow_down: |
| wasm | 68.55% <55.21%> (-1.09%) |
:arrow_down: |
Flags with carried forward coverage won't be shown. Click here to find out more.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
🚀 New features to boost your workflow:
- ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
This PR is basically a rewrite of the bandwidth estimator without using any interceptor-specific concepts. Since it does not add an interceptor and can be used without interceptors, what do you think of moving the package into a separate repository which can then also hold alternative bandwidth estimator implementations? @Sean-Der @aalekseevx @JoeTurki
@mengelbart, I like this idea. I think it would be convenient to keep the BWE implementation and tests in the same place. Maybe we can use the existing pion/bwe-test repository for this and rename it to pion/bwe?
Hello, I agree with @aalekseevx, let's see what Sean see.
pion/bwe sounds good. Unfortunately, I never got to really finish the test suite there, but it might be a good opportunity to finally straighten that out.
I created https://github.com/pion/bwe-test/pull/61