[midzdotdev]

Addresses #601.

What I saw: a YouTube video with AI-dubbed audio, sent with the AirPlay button in Safari (macOS, youtube.com), plays its French dub. -lang and $LANGUAGE make no difference.

Cause: Safari hands over a plain https://manifest.googlevideo.com/api/manifest/hls_variant/... URL, which goes straight to playbin. That master playlist has no EXT-X-MEDIA audio renditions: each resolution is listed once per audio language as a separate variant stream, marked only by YT-EXT-AUDIO-CONTENT-ID and YT-EXT-XTAGS (acont=original / acont=dubbed-auto, lang=...). The player takes the highest BANDWIDTH, which is a dub by a few bits per second. Details and numbers are in #601.

What this does

• select_yt_web_manifest_language() in lib/airplay_video.c filters such a master playlist down to the variant streams of one audio language. It reuses strict_match_language() / match_language(), so the choice follows the app path: a strict match with the -lang list, else a match with the system languages, else the language marked acont=original. Variant streams with no language attributes are the original audio: they are kept with the original language, and are all that is kept when nothing is marked as the original. It returns NULL ("play unchanged") when there is nothing to choose, and for anything malformed (a variant without a URI line, relative URIs, more than 64 languages).
• For plain URLs of the form https://[*.]googlevideo.com/.../manifest/hls_variant/..., uxplay.cpp fetches the playlist (video_renderer_fetch_text(): source element into appsink, 5 s overall limit, 4 MiB cap), filters it, writes the copy to a 0600 file in the user runtime directory and gives playbin its file:// URI. The file is removed at exit. The fetch runs in the main thread before the renderer is rebuilt, not in on_video_play(), which runs in the httpd thread.
• If the fetch fails or times out, or the filter returns NULL, the URL is played unchanged, as now. Other plain URLs are not touched.
• README: one paragraph under -lang.

About #581 / hlspi

#581 adds a pad probe for master playlists that GStreamer fetches itself. That is a better place for this than a second fetch and a temporary file: the language filter could be one more call inside the probe. It is not in master, so this PR is self-contained against master. If hlspi is going to land, I would rather redo the wiring on top of the probe and drop video_renderer_fetch_text() and the temp file; the filter function and its test would carry over as they are. That is why this is a draft: tell me which base you want.

Tests

The second commit adds tests/test_yt_web_manifest.c (30 cases on synthetic playlists: language choice, one exact-output comparison, malformed input) as a target that is not built by default and not installed. It is a separate commit, so it is easy to drop.

Validation

• Debian 13 (trixie), GStreamer 1.26.2, on arm64 (VM, software GL) and x86_64 (Intel, VA-API): builds with no new warnings; the test passes, also under ASan and UBSan.
• A captured real manifest (54 variant streams, 8 languages plus untagged): English system languages keep 12 (6 en-US original + 6 untagged); -lang fr keeps the 6 fr-FR.
• Which track actually plays, read from GST_DEBUG=hlsdemux2:6 and the duration in /playback-info: unpatched master fetches a dubbed variant with no option, bare -lang and -lang en; the patched build fetches the original with LANGUAGE=en_GB:en, and the French dub with -lang fr.
• Real sender: Safari on macOS to the x86_64 host, two videos. Log: YouTube web manifest: available audio languages fr-FR,de-DE,en-US (original: en-US), selected: en-US, then normal playback.
• A non-YouTube HLS URL plays as before, with no fetch. A googlevideo URL that cannot be fetched is played unchanged. A server that hangs or drip-feeds is given up on at the time limit.
• The filter was also run over about 2.6 million mutated playlists under ASan and UBSan without a report.

Not tested / known gaps

• macOS and Windows builds (I only have the CI for those).
• Live-stream manifests.
• A second /play that arrives while the first manifest is being fetched wins, as it should, but is played unfiltered.
• No GLib main loop runs during the fetch (typically about 0.2 s, at most 5 s).
• If a dubbed language ever has more than one content id, the choice between them is still by bandwidth.
• uxplay.1 and the -h text are unchanged.

🤖 Generated with Claude Code

[fduncanh]

So you have found (or got Claude to find?) how to intercept the m3u8 hls playlists that gstreamer fetches directly.

The simplified strategy we used with the playlists pushed by the client to UxPlay was to edit the playlists to filter out all languages (and subtitle languages) except the one we actually want to render. (one audio language, 0 or 1 subtitle language) This was because it was difficult to get gstreamer to choose the right one, so we don't offer it a choice. Are you trying to to something similar with the gstreamer playbin -downloaded playlists?