6.4.0 - Seekable HEVC-in-MPEG-TS HLS VOD

Finite HLS VOD carrying HEVC in MPEG-TS plays instead of mounting black, and a VOD source whose container starts at a non-zero PTS publishes its playhead where its own duration says it should.

Fixed

• Finite HEVC-in-MPEG-TS HLS VOD no longer reaches AVPlayer's audio-only, black native path. AVFoundation builds no video track for HEVC carried in MPEG-TS, since the HLS Authoring Spec sanctions HEVC only in fMP4, so such a source reached readyToPlay with working audio, a running clock, landing seeks and 0x0 dimensions. The 5.17.0 carriage watchdog could not catch it: that one is live-only and needs master-variant evidence, which a direct media playlist has none of.

  The decision is now taken from content before the native mount. The playlist must be finite (#EXT-X-ENDLIST), its segments MPEG-TS, and the first segment's PMT must declare HEVC; only that positive evidence reroutes. Unknown, fMP4, live, encrypted, demuxed-audio and H.264 shapes keep their existing route, and no verdict is read from the .m3u8 suffix or an AVPlayer error string. A confirmed source runs through a seekable TS to fMP4 ingest that preserves the URL, HTTP headers, duration, resume position and ordinary VOD seek semantics: it addresses elapsed media time and restarts at the segment ahead of a seek target instead of pretending to a byte address space it cannot serve. Both direct media playlists and master playlists are covered.

  Reported and implemented by @qoli (#268, #269).

• A VOD source whose container starts at a non-zero PTS publishes its playhead on the same 0-based axis as its duration. The display origin was anchored for disc titles only (#105), so every other source published raw source PTS. That is invisible while the source axis starts at 0, which is every MP4, and wrong as soon as it does not: MPEG-TS carries an arbitrary origin, ffmpeg writes 1.4 s by default, and VOD carved out of a broadcast stream starts hours in. Measured on one 600 s transport stream muxed three times with different origins:

  origin    1.4 s   first published position    2.00 s   unnoticed
  origin     60 s   first published position   62.04 s   scrubber opens at 1:02 of a ten-minute item
  origin   1001 s   first published position 1002.04 s   a seek to 480 s reported a landing and
                                                         resumed at the start of the file
  

  The origin now comes from the container's own start time, which is what duration is measured from, and is installed when the session starts rather than derived from the producer's shift, whose value also carries the producer's initial drift. Two seek-landing events that published renderedTime on the source axis while their own target was on the display axis are folded the same way (#270).

Added

• HLSVideoEngine.sourceStartSeconds, the source PTS the container's timeline starts at. The engine folds it out of the published playhead; a host driving HLSVideoEngine directly can do the same.

Upgrading

.package(url: "https://github.com/superuser404notfound/AetherEngine", from: "6.4.0")

Source-compatible. One behaviour change is worth knowing about: for a VOD source whose container PTS starts away from zero, the published currentTime and the seek axis are now 0-based, so a stored resume position taken from an earlier version of such a source is offset by that origin. Sources that already start at 0 are byte-identical to 6.3.0, and sourceTime stays on the source axis as before.