Repository navigation
fix(whip input): restore the default jitterbuffer latency to 200 ms - #1064
Merged
Merged
Conversation
WHIP Input defaulted jitterbuffer_latency_ms to 400 ms since #665, twice webrtcbin's own default. Restore it to 200 ms. The property stays for operators who need more headroom. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
WHIP Input sets the jitterbuffer latency to 400 ms by default (
jitterbuffer_latency_ms, since #665). That doubles the receive-side buffering over GStreamer's own default and adds 200 ms of end-to-end latency to every WHIP contribution.Change
Restore the default to 200 ms, the same as
webrtcbin's andrtpjitterbuffer'slatencydefault (gst-inspect-1.0:Default: 200). The property stays, so an operator who sees video fail to start can raise it. The block definition default, the parser fallback, the code comment and the unit test move together.WHEP Input's
jitterbuffer_latency_msis left as it is.Evidence
jitterbuffer_latency_ms_defaults_to_200calls the realparse_jitterbuffer_latency_msand fails if the fallback goes back to 400.PropertyValue::Int(200)). Not covered by a test.Tests
Ran (macOS):
cargo test --lib jitterbuffer_latency_ms: 3 passed.Not run: WHIP integration tests and a live WHIP session.
For the reviewer
#665 raised this to 400 because 200 together with
drop-on-latency(on by default) dropped the first video keyframe's packet burst on a fresh per-session pipeline, so video never started. WHIP Input has had many fixes since then (#957 and others), but nobody has rerun that case at 200. Watch for video that never starts on connect; the workaround is to raisejitterbuffer_latency_mson the block.Flows that saved 400 explicitly keep it. Flows that relied on the default get 200.
🤖 Generated with Claude Code