enricobuehler 2a62fe7857 fix(client): stop the double-arm race re-freezing RFI-healed streams ...

Every unrecoverable loss armed the client's freeze gate twice: instantly at
frame-index-gap detection (which fires the RFI), and ~120 ms later when the
reassembler ages the lost frame into frames_dropped and poll() re-armed
unconditionally. An LTR-RFI recovery anchor lands in ~60 ms — between the two
signals — so the stale climb re-froze a bit-exact-healed stream, the host
swallowed the re-ask as an RFI echo, and the picture stayed frozen until the
overdue backstop extracted a full IDR: the field 'H265 freezes on every loss,
AV1 fine' signature on AMD hosts (AMF is the only LTR-RFI backend; the slower
IDR path usually lands after the climb and dodged the race).

The gap-arm now pre-credits the expected climb (ReanchorGate::arm_expecting_drops;
credit expires after DROP_CREDIT_WINDOW so a straggler-filled gap can't mask a
later real loss), and poll() consumes credited climbs instead of re-arming.
Plumbed through every embedder: pf-client-core's session pump, Android's
sync/async loops (note_frame_index now returns the gap width), and the Swift
client via new ABI exports punktfunk_connection_note_frame_index_ex +
punktfunk_reanchor_gate_arm_expecting_drops (additive; the bool ABI stays).

2026-08-12 08:11:35 +02:00

..

src

fix(client): stop the double-arm race re-freezing RFI-healed streams

2026-08-12 08:11:35 +02:00

vendor/ndk

docs: repo-wide housekeeping — sync README & docs with the code as shipped

2026-07-10 09:13:42 +02:00

Cargo.toml

fix(android/pad-audio): pin the uac-host that unmutes the pad

2026-08-03 14:35:27 +02:00