Where the controller is now
AdaptiveBitrateController steers on backlog — how much video the receiver has not acknowledged — plus the send gate's shed rate and the receiver's decode queue. Congestion is a set of thresholds, with hysteresis, a cooldown, and a least-squares slope over the last six reports to catch backlog building before it crosses any level.
That slope is the one idea borrowed from Google Congestion Control, and the code says plainly that it is not GCC: no Kalman filter, no adaptive threshold, no arrival-time model. The reason is cadence. Reports arrive every 500 ms, and GCC makes ten to twenty decisions a second from per-packet arrival times. The rest of that machinery has nothing to work with at two samples a second.
The actual question
Is the 500 ms report interval a property of the problem, or just a number someone chose?
If per-frame arrival timing were available — and after #58 the receiver does stamp arrivals, it simply reports summaries on a timer — then a proper estimator becomes possible:
- inter-arrival delay variation per frame group, rather than a backlog summary twice a second
- an adaptive threshold that learns what normal looks like on this link, instead of a fixed 120 ms that means very different things on Ethernet and on congested Wi-Fi
- a trendline filter over arrival deltas, which is what GCC's over-use detector actually consumes
- an explicit increase / hold / decrease state machine rather than counters and cooldowns
Why it might genuinely be better
The current thresholds are absolute. 120 ms of backlog is catastrophic on a direct cable and unremarkable on hotel Wi-Fi, and the controller cannot tell those apart — it has no model of what this link is normally like. An adaptive threshold is exactly the missing piece.
Why it might not
More responsive control on a noisier signal can oscillate where the current one merely degrades. The existing controller is deliberately asymmetric — one bad signal cuts, every signal must agree to climb — and that conservatism is load-bearing. AdaptiveBitrateTests includes a convergence check for precisely this failure.
What a convincing attempt looks like
- Simulate first. The controller is pure and takes a sample sequence, so scenarios can be replayed offline: a link that halves, one that recovers, one that jitters without losing capacity, a still desktop sending nothing.
- Beat the current one on those traces, on time-to-react and on stability, not just one of the two.
- Then discuss the report cadence, because raising it costs bandwidth on the control channel and that has to be paid for by the result.
References worth reading first: RFC 8888, and the GCC draft (draft-ietf-rmcat-gcc).
Do not
Adopt WebRTC wholesale to get this. That was considered and rejected — the transport, pairing and framing here are deliberate, and pulling in a media stack to obtain one estimator is the tail wagging the dog.
Where the controller is now
AdaptiveBitrateControllersteers on backlog — how much video the receiver has not acknowledged — plus the send gate's shed rate and the receiver's decode queue. Congestion is a set of thresholds, with hysteresis, a cooldown, and a least-squares slope over the last six reports to catch backlog building before it crosses any level.That slope is the one idea borrowed from Google Congestion Control, and the code says plainly that it is not GCC: no Kalman filter, no adaptive threshold, no arrival-time model. The reason is cadence. Reports arrive every 500 ms, and GCC makes ten to twenty decisions a second from per-packet arrival times. The rest of that machinery has nothing to work with at two samples a second.
The actual question
Is the 500 ms report interval a property of the problem, or just a number someone chose?
If per-frame arrival timing were available — and after #58 the receiver does stamp arrivals, it simply reports summaries on a timer — then a proper estimator becomes possible:
Why it might genuinely be better
The current thresholds are absolute. 120 ms of backlog is catastrophic on a direct cable and unremarkable on hotel Wi-Fi, and the controller cannot tell those apart — it has no model of what this link is normally like. An adaptive threshold is exactly the missing piece.
Why it might not
More responsive control on a noisier signal can oscillate where the current one merely degrades. The existing controller is deliberately asymmetric — one bad signal cuts, every signal must agree to climb — and that conservatism is load-bearing.
AdaptiveBitrateTestsincludes a convergence check for precisely this failure.What a convincing attempt looks like
References worth reading first: RFC 8888, and the GCC draft (
draft-ietf-rmcat-gcc).Do not
Adopt WebRTC wholesale to get this. That was considered and rejected — the transport, pairing and framing here are deliberate, and pulling in a media stack to obtain one estimator is the tail wagging the dog.