LEAD WITH THIS, it is the unusual part: I am NOT publishing from OBS. I publish Enhanced Broadcasting multitrack from my own ffmpeg pipeline on a VPS (OBS sends one SRT feed to my server; the server composes the vertical canvas and publishes the multitrack RTMP session). So please do not close this with “enable Enhanced Broadcasting in OBS” — the question is whether a non-OBS multitrack publisher is supported at all.
SYMPTOM
Every Dual Format stream produces a VOD that will not play from 00:00:00 in the web player: error #4000, then #3000 once the buffer is poisoned. Seeking does not recover it — only a fresh load that never touches segment 0. Loading the same VOD with ?t=30s plays perfectly.
MEASURED (most recent example, VOD id 2843177762, ~19h44m, streamed 2026-08-11)
- All 5 renditions fail identically: segment 0 (0.mp4) has NO VIDEO TRACK; segment 1 (1.mp4) is fine (h264 High 1920x1080, and the corresponding Main profile for 720p/480p/360p/160p).
- The playlist contains an #EXT-X-DISCONTINUITY and a SECOND init segment after segment 0. A player initialising from the audio-only init finds no video track and dies.
- The vertical canvas does not appear in the VOD at all — only horizontal renditions. (Is horizontal-only archiving expected for Dual Format? Please confirm.)
WHAT I ALREADY RULED OUT ON MY SIDE
- My publish used to open with ~1.6 s of audio before the first video keyframe (measured: first audio pts 1.400, first video keyframe pts 3.019), because my relay served the reader mid-GOP.
- I built a keyframe gate that fixed exactly that: the publish now opens with a video keyframe, and all tracks first-emit at the same pts (audio +0.016 s), measured. THE ARCHIVED VOD’S FIRST FRAGMENT WAS UNCHANGED — still audio-only. So the audio lead was a correlate, not the cause; something in the archiver is writing that fragment.
- Single-track (non-multitrack) publishes from the SAME pipeline archive perfectly. Only multitrack/Dual Format is affected.
- I was granted Server Side Transcode support on 2026-08-08 (ladder went from 4 rungs to 2). I expected Twitch’s own re-encode to normalise the opening away. It did NOT — re-measured 2026-08-12 on VOD 2843177762: 0/5 renditions playable, all with the audio-only first fragment. The transcodes appear to inherit the source’s segment boundaries.
MY QUESTIONS
- Is a non-OBS multitrack publisher supported for Dual Format, or is OBS/XSplit the only supported path?
- Does the ARCHIVER require the BPM (Broadcast Performance Metrics) SEI messages that OBS injects before every IDR on every track? ffmpeg cannot emit them natively. AWS IVS’s Broadcast Software Integration Guide lists their absence as a disconnect condition; my LIVE broadcasts are completely unaffected and have run for days, so live clearly tolerates their absence — but I cannot tell whether the archiver does.
- Is there a documented requirement for the first fragment, or for IDR alignment across tracks, that a third-party publisher must meet for archiving to work?
Live playback is perfect on both canvases and always has been. This is purely about what gets archived.
Posting as channel: kinesinships