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: ["*"]