Sibling of the encrypted-VOD fail-fast added for #412 — two more inputs reach the MP4 demuxer with bytes that can never demux, and surface as "Could not read the audio track (MP4 moov not found)":
- MPEG-TS segment streams (e.g. https://test-streams.mux.dev/x36xhzz/x36xhzz.m3u8).
readAudioFromHls fetches and concatenates the segments, but the decode path (decodeFragmentedMp4ToMono16k) only understands fMP4/CMAF. Classic TS-muxed HLS was never supported by the extraction path — but the error doesn't say so.
- Master playlists with no audio rendition:
pickAudioRenditionUrl returns null and parseMediaPlaylist then treats the variant-playlist URIs (the non-# lines of a master playlist) as segment URLs — concatenating m3u8 text and handing it to the demuxer.
Note the file's header comment describes an hls.js transmux-tap design ("we tap its appended audio data"), but extraction is actually the direct byte-range path; hls.js is playback-only. Worth reconciling the comment with whichever direction is chosen.
Suggested fix (fail fast, mirroring #412)
- Master playlist: if the text contains
#EXT-X-STREAM-INF, either recurse into a variant media playlist (lowest bandwidth would do — audio is extracted regardless of video size) or fail with "this master playlist has no separate audio rendition".
- TS segments: detect before demuxing (
.ts URLs / no #EXT-X-MAP / first byte 0x47 sync marker) and fail with "TS-segment HLS is not supported — only fMP4/CMAF streams".
Alternative (bigger)
Implement the header comment's design: route TS streams through hls.js's transmuxer (tap appended fMP4 audio data), which would make classic TS VOD actually transcribable rather than cleanly rejected.
Sibling of the encrypted-VOD fail-fast added for #412 — two more inputs reach the MP4 demuxer with bytes that can never demux, and surface as "Could not read the audio track (MP4 moov not found)":
readAudioFromHlsfetches and concatenates the segments, but the decode path (decodeFragmentedMp4ToMono16k) only understands fMP4/CMAF. Classic TS-muxed HLS was never supported by the extraction path — but the error doesn't say so.pickAudioRenditionUrlreturns null andparseMediaPlaylistthen treats the variant-playlist URIs (the non-# lines of a master playlist) as segment URLs — concatenating m3u8 text and handing it to the demuxer.Note the file's header comment describes an hls.js transmux-tap design ("we tap its appended audio data"), but extraction is actually the direct byte-range path; hls.js is playback-only. Worth reconciling the comment with whichever direction is chosen.
Suggested fix (fail fast, mirroring #412)
#EXT-X-STREAM-INF, either recurse into a variant media playlist (lowest bandwidth would do — audio is extracted regardless of video size) or fail with "this master playlist has no separate audio rendition"..tsURLs / no#EXT-X-MAP/ first byte 0x47 sync marker) and fail with "TS-segment HLS is not supported — only fMP4/CMAF streams".Alternative (bigger)
Implement the header comment's design: route TS streams through hls.js's transmuxer (tap appended fMP4 audio data), which would make classic TS VOD actually transcribable rather than cleanly rejected.