From eb20e88f582e1ddb0f32e8acf90cd9e77ec63b8f Mon Sep 17 00:00:00 2001 From: ssmithx Date: Fri, 31 Jul 2026 11:08:20 +0000 Subject: [PATCH] fix: switch HLS output from low-latency to standard mode MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- mediamtx/mediamtx.yml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/mediamtx/mediamtx.yml b/mediamtx/mediamtx.yml index ceafde2..8a48890 100644 --- a/mediamtx/mediamtx.yml +++ b/mediamtx/mediamtx.yml @@ -25,7 +25,13 @@ rtmpAddress: :1935 hls: yes 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 hlsAllowOrigins: ["*"]