Live HLS ingest drops the master's SUBTITLES renditions, so live subtitles are unreachable

[superuser404notfound]

What happens

On the loopback live path (effective video route = loopback), a channel whose upstream master advertises a SUBTITLES group plays without any subtitle track. subtitleTracks stays empty, so nothing is selectable and nothing renders.

Measurement

MDR Sachsen (public HLS, https://mdrtvsnhls.akamaized.net/hls/live/2016928/mdrtvsn/index.m3u8) advertises a WebVTT rendition on every variant:

#EXT-X-STREAM-INF:...,AUDIO="program_audio",SUBTITLES="subs"
#EXT-X-MEDIA:TYPE=SUBTITLES,NAME="Untertitel",DEFAULT=YES,AUTOSELECT=YES,FORCED=NO,LANGUAGE="de",GROUP-ID="subs",URI=".../master-subs-1200.m3u8"

What the engine does with it:

[HLSIngest] master playlist: picked variant bandwidth=8500800
[HLSIngest] demuxed audio rendition (group "program_audio", default=true): starting companion reader on ...
[Demuxer] Opened: 1 streams
[Demuxer]   stream[0] type=video codec=h264 1920x1080
[AetherEngine] native subtitles: prepare=false eager=false textTracks=0 bitmapOCR=0 enable=false

The variant's SUBTITLES group is never looked at. HLSLiveIngestReader.swift (551 lines) contains no occurrence of "subtitle", and HLSMasterPlaylist models variants, demuxedAudioGroupIDs and audioRenditions only. The served local master consequently declares CLOSED-CAPTIONS=NONE and carries no rendition.

The audio side of exactly this shape is already handled: a demuxed audio rendition gets a companion reader. Subtitles have no equivalent.

What the segments look like

Plain .vtt, 2 s each:

WEBVTT
X-TIMESTAMP-MAP=LOCAL:159:04:22.306,MPEGTS:183000

164:04:24.000 --> 164:04:25.440
Alles klar?

Two properties that shape any implementation:

1. Cue times are not stream times. They sit on a long-running LOCAL clock (164 h here) and only X-TIMESTAMP-MAP anchors them to the program's 90 kHz MPEGTS clock, which is the same clock the segment producer already derives playlistShiftSeconds from. The mapping is therefore cue time -> MPEGTS time -> player clock, wrap-safe on 33 bits.
2. Cues repeat across segment boundaries. A cue spanning several segments is repeated in each, clipped to the boundary (segments 133/134/135 above each carry the same line with adjacent ranges). A naive collector publishes the same line three times.

Proposed shape

• HLSPlaylistParser learns EXT-X-MEDIA:TYPE=SUBTITLES and the variant's SUBTITLES group id.
• The ingest hands the picked variant's renditions up as metadata, without fetching.
• They surface as TrackInfo entries in subtitleTracks under their own synthetic id range, like the A53 closed-caption track and the external tracks already do.
• selectSubtitleTrack on such an id starts a fetch loop over the rendition playlist: first what the playlist currently lists (so a jump back inside the DVR window is covered), then following the live edge. Deselect stops it.
• Segments are parsed into SubtitleCues, mapped onto the player clock as above, with repeats merged rather than appended.

Out of scope for a first cut: WebVTT in fMP4, the bypass path (it sees renditions natively), and Teletext (a TS concern).

[superuser404notfound]

Built on feat/live-hls-subtitle-renditions, verified headless against the live channel:

aetherctl play --live --live-ingest --seconds 45 --subs de <mdr master.m3u8>
  [HLSIngest] subtitle renditions in group "subs": 1 (de)
  [AetherEngine] surfaced 1 live subtitle rendition(s) from id 300000
  CUE #114 27730.59-27731.71 'wie viel Verkehr auf der Brücke | zugelassen werden kann.'
  VERDICT: OK

Three things the real stream corrected in the design above, each of which produced an empty overlay on its own:

1. X-TIMESTAMP-MAP does not place these cues. The proposal assumed it would. Measured, MDR writes one constant map per rendition (LOCAL:159:04:22.306,MPEGTS:183000, identical in every segment) whose MPEGTS value sits two hours off the video rendition's PTS, so a cue placed through it landed 7185 s from the picture. What the renditions genuinely share is the playlist geometry: identical EXT-X-MEDIA-SEQUENCE and identical EXT-X-PROGRAM-DATE-TIME, byte for byte. A cue is now placed by its segment's wall time plus its offset inside that segment, against the wall time the video ingest joined at. The map is still parsed, because a segment without one cannot be placed at all and is refused rather than guessed at.

2. RemoteHLSMediaSelection.ordinal claimed the new id space. It tested id >= subtitleTrackIDBase with no upper bound, so the renditions at 300_000 were routed into the AVMediaSelection path and their selection never reached their own. Bounded now, with a test. Worth remembering as a class: an open-ended id range silently annexes every range added above it, and the symptom is not a crash but a feature that quietly does nothing.

3. A rendition playlist is not a handful of segments. The backfill took "what the playlist currently lists", assuming that approximates the DVR window. MDR publishes its entire two hour window, 3600 entries, so the loop began two hours behind the picture and every cue it produced was pruned as stale on arrival. It now anchors at the playhead and marks anything older than the backfill span (120 s) as seen without fetching it.

Also added aetherctl play --live-ingest, since the ingest path had no CLI harness against a real channel at all, which is the reason this went unnoticed for as long as it did.

Open: device verification through a host, and the Sodalite side that shows the tracks.