Confirmed live in mediamtx logs: the HLS muxer for a browser-published
stream gets created then immediately destroyed — 'the stream doesn't
contain any supported codec, which are currently AV1, VP9, H265, H264,
Opus, MPEG-4 Audio, KLV'. Chrome's getUserMedia()/getDisplayMedia()
default video codec for WebRTC is VP8, which isn't in that list. The
WHIP publish itself succeeds (stream correctly shows live, mediamtx's
own API confirms bytes arriving) so this was easy to miss — only
hls/live/<id>/index.m3u8 silently 404s with 'muxer is waiting to be
created' forever.
Fixed with RTCRtpTransceiver.setCodecPreferences(), reordering the
video codec list so H264 is offered first — falls through safely if
unavailable. Matches what OBS already sends over RTMP, so recording and
HLS both stay on the one already-tested codec instead of gaining a
second, broken one.