bmoon 0 Posted 41 minutes ago Posted 41 minutes ago ## Environment - Caption stream metadata: `Codec: eia_608, IsTextSubtitleStream: true, SubtitleLocationType: VideoSideData`, index 100. It looks like AVPlayer's caption parsing for in-band 608 in a **progressive MPEG-2 TS** decodes the initial buffer and never processes subsequent caption data (in-band 608 handling is well supported for HLS/H.264 SEI; the progressive-MPEG-2-TS case appears unhandled or stalled). ## Finding 3 — no extraction fallback for live TV Every `live.m3u8` request in the session log (all clients, ~18k requests) negotiate `SubtitleMethod=VideoSideData&VideoSideDataSubs=100&ManifestSubtitles=vtt` — i.e. captions are only ever carried **in-band**, and the `ManifestSubtitles=vtt` request never yields a WebVTT rendition for live streams. The transcode commands carry `-sn`. Server user policies expose no burn-in option per user. So when the in-band carrier is lost (Finding 1) or the player can't decode it (Finding 2), there is no third path — **a 608 → WebVTT extraction option for live TV would resolve all of the above**. ## Workaround that works today Set the Apple TV app's player to **MVP** (the mpv-based player) and DirectStream the source (Max quality). mpv decodes the EIA-608 captions in software from the raw TS and renders them live: - Captions update continuously (verified minutes at a time) - Zero server transcode — the MPEG-2 stream is played as-is - Quirk: after starting a session, the caption track sometimes needs to be re-selected (CC off → CC1) before mpv begins decoding — first selection at stream start appears to bind before caption decoding attaches Android-family apps also expose a player choice; the same mpv route should fix captions there. ## Requests (in priority order) 1. **A53/CEA-608 caption injection for hardware H.264 encoders** in the transcode pipeline (VAAPI/QSV/NVENC), or transparent caption carry-over where the encoder supports user data — closes the silent caption loss for all HW-transcoding clients. 2. **Live TV subtitle extraction (608/708 → WebVTT)** as a server fallback when captions can't ride in-band — would rescue every affected client/player combination, including AVPlayer. 3. Investigate **in-band 608 decode stall in the Apple TV native player** on DirectStream of live MPEG-2 TS (Finding 2). 4. (Minor) AMD VAAPI intermittent `Access unit too large / Encode failed: -28` on live HLS transcodes, which surfaces the otherwise-unreachable software fallback. Happy to attach the full ffmpeg transcode logs and session log excerpts on request.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now