6.6.1 - The probe pays for a segment only where nothing else can answer
One behaviour fix, out of the 6.6.0 device leg on a real live channel. No API change.
Fixed
-
The live carriage probe no longer spends a media connection where the playlists already answer, nor spends one against the mount. Origins that authenticate per token routinely cap concurrent connections at one or two, and what such a cap counts is media fetches rather than playlist fetches. The 6.6.0 probe's ranged segment head was therefore a second media connection, opened while AVPlayer was establishing its own, on exactly the channel shapes the probe's gate admits. Two things were wrong with that, and neither is that the probe reads a segment.
It read one where the playlists already answer. An fMP4 media segment requires an
EXT-X-MAP(RFC 8216 4.3.2.5), so a master advertisinghvc1/hev1/dvh1/dvhe/av01over a window that carries none is that codec in MPEG-TS: settled from theCODECSattribute AVFoundation has already parsed plus one playlist fetch, with no segment byte at all. AES-128 no longer blocks that branch either, since nothing is decrypted to reach the verdict and the ingest serves the carriage.And it read it at the one moment where losing the race is expensive. The verdict cannot be acted on before readyToPlay in any case, because it feeds the #168 watchdog and the watchdog arms there, so running the read against the mount bought nothing but a head start on the probe's own latency. What the playlists cannot settle, a direct media playlist or a master without
CODECS, still reads one segment head, because only the PMT separates HEVC in MPEG-TS from H.264 in MPEG-TS there and dropping that distinction would either pull working H.264 channels off the native path or return the case to indefinite black. That read now waits for readyToPlay, where a lost connection costs the verdict rather than the mount, on a session that is already showing black (#296).Media connections per channel shape:
shape 6.6.0 6.6.1 master advertising HEVC / DV / AV1, no EXT-X-MAP1, against the mount 0 master advertising HEVC / DV / AV1, AES-128 0, inconclusive, full grace 0, settled early direct media playlist, no CODECS1, against the mount 1, after readyToPlay H.264 master 0 0 A session whose watchdog disarms first, or which never becomes ready, now fetches nothing at all. The saving stays about 3.5 s of the 4 s grace, since the deferred verdict lands inside the first tick or two.
The verdict log line names where its evidence came from, so the two paths are separable in a capture:
carriage probe: hevcInMPEGTS from playlist evidence (#293)against... from segment PMT evidence (#293).carriage probe:still greps for both.
Raised by @kskchaitanya1993 as a design concern against connection-capped IPTV origins, after running the 6.6.0 device leg for #293 (t+6.0 s against t+9.0 s on a master, t+5.0 s against roughly 24 s on a direct media playlist).