tvOS 27: an HDR master served during the display mode switch is refused (-11868), costing the master for every HDR title

[imbenjamin]

Background

• Load during the panel switch instead of behind it (the play gate serialises what could overlap) #348: the pre-flight gate's 2 s cap is deliberately shorter than a ~2.9 s switch, so the load overlaps the switch.
• The master-refusal latch goes stale after an output-format change, and costs more than the master route #588: a master refusal is latched until the app returns from the background.
• Stats report wrong current display mode: HDR10+ -> SDR (when display is HDR locked) #459: on tvOS 27 currentEDRHeadroom stays at 1.00, so the session keeps its SDR label.

What is new here: on tvOS 27, the master served during that overlap is refused.

Setup

• AetherEngine 7.22.0. The host is an AVPlayerViewController (AVKit chrome hidden, appliesPreferredDisplayCriteriaAutomatically = false, so the engine is the only criteria writer). LoadOptions are the defaults apart from matchContentEnabled, read from AVDisplayManager (true).
• Apple TV 4K (3rd generation), tvOS 27.0, Match Content on for dynamic range and frame rate (matching=on; the panel switched to 23.976 Hz).
• TV: HDR10 only, no Dolby Vision (displayCapabilities: hdr=true hdr10=true hlg=true dv=false).
• Source: HEVC Main10, BT.2020/PQ, HDR10 (no Dolby Vision in the file), 23.976 fps, direct play over the loopback route.

What happens

1. Criteria are set for HDR10 at 23.976 Hz, and the TV starts switching.
2. The gate proceeds at its 2 s cap ("switch not observable, likely DV", although neither the source nor the panel has DV).
3. The HDR master is served about 140 ms later, and AVPlayer refuses it with -11868 80 ms after that.
4. The refusal is latched (The master-refusal latch goes stale after an output-format change, and costs more than the master route #588), and the engine falls back to the media playlist, losing the SUBTITLES and AUDIO renditions.
5. The switch settles (modeSwitchEnd) 660 ms after the refusal, 2874 ms end to end.
6. The media playlist plays HDR10/PQ correctly and the TV shows HDR10. The session is labelled SDR, as in Stats report wrong current display mode: HDR10+ -> SDR (when display is HDR locked) #459.

The switch measured 2874 ms end to end in each capture on this TV, which is inside #348's measured range. So every HDR title on this box loses its master, and until the app is backgrounded the latch routes every later title media-direct without asking.

Expected

Keep #348's overlap, but either:

• don't serve the master until modeSwitchEnd when an HDR switch has started (the load can still run; only the master/media choice waits), or
• don't let a refusal raised while a switch is in progress set the latch, and retry the master once it settles.

Log (redacted)

17:10:33.261739 [engine] [DisplayCriteria] panel readout before apply: currentEDR=1.00 potentialEDR=1.00 headroomLimit=unspecified switching=no matching=on hdrEligible=yes provenHDR=no
17:10:33.263065 [engine] [DisplayCriteria] SET: format=hdr10 codec=hvc1 rate=23.976 extensions=HDR
17:10:35.287111 [engine] [DisplayCriteria] proceed after cap (start in-gate after 11ms, total 2023ms; engine HDR criteria, switch not observable, likely DV; EDR headroom 1.00)
17:10:35.288114 [session] [DisplayCriteria] panel unproven but HDR-eligible: serving the master and letting AVPlayer answer (refusal costs one in-place media fallback)
17:10:35.423929 [engine] [HLSVideoEngine] serving on http://127.0.0.1:49923/<id>/master.m3u8 (dvModeAvailable=false effectiveDvMode=false panelIsHDR=true displaySupportsHDR=true matchContent=true sourceIsHDR=true useMaster=true videoRange=pq dvVariant=none aud
17:10:35.429112 [engine] [NativeAVPlayerHost] #1 load url=http://127.0.0.1:49923/<id>/master.m3u8 startPos=nil headers=none
17:10:35.510720 [engine] [NativeAVPlayerHost] #1 item.status=failed err=AVFoundationErrorDomain/-11868 'Cannot open'
17:10:35.511452 [engine] [DisplayCriteria] panel refused an HDR master (code=-11868); this process routes HDR sources media-direct until it returns from the background (#588)
17:10:35.511570 [session] [AetherEngine] AVPlayer rejected the master (code=-11868); falling back to media playlist (no CC/subtitle renditions) at 0.00s
17:10:35.511811 [engine] [NativeAVPlayerHost] #2 load url=http://127.0.0.1:49923/<id>/media.m3u8 startPos=0.00s headers=none
17:10:35.592135 [engine] [NativeAVPlayerHost] #2 item.status=readyToPlay
17:10:35.597335 [engine] [NativeAVPlayerHost] #2 item videoFormat=hdr10 subType='hvc1' transfer=SMPTE_ST_2084_PQ rate=0.000
17:10:36.171570 [engine] [DisplayCriteria] switch settled via modeSwitchEnd (start pre-gate (start notification, before gate entry) 2169ms before gate entry, total 736ms, switch 2874ms end to end, panel 23.976Hz, the requested rate)
17:10:40.049771 [engine] [DisplayCriteria] mode check (native): content=23.976 requested=23.976 panel=23.976Hz (nominal 23.976) player=24.433fps
17:10:48.872907 [engine] [DisplayCriteria] playback probe: no HDR reading in 12155ms (max headroom 1.00, 47 samples); this panel does not raise the EDR headroom for HDR content, so the session keeps its SDR label

[superuser404notfound]

Released in 7.22.2 (3a0a5fbe, via #669). Thanks for the precise timeline, it pinned the cause down without a round trip.

Both halves of the expected behaviour are in:

• When the route is an unproven HDR master and a switch was seen to start but has not ended, the load now waits for modeSwitchEnd (same 6 s ceiling as the play gate), re-reads the panel and only then chooses master or media. The Load during the panel switch instead of behind it (the play gate serialises what could overlap) #348 overlap stays on every other route, and a switch that never reported a start is not waited on.
• A display rejection raised while isDisplayModeSwitchInProgress is true no longer sets the The master-refusal latch goes stale after an output-format change, and costs more than the master route #588 latch. The item still falls back to the media playlist.

What a retest on 7.22.2 should show on that box, in this order:

[DisplayCriteria] proceed after cap (...)
[DisplayCriteria] unproven HDR master waits for the running switch to end before it is served (#667)
[DisplayCriteria] switch settled via modeSwitchEnd (...)
[HLSVideoEngine] serving on .../master.m3u8 (... useMaster=true ...)
[NativeAVPlayerHost] #1 item.status=readyToPlay

The cause is inferred from the timing in the log, so the retest is also the check on it. If the master is still refused with -11868 after switch settled via modeSwitchEnd, the switch was not the reason. The refusal then latches as before, and a log of that run would be the next thing to look at. Leaving this open until then.

[imbenjamin]

Retested on 7.22.2, same box (Apple TV 4K 3rd gen, tvOS 27.0, HDR10-only panel), four titles in one process with no backgrounding in between: three HDR10/HDR10+ sources then an SDR one.

Each HDR title logged the expected sequence:

[DisplayCriteria] proceed after cap (... total 2030ms ...)
[DisplayCriteria] unproven HDR master waits for the running switch to end before it is served (#667)
[DisplayCriteria] switch settled via modeSwitchEnd (... total 903ms, switch 2884ms end to end, panel 23.976Hz ...)
[HLSVideoEngine] serving on .../master.m3u8 (... useMaster=true ...)
[NativeAVPlayerHost] #1 item.status=readyToPlay
[AetherEngine] republishing videoFormat sdr -> hdr10: AVFoundation accepted the HDR master ...

The switch measured 2884, 2890 and 2882 ms, settling 903–904 ms after the cap each time. No -11868 on any of them. The second and third HDR titles in the same process still served the master, the TV reported HDR10 for all three, and the served playlists carried the SUBTITLES and AUDIO renditions. The SDR title that followed switched straight to SDR at 23.976 with no wait and served the master.

So the switch was the cause. Thanks for the quick turnaround. Fine to close from my side.

[superuser404notfound]

Thanks for the thorough retest. Three consecutive HDR loads settling via modeSwitchEnd about 900 ms after the cap, no -11868, and the master (with its renditions) served each time confirms the switch was the cause. Closing as fixed in 7.22.2.