From 15766834f1fdbe0a33a04e8d38d7d533a0f0bd3a Mon Sep 17 00:00:00 2001 From: Mollusk Date: Thu, 21 May 2026 05:26:53 -0400 Subject: [PATCH] Revert "viewer HTTP: Content-Type application/octet-stream, not video/mp2t" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This reverts commit 0a253bd91908539ec8503bedee5874b94c95e536. The Content-Type change was a misdiagnosis. The real cause of VLC's "no demux modules matched" was a missing `vlc-plugin-dvb` package on the test machine — Arch/CachyOS ship the MPEG-TS demuxer plugin (`libts_plugin.so`) in a separate package from `vlc`. Without it, VLC falls through to the PS demuxer and misidentifies the H.264 stream. With the package installed, `video/mp2t` opens cleanly. `video/mp2t` is the correct Content-Type for an MPEG-TS stream and is what we should be sending. Documentation of the package requirement and a runtime check follow in a separate commit. Co-Authored-By: Claude Opus 4.7 --- src/host/wayland.rs | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/src/host/wayland.rs b/src/host/wayland.rs index 9459630..bb30d0e 100644 --- a/src/host/wayland.rs +++ b/src/host/wayland.rs @@ -225,15 +225,8 @@ async fn serve_capture(listener: TcpListener, mut gst_stdout: ChildStdout) { return; } - // Content-Type intentionally application/octet-stream, not video/mp2t. - // VLC eagerly maps video/mp2t to demux="ts" and bypasses content - // probing; its ts demuxer's Open then fails on the live HTTP stream - // with "no demux modules matched" and the input never opens. With a - // non-video Content-Type, VLC falls back to byte-probing, which finds - // the TS sync pattern and opens cleanly. mpv probes regardless of - // Content-Type, so it's unaffected. const RESPONSE: &[u8] = b"HTTP/1.1 200 OK\r\n\ - Content-Type: application/octet-stream\r\n\ + Content-Type: video/mp2t\r\n\ Cache-Control: no-cache, no-store\r\n\ Connection: close\r\n\ \r\n";