From 17e3ac747ce86663b5b0a1a2c74ffe32935aa14c Mon Sep 17 00:00:00 2001 From: ssmithx Date: Tue, 11 Aug 2026 11:45:13 +0000 Subject: [PATCH] =?UTF-8?q?fix:=20switch=20HLS=20back=20to=20lowLatency=20?= =?UTF-8?q?=E2=80=94=20mpegts=20can't=20mux=20VP8/VP9=20from=20browser=20p?= =?UTF-8?q?ublish?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit mpegts (moved to earlier for OBS B-frame stability) only supports H264. Browser (WHIP) publishing sends VP8 or VP9 depending on the machine's available encoders, which mpegts can't mux at all — confirmed live, 'the MPEG-TS variant of HLS supports H264 video only' crash loop. lowLatency supports the broader codec set browser publishing actually needs. Real risk, not resolved by this alone: lowLatency is what caused the original OBS B-frame muxer crashes this session already fixed once by moving to mpegts. If that recurs, the correct fix is two MediaMTX instances (one per hlsVariant) since it's a global, not per-path, setting — not flip-flopping between the two. --- mediamtx/mediamtx.yml | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/mediamtx/mediamtx.yml b/mediamtx/mediamtx.yml index 63df3d3..31e2a8e 100644 --- a/mediamtx/mediamtx.yml +++ b/mediamtx/mediamtx.yml @@ -25,13 +25,22 @@ rtmpAddress: :1935 hls: yes hlsAddress: :8888 -# 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 +# Switched from mpegts back to lowLatency (2026-08-11): mpegts can only mux +# H264, and browser (WHIP) publishing sends VP8/VP9 depending on the +# machine's available encoders — confirmed live, mpegts crashed with "the +# MPEG-TS variant of HLS supports H264 video only" for a VP9 browser stream. +# lowLatency supports AV1/VP9/H265/H264/Opus, so it's required for browser +# publishing to produce any HLS output at all. +# +# Known risk: this is the variant that was moved AWAY from earlier — 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 OBS 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. If that recurs, the real fix is running two MediaMTX instances +# (mpegts for RTMP/OBS, lowLatency for WHIP/browser) since hlsVariant is a +# global setting with no per-path override — not flipping back and forth. +hlsVariant: lowLatency hlsAlwaysRemux: yes hlsAllowOrigins: ["*"]