Mistserver cmaf bug report

[gabriel2k5]

Summary

After upgrading from 3.10 to 3.11.2, the CMAF output (HLS7/index.m3u8) intermittently hangs indefinitely when generating the video track's init.m4s, while the same stream plays back correctly through classic HLS (TS-based) and WS/MP4 outputs. The issue started immediately after the upgrade, with no changes made to the stream configuration, encoder, or source.

Environment

• MistServer version: 3.11.2 (Free), 64-bit
• Previous working version: 3.10
• Affected output: CMAF (HLS7 / html5/application/vnd.apple.mpegurl;version=7)
• Unaffected outputs on the same stream: classic HLS (TS-based), WS/MP4 (WebSocket)

Steps to reproduce

1. Upgrade a working MistServer 3.10 instance to 3.11.2
2. Play back a live stream via the CMAF output (/cmaf/STREAMNAME/index.m3u8)
3. Playback intermittently hangs — the HTML5 video player fires a stalled event and never recovers (eventually shows "Poor playback: 0%" from the built-in quality monitor)

Observed behavior

• Browser Network tab shows the request to /cmaf/STREAMNAME/5/init.m4s?tkn=... stuck in pending, 0 bytes, and never resolves (no timeout, no error — just hangs forever)
• MistController log at the time of the hang:

  [WARN] Empty CMAF header for track 5: 18958685-18960685 contains no packets (first: 19158685, last: 19210319), firstPart=92275, lastPart=92275 (../build/lib/cmaf.cpp:280)
  

• The requested range is roughly 200 seconds behind the current live buffer range for that track, yet the affected track itself is reported as healthy — see below
• Track 5 (the main video track, H264, 1280x720@30fps, 2s keyframe interval / 60 frames per GOP) shows "Issues: None" in the stream health panel at all times, including during the hang
• Explicitly selecting tracks via URL parameters (?video=h264&audio=aac&meta=none) does not resolve the hang
• Fetching the manifest (index.m3u8) directly always returns a valid, well-formed playlist — the problem is isolated to fetching the video track's init segment
• The same stream, same moment, plays back with no issues via:
  • Classic HLS (TS-based) output (/hls/STREAMNAME/index.m3u8)
  • WS/MP4 (WebSocket) output

What we ruled out

• Network/CDN caching of the manifest: ruled out — the manifest itself loads correctly and reflects current state; the hang is specifically on segment/init fetch, and reproduces on a direct (non-cached) request
• Token/auth expiry: ruled out — the hang happens even shortly after establishing a fresh session
• Encoder/source instability: ruled out — the video track reports no health issues, and other outputs consuming the exact same source track play back fine
• A stray metadata (JSON) track present on the stream: initially suspected as a possible cause of a "wait for all tracks" stall, but excluding it via meta=none did not fix the hang, so this does not appear to be the (sole) cause
• Stream restart: does not resolve the issue — reproducible after a clean stream restart

Current workaround

Disabled the CMAF output entirely at the server level (Protocols configuration), since this deployment does not need DASH or MS Smooth Streaming output. All viewers were switched to classic HLS output, either via the server-side protocol removal or via the meta-player's forceType: "html5/application/vnd.apple.mpegurl" option for embeds that could not wait for the server-side change. This fully resolved playback for all affected viewers.

Suspicion

Given the timing (immediately after the 3.10 → 3.11.2 upgrade, no other changes) and the specific error signature, this looks like a regression in the CMAF output's header/init-segment generation path introduced somewhere in the 3.11 line — possibly related to changes in default track sorting ("Optimal" track sorting became the new default in 3.11) or to CMAF header generation logic (cmaf.cpp), though we were not able to pin down the exact trigger from the client side.

[Rokamun]

Hey!

Thanks for the report, I'll see if we can find something. We also have a development branch that had several improvements to CMAF, chances are I'll just have to see if I can hasten its release.
Could you try one thing for me on the CMAF output? If you activate it and activate the "send whole fragments" checkbox does it then start working again? I suspect the issue might be we're mistiming the creation of the segments and filling them at the moment. Ticking that box would enforce only posting new fragments when they can be fully filled with data.