> For the complete documentation index, see [llms.txt](https://docs.vdo.ninja/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.vdo.ninja/guides/stats-menu/viewer-stats.md). # Reading the viewer panel This is the panel you get when you Ctrl + click a **remote** video — a guest in your room, or a stream you are viewing in OBS. It describes what is arriving at your machine. The panel opens with `StreamID:` so you always know which stream you are looking at. That matters when several guests are on screen. ## Stream info
Stream Info section listing capture settings, audio processing, version, and the sender's hardware

Stream info describes the sender's machine and settings, not yours.

Everything in this section is **self-reported by the person sending the video**. It is not measured by you. This is the single most misread part of the panel: `CPU`, `GpGPU`, `Platform (OS)` and `Power level` all belong to the guest, not to you. | Field | Meaning | | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Video init width` / `height` / `frameRate` | What the sender asked their camera for. Not necessarily what is being sent right now — compare against `Resolution` under Video track | | `Quality (URL)` | The sender's `&quality` setting | | `Echo-Cancellation`, `Auto-Gain (agc)`, `De-noising` | The sender's audio processing. `default` means they did not override it and the browser decides — which is not the same as "off" | | `Pro-Audio (Stereo-mode)` | Only appears if the sender used `&stereo`. Higher-fidelity audio modes usually need headphones at both ends | | `VDO.Ninja Version` | The sender's version. Mismatched versions are worth noting when something behaves oddly | | `User agent`, `Platform (OS)`, `Browser` | The sender's browser and OS. Click the user agent to copy it | | `GpGPU`, `CPU` | The sender's graphics adapter and core count. Limited hardware can help explain encoder trouble, but these fields do not measure current load | | `Power level`, `Plugged in` | The sender's reported battery state. A low battery, low-power mode, or thermal pressure may reduce performance, but the percentage alone does not prove throttling | | `Quality limited by` | Why the browser says the sender's encoder is limiting resolution or frame rate: `none`, `bandwidth`, `cpu`, or `other` | | `Total outbound p2p connections` | How many viewers the sender currently has, updated within a few seconds of anyone joining or leaving. The same count can be shown as a 🔗 badge on the video itself with [`&showconnections`](/advanced-settings/settings-parameters/and-showconnections.md) | `Quality limited by` is one of the highest-value fields in this section. If a guest looks soft and it says `cpu`, raising the bitrate on your side is unlikely to fix it. ## Peer-to-peer connection
Peer-to-peer connection section showing round trip time, candidate types, time active and total received bitrate

The transport between you and the sender.

This section describes the network path itself, measured by your machine. | Field | Meaning | What to look for | | ------------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | `Round Trip Time` | Network latency there and back | Stable is more important than low. A number that swings around indicates a congested path | | `Candidate type - Local` | The candidate used at **your** end | `host` = a local interface candidate. `srflx` = a public NAT mapping discovered through STUN. `relay` = a TURN allocation | | `Candidate type - Remote` | The candidate used at **their** end | Interpret it together with the local candidate. A selected pair containing `relay` is using TURN; `host` on both ends often indicates a LAN path | | `Local network type` | Your interface type where the browser exposes it | Often `unknown`; Chrome hides this for privacy | | `Time active` | How long this connection has been up | Resets on reconnect. A number that keeps resetting means the connection is flapping | | `Total received` | Total inbound bitrate on this connection | Includes every track plus protocol overhead, so it reads slightly higher than the per-track bitrates added together | | `Requested resolution` | The size your viewer has asked the sender to send | In **device pixels**, so on a HiDPI screen it will look larger than your window. `~` means the request was snapped to a nearby standard size | `Requested resolution` surprises people. VDO.Ninja asks for the resolution that matches how large the video is actually drawn on your display, multiplied by your device pixel ratio. A small video in a grid genuinely does request a small resolution — that is the bandwidth optimisation working as intended. See [`&scale`](/advanced-settings/video-parameters/scale.md) if you need to override it. ## Audio track and Video track
Audio track and Video track sections showing bitrate, jitter buffer, codec, packet loss and NACKs

One section per incoming track. If a section is missing, that track is not being received at all.

Each incoming track gets its own section. **A missing section is itself a diagnosis**: if there is no *Audio track* section, no audio is arriving, and the problem is at the sender or in the negotiation — not in your speakers. | Field | Applies to | Meaning | | --------------------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Bitrate` | both | Actual received bitrate for this track. A ⚠️ appears here if it drops to zero while the track still exists | | `FPS` | video | Frames per second actually being decoded | | `Resolution` | video | The size actually arriving. Compare to `Requested resolution` above and to the sender's `Video init width/height` | | `Jitter Buffer Delay` | both | How much delay the receiver is adding to smooth out uneven arrival. A rising value can warn that packets are arriving unevenly, even when the current loss sample is low | | `Audio Level` | audio | Current loudness, 0 to 1. If this sits at exactly 0 while bitrate is healthy, the sender is transmitting silence | | `ClockRate` | audio | Sample rate and channel count, e.g. `48000 / 2` | | `Codec` | both | The negotiated codec. `opus, /w fec` means forward error correction is active on audio | | `Packet Loss` | both | Percentage of packets that never arrived | | `Keyframes requested (PLI)` | video | How many times your end has asked for a fresh keyframe. Climbing steadily means your decoder keeps losing sync | | `NACKs sent` | video | How many times your end asked for a specific lost packet to be resent | | `Type` | both | Which kind of track this is | ### How these interact Packet loss, NACKs and PLIs often interact: 1. A missing or late packet can cause your end to send a **NACK** asking for it again. 2. If the decoder cannot continue from the frames it has, it can request a fresh **keyframe (PLI)**. 3. A keyframe is usually larger than a delta frame, so it can briefly increase bandwidth. A burst of loss can therefore produce NACKs followed by a PLI and the familiar "freeze, then snap back into focus" artefact. A PLI is not proof of packet loss, though: startup, decoder resets, layer changes and renegotiation can also request a keyframe. Look for sustained counter growth alongside the visible symptom. ## Extra rows you may see These only appear in specific configurations: | Field | When | | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Added Buffer Delay`, `Total Playout Delay` | You are using [`&buffer`](/advanced-settings/video-parameters/buffer.md) or [`&bufferaudio`](https://github.com/steveseguin/vdo.ninja/tree/gitbook/advanced-settings/audio-parameters/and-bufferaudio.md). `Total Playout Delay` is network latency plus jitter buffer plus any buffer you added — but it does not include Bluetooth, monitor or capture delay | | `Video Buffer: Target / Current`, `Audio Buffer`, `Video Repairs: FEC / NACK` | The stream is in chunked mode. `(rebuffering)` in red means playback has stalled while it refills | | `Candidate type` showing `💸 relay server` | A TURN relay is carrying the traffic. See [relay connections](/guides/stats-menu/troubleshooting.md#the-connection-is-using-a-relay) | | `⚠️ You're blocking` / `⚠️ They're blocking` | A browser or system setting is preventing a direct peer-to-peer connection at that end | | A map with coordinates | The sender is sharing location data | ## Next * [Reading the publisher panel](/guides/stats-menu/publisher-stats.md) — the other end of the same connection * [Diagnosing problems](/guides/stats-menu/troubleshooting.md) — what to actually do about these numbers --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.vdo.ninja/guides/stats-menu/viewer-stats.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.