Part of the streaming-performance work (umbrella #102). Structural, needs a state-machine design — file as its own item.
Problem
Encoder params are decided once at boot and never change (IOSAgent.ts:278, AndroidAgent.ts:517). The only congestion response is drop-to-keyframe + on-demand IDR. The signals for adaptation are already collected but not wired to a control loop:
- relay drop rate /
bufferedAmount (bandwidth bottleneck)
- browser
FrameLatencyTracker decodeMs (decode-CPU bottleneck — directly addresses the heterogeneous-viewer-hardware result from the W2 LAN measurements)
Proposal
A step-down/up control loop feeding both signals back to the agent (bitrate → fps → resolution). VideoToolbox supports runtime AverageBitRate changes, so start with the iOS / gRPC encode paths. A full WebRTC GCC implementation is not required.
Design (state machine + hysteresis to avoid oscillation) should be worked out in a dedicated plan before implementation. (Review §6.3 S1.)
Part of the streaming-performance work (umbrella #102). Structural, needs a state-machine design — file as its own item.
Problem
Encoder params are decided once at boot and never change (
IOSAgent.ts:278,AndroidAgent.ts:517). The only congestion response is drop-to-keyframe + on-demand IDR. The signals for adaptation are already collected but not wired to a control loop:bufferedAmount(bandwidth bottleneck)FrameLatencyTrackerdecodeMs(decode-CPU bottleneck — directly addresses the heterogeneous-viewer-hardware result from the W2 LAN measurements)Proposal
A step-down/up control loop feeding both signals back to the agent (bitrate → fps → resolution). VideoToolbox supports runtime
AverageBitRatechanges, so start with the iOS / gRPC encode paths. A full WebRTC GCC implementation is not required.Design (state machine + hysteresis to avoid oscillation) should be worked out in a dedicated plan before implementation. (Review §6.3 S1.)