Skip to content

5.23.8 - AirPlay native subtitles

Choose a tag to compare

@superuser404notfound superuser404notfound released this 27 Jul 04:18

Patch release. One fix: native subtitle renditions now reach a wireless AirPlay receiver for SDR sources.

Fixed

Native subtitles no longer stop at the AirPlay hop.

A SUBTITLES rendition can only be declared in a master playlist. The AirPlay rewrite that moves the loopback onto the device's LAN IP, so the receiver can reach it at all, also forced the media playlist for every source. The receiver therefore got a manifest with no EXT-X-MEDIA tags, setNativeSubtitleSelected(track:) had no legible group to select against, and the call succeeded while rendering nothing. Picture in Picture, which plays the same renditions off the local master, was unaffected, which is what made the two features look mutually exclusive.

The constraint behind that downgrade is narrower than the rule built on it: AVPlayer rejects an HDR or Dolby Vision master on a receiver that is not in HDR or DV mode, and will not switch by itself. An SDR variant is routing-safe on any receiver, so it now keeps its master and the renditions travel with it. The master's rendition URIs are relative, so they resolve against the LAN base with no further work.

HDR and DV sources keep the media downgrade. An SDR-signalled master over HDR content does not fool the external-display compatibility gate either, since it reads the real colr and codec rather than the manifest string, so there is no manifest that both survives an SDR receiver and carries renditions. What changes for those sources is honesty: nativeSubtitleRenditionsServed now reports the playlist actually served to the receiver instead of the one the local session resolved. It goes false on that hop, so a host can tell the user that subtitles will not travel to this route rather than dropping them silently.

The reactive master-rejection fallback now rewrites onto the LAN IP as well. It reloaded the 127.0.0.1 media playlist, which a receiver cannot reach. That path was already reachable before this release, because the engine reported itself as serving the master while media was in fact being served.

Hosts

No public API change, and no change on any route other than wireless AirPlay. Hosts that already observe nativeSubtitleRenditionsServed get a more accurate value; hosts that do not can keep calling setNativeSubtitleSelected(track:) on the AirPlay route and it will now work for SDR sources.

Verification

1106 tests green, including six new cases for the AirPlay playlist decision. swift build -Xswiftc -strict-concurrency=complete clean, CI green on macOS, tvOS Simulator and iOS Simulator, standalone iOS and tvOS builds without warnings.

Acknowledgements

Reported by @thatcube with a precise reading of the two code paths involved, which is what pinned this to construction rather than to selection timing, and with the failure modes of two workarounds already ruled out. Thanks also to @DrHurt, whose original AirPlay caveat is the constraint this release narrows to its actual scope.