6.9.0 - a software session reports its own network telemetry

Three new LiveTelemetry fields plus one field that stops reading zero on the software path. Additive, so this is a minor. Drop-in from 6.8.0, no source change on the consumer side: the new initializer parameters carry defaults.

Fixed

• Byte-derived telemetry read zero for an entire software session. The engine's pump byte counter resolved through the native HLS session, which a software session does not own. Every figure a host derives from it was therefore a hard zero for the whole session on the one path that carries VP9, AV1 without hardware decode and MPEG-4 Part 2: instantBitrateMbps, averageBitrateMbps, networkThroughputMbps, networkTransferredBytes and LiveTelemetry.demuxerBytesFetched.

  A stats overlay reading those fields did not show blanks, it showed 0.0 Mbps against a session playing perfectly. The counter now resolves software first and native second, which is the precedence the 30 s memory probe has always used to read the pump (#306).

Added

• The software path publishes the read-ahead it already computes. Three new fields on the 1 Hz snapshot:

  field	path	meaning
  displayCushionSeconds	software	decoded video queued past the clock (the #303 cushion)
  readerWindowAheadBytes	both	bytes fetched but not yet consumed by the demuxer
  accumulatedFrameDelaySeconds	software	cumulative late-frame delay from the render synchronizer

  droppedFrameCount is now populated on the software path too, from AVSampleBufferVideoRenderer.videoPerformanceMetrics rather than the AVPlayerItem access log that path has no access to.

  forwardBufferSeconds deliberately stays nil on the software path. The demux loop reads on renderer back-pressure, so there is no seconds-deep reservoir of arrived-but-unplayed media to report there, and publishing the sub-second cushion under the native path's name would report a near-stall on a healthy session. clock.bufferedPosition carries the same quantity and is why a host measuring it reads about 20 ms on a healthy VP9 stream: that reading is correct, and it is a cushion rather than a buffer. The two new fields are what that path has instead.

  Reported by @kskchaitanya1993 in #306, with the measurement of both backends side by side that separated the two defects.

• aetherctl play prints the network half of the snapshot on its 1 Hz line: net, rx, ahead, cushion, fwd, drop, delay, each omitted where the running path has no answer. A software session against a rate-limited origin now reads

  t=08 state=playing phase=playing cur=8.01 src=8.01 buf=8.20 dur=60.0 net=5.73Mbps rx=5.9MB ahead=4.1MB cushion=0.23s drop=99
  

  where every one of those fields was previously zero or absent. Note that drop climbs in a CLI run because nothing binds a render surface there; it is not a playback verdict.

Parser note

Field additions only. LiveTelemetry is read-only for hosts and its existing fields keep their meaning, so a host that ignores the new ones is unaffected.