fix: switch HLS output from low-latency to standard mode
lowLatency's small per-part buffering window has very little tolerance for B-frame reordering (common in typical OBS encoder presets) — a real test stream crashed the muxer twice in ~2 minutes with "too many reordered frames" / "unable to extract DTS", tearing down and rebuilding HLS output each time (visible to viewers as buffering/stalls). Standard HLS buffers a full segment before finalizing instead of near-real-time parts, absorbing that jitter. Confirmed via a live test stream afterward: zero muxer crashes over several minutes, vs. two in the first two minutes before. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
@@ -25,7 +25,13 @@ rtmpAddress: :1935
|
|||||||
|
|
||||||
hls: yes
|
hls: yes
|
||||||
hlsAddress: :8888
|
hlsAddress: :8888
|
||||||
hlsVariant: lowLatency
|
# Standard HLS, not lowLatency: LL-HLS's small per-part buffering window has very little
|
||||||
|
# tolerance for B-frame reordering (common in most OBS encoder presets), and a real test
|
||||||
|
# stream crashed the muxer twice in ~2 minutes with "too many reordered frames" / "unable to
|
||||||
|
# extract DTS" once frame timing got even slightly irregular. Standard HLS buffers a full
|
||||||
|
# segment before finalizing, which absorbs that jitter — a few extra seconds of latency
|
||||||
|
# instead of intermittent muxer crashes / viewer buffering.
|
||||||
|
hlsVariant: mpegts
|
||||||
hlsAlwaysRemux: yes
|
hlsAlwaysRemux: yes
|
||||||
hlsAllowOrigins: ["*"]
|
hlsAllowOrigins: ["*"]
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user