7.10.1 - Two answers that outlived what they described
Two fixes, no API change. Both are the same shape: a piece of state that kept answering a question after the thing it described had gone.
Fixed
The master-refusal latch no longer outlives the output format it describes. panelRefusedHDRMaster records that AVFoundation refused an HDR master, and it kept that answer for the life of the process. The answer is about an output CONFIGURATION, which the user changes in Settings and which the platform never reports, so a latch taken in a mode that genuinely refused went on routing every HDR title media-direct long after the mode was changed back. On a box that holds one app process for days the only cure was a force quit.
The price was also booked wrong. The comment recorded it as "the master route until restart"; what actually hangs off it is the SDR label on every title, Dolby Vision signalling for Profile 7 (which builds its own supplemental=dvh1.08.06/db1p and has no variant for it in a media playlist), and bitmap subtitles in PiP, which without the master rendition publish into a window nobody sees. On a panel whose headroom leg reads flat, master acceptance is the only answer available rather than one of two.
The latch is now cleared on a real return from the background, which is the only guaranteed event after a visit to Settings. isBackgrounded is read before the reset, so a resign that never backgrounded the app (a system dialog, the volume HUD) does not count as a Settings visit. Clearing it wrongly costs one in-place fallback per foregrounding, measured at 223 ms with no visible black frame, instead of once per process.
A fingerprint of the display configuration was considered and rejected: the latch can only be taken while eligibleForHDRPlayback is true, so the capability table at refusal time can be identical to the later one, and the fingerprint would have held the stale latch silently.
A correction that does not rebuild no longer ends a running recording. reloadAtCurrentPosition(applying:) has four exits that never reach a rebuild: the identity refusal, the not-reloadable-in-place refusal, the decode-path refusal, and the early return for a field the session owns. The rule those were built around is that a correction which does not rebuild costs the session nothing, and the call's own documentation says the refusals leave the session untouched.
Since 7.8.0 all four ran behind the source-reset teardown of a running recording, so a refused correction finished the file and published .ended while the session played on, with nothing said. The teardown now sits with the rebuild it belongs to, after the last statement that can still refuse. Its own requirement is unchanged: the recording is still closed as a source reset before the source is re-opened, so stopInternal's call stays a no-op.
Present in 7.8.0, 7.8.1, 7.9.0 and 7.10.0.
Full notes: CHANGELOG · 7.10.0...7.10.1