Why FPS drops: P-frame reference collapse

[mauricio-gg]

Summary. FPS drops on the Vita are caused by the network, not by the Vita: a lost frame that FEC cannot repair breaks the H.264 reference chain, and every later P-frame fails until a new keyframe (IDR) arrives. The Vita decode path is not the bottleneck (decode averaged 1.7 ms against a 33 ms frame budget). The February 2026 fixes (faster IDR requests, cascade skip) are in main; the proactive soft restart ("cascade alarm") from the same investigation was disabled and has since been removed. The IDR round trip turned out to be far slower than this investigation assumed; see the #251 IDR-wait freeze thread.

Root cause: network-driven reference chain collapse

FPS drops are not caused by Vita-side bottlenecks. The decode design has no queue pressure: overwrites=0 in healthy sessions confirmed decode and render stay in sync.

The chain of events:

1. Wi-Fi instability causes packet loss.
2. Lost packets that FEC cannot recover leave an incomplete frame.
3. If that frame is an I-frame (or any frame later ones depend on), every subsequent P-frame in the chain also fails, because H.264 inter-prediction needs the lost frame.
4. The client requests an IDR. The investigation estimated "50-200 ms round trip, so 3-9 more P-frames are lost by then". That estimate was wrong. Later measurement (GH Video delivery is bursty: frame arrival gaps up to 706ms while the console renders on time — felt as input lag #251) showed the PS5 takes 818-1499 ms to answer, and the client discarded every P-frame in between. See the Video delivery is bursty: frame arrival gaps up to 706ms while the console renders on time — felt as input lag #251 IDR-wait freeze thread.
5. The cascade repeats until a keyframe succeeds, and new losses can start another one.
6. Separately, the PS5's congestion response is a downward-only ratchet on reported loss: target_bitrate steps down and never recovers mid-session (sessions 11782861312 and 18107437792; PR fix(congestion): report post-FEC effective loss to stop PS5 bitrate ratchet (GH #206) #213 / GH Wi-Fi burst jitter + receive-queue overflow drive PS5 bitrate floor-throttling (post-GH #188 track) #206 fixed loss being reported before FEC could recover it, which had been driving the ratchet down needlessly).

Evidence from two February 2026 sessions

Only the measurements that do not depend on the later-discredited metrics are kept. The original table also had RTT and "measured bitrate" rows. The RTT row came from the fabricated readout (handshake RTT plus control-channel EWMA, see the #251 IDR-wait freeze thread), and the measured-bitrate row used a frame-count-divided figure that PR #193 found to seesaw between 0 and ~2 Mbps even on a healthy stream. Both rows are dropped as invalid. The session IDs for these two sessions were not recorded.

Metric	Session 1 (degraded)	Session 3 (smooth)
FPS	18-22	30-31
missing_ref	36 (cascading)	0
corrupt_bursts	74	2 (isolated)
fec_fail	1 (permanent)	0
overwrites	8-10	0
decode_avg_ms	up to 14.9 ms spike	1.7 ms

Why session 3 was smooth: a 5 second cooldown between sessions let Wi-Fi settle, the stream context was fresh with no accumulated corruption, and the first I-frame and following P-frames arrived intact, so no cascade started.

Constants: what the document said, and what is true on main (0e9dd13)

The old document quoted its constants at lib/src/videoreceiver.c:18-19 (it listed 200 ms / 2000 ms in one table and 100 ms / 1000 ms in its status table). Neither location is right any more.

Constant	Old doc	Today on main
IDR_REQUEST_COOLDOWN_MS	200 ms (later 100)	100 ms, lib/src/videoreceiver.c:49
IDR_REQUEST_TIMEOUT_MS	2000 ms (later 1000)	1000 ms, lib/src/videoreceiver.c:50
CASCADE_SKIP_THRESHOLD	3	3, lib/src/videoreceiver.c:51 (used at :658)
VIDEO_GAP_REPORT_HOLD_MS	12 ms	24 ms, videoreceiver.c:15
VIDEO_GAP_REPORT_FORCE_SPAN	6	12, videoreceiver.c:17
UNIT_SLOTS_MAX	256	256, lib/src/frameprocessor.c:39
LOSS_RECOVERY_ACTION_COOLDOWN_US	10 s	10 s, vita/src/host_recovery.c:9
RECONNECT_RECOVER_LOW_FPS_TRIGGER_WINDOWS	12	12, host_recovery.c:13
RECONNECT_RECOVER_TARGET_KBPS	900	900, host_recovery.c:17
FAST_RESTART_BITRATE_CAP_KBPS	1500	1500, host_recovery.c:19
LOSS_RETRY_BITRATE_KBPS	800	800, vita/include/host_constants.h:3
STUCK_BITRATE_STREAK_THRESHOLD	5	Gone: no handle_stuck_bitrate or STUCK_BITRATE_* anywhere in vita/ or lib/

Also stale in the old text: the reference store is 8 slots, not 16 (lib/include/chiaki/videoreceiver.h:22, PR #186; see the motion macroblocking thread), and the video jitter ceiling on the Vita is now 40 ms (lib/src/takion.c:85, PR #195), not 100 ms.

Improvement opportunities and what became of each

1. Faster IDR recovery (cooldown 200 -> 100 ms, timeout 2000 -> 1000 ms, request on first missing reference). Shipped. Constants above. The IDR request on the first missing reference is PR fix(video): request IDR on first unrecoverable missing ref, not third #187 (videoreceiver.c:826). It trims the client-side delay but cannot shorten the console's own ~1 s answer time.
2. Cascade decode skip. After 3 or more consecutive missing references the client skips the flush and decode of the doomed frame, still counts it lost, and keeps IDR pressure (videoreceiver.c:658-669). Shipped. The old text said the saved ~55 ms per frame blocked the Takion thread; since PR feat(video): decouple sceAvcdecDecode from Takion recv thread (GH #188) #199 decode runs on its own thread (VitaDecode), so that blocking argument no longer applies.
3. Proactive soft restart on cascade detection ("cascade alarm"). Triggered after 2 consecutive missing-ref events within 1 s and requested a soft restart at 75% of bitrate. In February hardware tests the restarts consistently failed at the Takion v12 handshake and killed playable ~21 FPS sessions, so it was disabled by commenting out the call. Gone from the code: handle_cascade_alarm no longer exists. Only leftover state fields and a log line remain (vita/include/stream_state.h:249-251, vita/src/host_metrics.c:211-214, 773). The library's own soft-restart ladder was removed by PR fix(session): hands-off recovery after transport death (#272) #274, and recovery now reconnects from the UI thread after a transport death.
4. Congestion control self-adaptation (restart the stream when bitrate is ratcheted too low). Not done. lib/src/congestioncontrol.c still reports every 200 ms (:5) with the loss clamp at 10% (:11). Note the clamp does not prevent the ratchet: any non-zero reported loss steps the bitrate down.
5. Wi-Fi RSSI trend and pre-emptive action. Not done. RSSI is sampled once a second and logged as rssi= in the PIPE/FPS line (vita/src/host_metrics.c:528-530, :759), with no trend tracking or action.

The cascade flow, in short

Wi-Fi instability -> packet loss -> FEC cannot recover a frame -> frame dropped, IDR requested -> P-frames arrive during the wait and fail on the missing reference (each is reported to diagnostics, and each re-requests IDR if the cooldown allows) -> IDR arrives and the chain is restored -> if Wi-Fi is still unstable, a new cascade starts.

One correction to the original flow chart: it said failing frames were "forwarded to decoder (decode-anyway)". They were not. With succ = false the frame never reached the decoder, which is exactly why the picture froze. Forwarding them is what PR #257 does behind its toggle (lib/src/videoreceiver.c:821-846).

Original hardware results (February 2026)

P0 and P1a worked as designed, pending full validation at the time. P1b (cascade alarm) was disabled because of the Takion v12 handshake failures described above. The original verification plan (move twice as far from the router and compare cascade recovery time and frames lost per cascade) has no recorded results in the repo.

Source: docs/ai/FPS_HEALTH_INVESTIGATION.md (deleted from the repo in #281; recoverable from git history at commit 0e9dd13)