2 Commits

Author	SHA1	Message	Date
enricobuehler	a784682d4c	fix(client/net): split the receipt stamp from the pull + bleed standing latency ... The two-pair investigation (wired Mac clients stuck at a rock-steady ~18-19 ms "network" that survived the load ending and cleared only on reconnect) exposed two structural gaps, one of measurement and one of recovery: - Receipt was stamped at the hand-off PULL (Swift nextAU, pf-client-core, Android decode loops), not at reassembly completion — so any client-side standing state between the reassembler and the pull read as NETWORK latency, undiagnosable from the HUD. ABI v9: `PunktfunkFrame`/`Frame` grow `received_ns`, stamped by `Session::poll_frame` as the AU crosses the session boundary. Every embedder now uses the core stamp; the Apple client keeps the pull instant as `AccessUnit.pulledNs` and shows the receipt→pull wait as its own "client queue" term (detailed HUD tier from 2 ms + a `queue_p50` stats-log field). Decode stages keep their pull anchor on all platforms, so no historical stage shifts meaning. - The jump-to-live detectors deliberately ignore anything under 6 queued frames / 400 ms behind — so a small, constant, loss-free elevation (a sub-frame standing backlog, or a stale clock offset after a wall-clock step/slew) is carried for the rest of the session. New third detector (`StandingLatency`, unit-tested ladder): window-MIN one-way delay ≥ 10 ms above the session floor with zero loss for ~4.5 s escalates gently — a free clock re-sync first (an applied re-sync re-bases the floor), then at most 3 flush+keyframe bleeds sharing the jump-to-live cooldown, then a loud disarm naming what it means. Loss windows reset the run: congestion belongs to FEC/ABR, not this detector. Also: mid-stream re-sync apply/discard logs debug→info — they are the forensic trail for the stale-offset case and were invisible in the field. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 23:38:11 +02:00
enricobuehler	f439b69451	refactor(android/W8): split decode.rs into decode/ directory module ... Break the 1747-line clients/android/native/src/decode.rs into a decode/ directory module (mod.rs + 5 concern submodules): - decode/setup.rs : codec creation + low-latency config + thread/frame-rate tuning + HDR static-info encode - decode/display.rs : DisplayTracker + render-callback registration + HDR dataspace - decode/latency.rs : realtime clock + decoded-pts / user-flags stat recording - decode/sync_loop.rs : the synchronous poll decode loop (+ feed/drain) — moved WHOLE - decode/async_loop.rs : the event-driven async decode loop (+ helpers) — moved WHOLE decode/mod.rs keeps the consts, DecodeOptions, and the `run` entry point + the `codec_mime`/`codec_label` re-export, so every crate::decode::X path stays byte-stable. The module has no decoder struct (free functions + small types), so both decode loops move byte-for-byte and their separately-inlined received-stat recording is NOT unified. 16 helper fns/types became pub(super) for sibling access; zero field bumps. lib.rs unchanged (`#[cfg(target_os="android")] mod decode;` resolves to decode/mod.rs). Verified: cargo-ndk check (aarch64-linux-android, clean) + the gradle cargoNdkDebug build (arm64-v8a / armeabi-v7a / x86_64). On-device runtime re-verification still owed per the plan (the two decode loops are a hot path). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 15:06:24 +02:00