A live diagnostic readout that tells you exactly why your stream looks the way it does. Use it to figure out whether the problem is your network, your decoder, your console, or something else.
During a stream, open the in-stream controls and tap the chart icon (iOS / macOS), pick Stats: On from the 3-dot menu (visionOS), or choose Show Stats from the menu (tvOS). It can also be toggled in Settings → Tools → Performance Overlay.
When the overlay is off, no measurement work runs in the streaming hot path — there's no performance cost to leaving it disabled.
The overlay has a header line plus three columns:
The header shows what you're doing (Remote Play or Cloud Play) and which server you're connected to (your console for remote play, or a datacenter like London A for cloud).
How much time passes between an event happening on the console and you seeing it on screen.
An estimate of the full end-to-end latency: network + decode + render. Anything under 30 ms feels excellent, 30-50 ms is fine for most games, over 50 ms may feel sluggish in fast-paced games.
An estimate of how long it takes a video frame to travel from the console (or cloud server) to your device. The dimmer text next to it (e.g. lona or your console's name) is the server tag — handy when sharing footage.
Time from frame received to frame on your screen: video decode time (DT) plus the render pipeline. Shorter is better. The label below in parentheses (e.g. Norm, Low, ULow, Comp) is your latency mode.
What's actually arriving from the server.
Frames decoded per second on your device. If you're streaming at 60 fps and this reads 50, frames are getting dropped or arriving late. The mini-graph below shows variation over time — a flat line is healthy, a wobbly line is not.
Frames per second the console (or cloud server) is actually producing. Distinct from FPS, which is what your device is decoding. If Src is stable at 60 but FPS is wobbling, the problem is between server and client (network, decoder). If Src itself is drifting or below 60, the game or its encoder is the source of the stutter — nothing on your end can restore missing frames.
How much video data is arriving, in megabits per second.
A low number isn't necessarily a problem — modern video codecs send less data when there's not much happening on screen (a static menu, a dark scene, a paused game). What matters is whether bitrate is low during fast motion: that usually means the stream has downshifted because of network congestion. Compare what you see here to what you set as the target bitrate in console settings.
The current stream resolution (e.g. 720p, 1080p, 1440p, 4K). Cloud streams may differ from your local Remote Play setting.
The diagnostic numbers — these are what tell you why the stream looks the way it does.
How long a packet takes to go to the console (or cloud server) and back. This is your "ping" from the streaming protocol's perspective.
How much your network's response time wobbles. Calculated as the standard deviation of recent RTT samples.
Two networks can both have a 30 ms average ping, but if one swings between 15 ms and 90 ms while the other holds steady at 28-32 ms, the wobbly one will feel laggy and stuttery — even though the averages match. Jitter is the most common cause of lag that looks like nothing's wrong.
How long your device takes to decode each video frame. On modern Apple silicon this is usually under 5 ms. High DT values mean your device is the bottleneck, not your network.
How much spare time your device has per frame, after decoding.
A 60 fps stream gives your device about 16.7 ms to handle each frame; 30 fps gives 33.3 ms. FB subtracts the decode time from that budget — a positive value means your device is keeping up comfortably, a negative value (shown in red, e.g. −1.3 ms) means it can't decode frames fast enough and stutter is imminent.
This is the easiest way to spot a device bottleneck. Most often it goes red on older Apple TVs trying to play 1080p HEVC streams at 60 fps.
Percentage of video packets that didn't arrive. Frames are split into multiple network packets — if any are missing, that frame can be corrupted or dropped.
The frame pacer's current cadence, shown as a ratio (e.g. 1/1 = matching cadence, 2/3 = holding some frames to absorb jitter). Green means the pacer is idle; yellow means it's actively compensating for jitter.
If Pace sits on yellow with drops climbing, the pacer is coping with a bad link — it's not broken, it's papering over the underlying network wobble at the cost of some drops. The fix is the network, not the pacer.
Cumulative count of frames the decoder skipped this session — usually because the video pipeline got too far behind. Occasional drops on long sessions are normal; rapidly climbing drops indicate sustained pressure on the device.
Look at: Jit
If RTT, drops, and VL all look fine but the video stutters, jitter is almost always the culprit. Speed-test apps don't catch this — they show the average ping, which can hide spikes that disrupt the frame-by-frame flow. Try wired ethernet, move closer to the router, or switch from 2.4 GHz to 5 GHz WiFi.
Look at: VL
Anything above 1% video loss will produce visible glitches. This is packet loss, often from an overloaded WiFi network or a weak signal. Other devices saturating the network (downloads, video calls) are common causes.
Look at: Total, RTT, Visual
High RTT (over 80 ms) is the usual cause for cloud streaming — physically far from the datacenter. For Remote Play, check that you're on the same network as your console (or that your internet upload speed is sufficient if you're remote). High Visual latency points to your device or display, not the network.
Look at: BT during fast motion
Bitrate naturally drops on calm scenes, so judge it during action. If it keeps falling well below your target during fast motion, the stream is downshifting because of detected congestion. This is usually a side effect of high VL or jitter — fix the underlying network issue and bitrate will recover.
Look at: Src (source FPS)
The game or encoder itself isn't producing 60 fps — the engine's dropping frames, running variable frame rate, or the encoder is skipping under heavy motion load. Nothing client-side can restore missing frames; frame generation only partially masks it.
Look at: VL and Drops together
Packet loss (not jitter) — real gaps in the video stream that cause corrupted frames. The decoder ends up waiting for the next keyframe (IDR), which is where the visible stutter comes from. Turn on FEC Recovery in settings (on by default from 1.3.2), and fix the link: switch to 5 GHz WiFi, pick a quieter channel, or wire the console up with ethernet.
Look at: Pace (frame pacer state)
Genuinely bad Wi-Fi. The pacer is absorbing constant jitter and paying drops for it — it's coping, not failing. Fix the network: closer to the router, 5 GHz, wired console.
Look at: FB and DT
Decode can't keep up. Thermal throttling from a long session, or HDR 4K on an older chip. Lower the resolution, switch the codec from HEVC to H.264 (decodes faster), or give the device a minute to cool down. Most common on older Apple TVs at 1080p60.
Look at: BT graph shape
Congestion oscillation. The bitrate is set too high for what your link can actually carry, so the console keeps backing off and creeping back up. Lower the bitrate cap in console settings — a steady 15 Mbps beats a wobbly 25 Mbps every time.
Look at: nothing — this one is a display cadence issue
The stream is fine; your display's refresh rate doesn't line up cleanly with 60 fps. Classic cases: visionOS at 90 Hz with frame generation off (a 3:2 pulldown pattern), or a Mac on a 144 Hz external monitor. Turn frame generation on — smoothing this out is exactly what it's for.
Look at: also cadence, not the network
The unavoidable drift slip — once per clock-deficit cycle, the client holds a single frame for one extra tick to stay in sync with the source clock. It's by design; the alternative is unbounded drift. Frame generation papers over even that.
A few non-obvious causes that don't show up as red numbers:
The pacer eliminates jitter and drift stutter, so whatever stutter you see now is almost certainly one of the causes on this page — the network, the source, or physics. If the overlay says all-green and it still stutters, grab a log and send it over; that's a genuinely interesting case.
A short video is much more useful than a screenshot. The FPS, bitrate, and jitter graphs change second by second — a still frame can miss the spike that's actually causing the problem. A 10-15 second screen recording during a bad moment captures the variation we need to see.
In the video (or screenshot, if that's all you have), the overlay tells us at a glance:
If the overlay points at a problem you can't fix on your end, send us a short screen recording (preferred) or a screenshot:
Contact us at [email protected] →