Found by review during the #597 backpressure work (sub-project 3, Task 8b). Reported, not fixed there — changing the bound changes behaviour for every GPU-direct destination and wants its own measurement.
The problem
The outgoing bitstream queue is bounded by two constants: sixty chunks, and two mebibytes. Both are memory bounds. They are doing duty as the thing that decides when a destination is too far behind, which is a latency question, and they answer it inconsistently.
The chunk cap is elastic in the throttle. The input throttle reduces the arrival rate, so the same sixty chunks represent about one second of stream at the shallowest level and roughly four seconds at the deepest. The queue therefore tolerates four times more latency exactly when the destination is struggling most.
The byte cap is elastic in the codec. Measured on this machine, the same two mebibytes is roughly two seconds of H.264 and around nine seconds of HEVC, because HEVC produces far less data for the same picture.
How it showed up
On HEVC the queue reached one and a half seconds of buffered latency while sitting at fewer than forty chunks, so the overflow path could not be reached at all on that codec — the gate could not exercise a branch that H.264 reaches readily. The same narrowing that congests one codec does not congest the other.
Why it matters
Everything else in this area was deliberately built on wall-clock buffered age, precisely because a count converted to time is wrong while the frame rate is being changed underneath it. These two caps are the remaining place where a count is standing in for time, and they are the last line of defence before a destination fault reaches the encoder.
Done when
The queue's admission bound is expressed in buffered milliseconds, with the memory caps retained purely as a safety net against pathological chunk sizes, and the resulting behaviour is measured on both codecs.
Found by review during the #597 backpressure work (sub-project 3, Task 8b). Reported, not fixed there — changing the bound changes behaviour for every GPU-direct destination and wants its own measurement.
The problem
The outgoing bitstream queue is bounded by two constants: sixty chunks, and two mebibytes. Both are memory bounds. They are doing duty as the thing that decides when a destination is too far behind, which is a latency question, and they answer it inconsistently.
The chunk cap is elastic in the throttle. The input throttle reduces the arrival rate, so the same sixty chunks represent about one second of stream at the shallowest level and roughly four seconds at the deepest. The queue therefore tolerates four times more latency exactly when the destination is struggling most.
The byte cap is elastic in the codec. Measured on this machine, the same two mebibytes is roughly two seconds of H.264 and around nine seconds of HEVC, because HEVC produces far less data for the same picture.
How it showed up
On HEVC the queue reached one and a half seconds of buffered latency while sitting at fewer than forty chunks, so the overflow path could not be reached at all on that codec — the gate could not exercise a branch that H.264 reaches readily. The same narrowing that congests one codec does not congest the other.
Why it matters
Everything else in this area was deliberately built on wall-clock buffered age, precisely because a count converted to time is wrong while the frame rate is being changed underneath it. These two caps are the remaining place where a count is standing in for time, and they are the last line of defence before a destination fault reaches the encoder.
Done when
The queue's admission bound is expressed in buffered milliseconds, with the memory caps retained purely as a safety net against pathological chunk sizes, and the resulting behaviour is measured on both codecs.