7.38.0 - a software start waits for its first frames, a live software join starts near the newest media, LibDTSX under the LGPL

Changed

• A live stream on the software path starts near the newest media. A continuous live stream over
  HTTP opens with a burst of what the origin holds of the channel (8 to 18 s on one IPTV panel, at
  link speed), and the software host armed its clock on that burst's first packet. Nothing on the
  software path catches up, so the picture then ran the whole burst behind the broadcast for as long
  as the channel played: measured 17 s behind on a channel whose native-path session ran 6 s behind.
  The live feeder now waits for the burst to land (the ring growing no faster than real time over a
  quarter second, from 0.3 s on, or 1.5 s at most) and starts 4 s behind the newest media, on a
  keyframe; a source that delivers in real time, or a ring too shallow to be worth a later keyframe,
  still starts from its first packet. The media behind the start stays in the rewind ring.
  SoftwareLiveJoinPolicy, SoftwareLiveJoinPlacementTests.

• LibDTSX 2.0.0: DTSX.framework is a dynamic framework the app embeds, under the LGPL. The
  dca crate it compiles in is labelled Apache-2.0 but is a port of FFmpeg's LGPL-2.1-or-later
  dca decoder, so the built library is LGPL-3.0-or-later and now ships, like the FFmpeg
  frameworks, as a replaceable framework in YourApp.app/Frameworks/, exporting only the C API.
  Same decoder, bit-identical output. A host with the DTSXObjectAudio trait on ships LibDTSX's
  NOTICE and LICENSES/ with the app (#798, thanks @tweakapps and @cmcpherson274).

• LibTrueHD 2.3.1: truehd_atmos_version_string() names the truehd commit actually built in;
  it still named an older one. Same decoder (LibTrueHD#2, thanks @cmcpherson274).

Fixed

• A software start or seek no longer runs the clock while the decoder works up to the target
  (#800). The software host started its clock the moment the first packet went in (video-only) or
  the first audio decoded, while the video decoder was still working from the keyframe before the
  target up to it, so the first frames reached the layer late and were dropped: a 4K HEVC title
  with no audio and 10 s GOPs ran its clock 0.9 s ahead of the first frame after a switch onto the
  software path and dropped 5 to 7 frames on an Apple TV 4K, a 1080p H.264 title with audio 0.3 s
  and 3. Before 7.32.2 the #724 re-anchor hid this by starting the clock a whole GOP behind. The
  video preroll #774 added for the Profile 7 FEL route now holds every VOD software route: the
  clock waits at rate 0 until frames from its position on are in the layer
  (SampleBufferRenderer.videoPrerollSeconds, 0.125 s) and then starts prerollStartLead from
  now. A live stream off the FEL route still starts at once. Measured with aetherctl play --sw on
  a 4K 10 s GOP fixture: preroll ready after 889 ms; starting at t=36.600, where the clock used to
  start at once. Reported with measurements by @cmcpherson274. VideoPrerollTests.

• A live reconnect whose audio returns first no longer publishes a picture twice. When the
  returning connection's audio opened the replay check before the outgoing connection's last pictures
  left the PES parser (a flagged picture and its unflagged, truncated successor), those pictures were
  not part of the held boundary. The returning copy of the first one committed the batch, the
  returning copy of the truncated one arrived after it, and the producer published both and bumped the
  second DTS, which poisons Apple's reference chain until the next IDR. Measured on one reconnect in
  three on an Apple TV (AE#747, superseded=0). Such a tail now raises the retained video frontier,
  bounded like a held damaged boundary, so the returning copies land in the verified batch and replace
  the outgoing ones. LivePacketReplayGuardTests.

• A live stream read off its URL and refused for a while keeps its session. The continuous
  MPEG-TS form of an IPTV channel is one connection for as long as it plays, and a connection-limited
  panel answers its reconnects with 509 while another device on the account holds the last slot, for
  seconds to tens of seconds. The reader climbed its 0.5, 1, 2, 4, 8 s ladder, gave up after six
  refusals, and each refusal armed the origin's request pacer (a quiet of up to 15 s, with each
  request waiting up to 10 s on it), which the reload after it then waited out. A live stream's
  429/503/509 is now asked again every second, or after the origin's Retry-After up to 5 s, for up to
  60 s, the way the live HLS ingest asks for its playlist (#778); its refusals arm no pacer and lower
  no budget, and the books still say the origin refused, so the revive arm tells metered from lost. A
  live open the origin answers with a status fails typed with that status at once
  (AVIOReaderError.httpStatus, sourceRateLimited or sourceRefused at the host), where the read
  loop used to spend the open budget on the same request and hand back an untyped read failure.
  A server error that is not a refusal (a 500 or 502 while a tuner spins up) is asked once more
  first, as the read loop did. LiveStreamRefusalRetryTests.

• Profile 7 FEL chroma residual is sampled where the base chroma sits. With a quarter-resolution
  enhancement layer (1080p under 4K), the chroma kernel read the enhancement chroma at texel centres,
  a quarter of an EL chroma texel up and to the left of the co-sited (top-left) chroma location HDR
  streams use. Base chroma sample n now reads EL texel n / 2, DoViBaker's phase. Same-resolution
  enhancement layers and luma are unchanged.