> 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/llm-prompt.md). # Asking an AI to read your stats Pasting a raw stats dump into an LLM usually produces confident nonsense. The field names look like generic WebRTC statistics but several of them are VDO.Ninja-specific, and a few mean close to the opposite of what a model will assume — most importantly, that raising the bitrate is the wrong response to packet loss. The prompt below supplies that missing context. Paste it, then paste your stats underneath. ## Before you paste: redact these The **Copy** button captures the panel exactly as shown, which can include: * **IP addresses** — `Local relay IP` and `Remote relay IP` appear when the connection is going through a TURN relay. * **Machine fingerprints** — user agent, GPU model, CPU core count, for both you and the person at the other end. * **Guest labels** — real names, if that is what you use for `&label`. * **Your stream IDs** — anyone with a stream ID can attempt to view or push to it, unless you are using a password. Replace anything sensitive with `REDACTED` before sharing. The diagnosis does not depend on any of it. ## The prompt ``` You are helping me troubleshoot a live video stream sent with VDO.Ninja, a peer-to-peer WebRTC streaming tool. I am going to paste the contents of its statistics panel. Read it using the following context. WHICH PANEL IS THIS There are two panels and they mean different things: - A VIEWER panel starts with "StreamID:" followed by a "Stream info" section. It describes what is ARRIVING at the person who captured it. Critically, the "Stream info" section is self-reported by the REMOTE SENDER: the CPU, GPU, OS, browser and battery listed there belong to the sender, not the person who captured the dump. - A PUBLISHER panel lists "Outbound connections" and then repeats a block per connected viewer, each headed "Viewer: ". It describes what is BEING SENT. Each viewer block is a separate encode with its own limits. If both panels are pasted, they are the two ends of the same connection and should be cross-referenced rather than analysed separately. FIELD MEANINGS - Packet Loss: the panel's current loss sample. Under 1% is often fine, but a low current sample does not rule out an earlier burst. - NACKs sent / NACKs per second: requests to resend a lost packet. Some is normal; sustained growth usually means missing or reordered packets. - Keyframes requested (PLI): the receiver asked for a full refresh because its decoder needed one. Loss can cause this, but startup, decoder resets, layer changes and renegotiation can as well. Correlate sustained growth with NACKs, loss and visible freezes rather than treating PLI as proof of loss. - Jitter Buffer Delay: delay added by the receiver to smooth uneven arrival. A rising value means arrival is becoming less even; a zero current loss sample does not prove that no earlier packets were lost. - Round Trip Time: network latency. Stability matters more than absolute value; 200ms intercontinental is normal, a number that swings is not. - Candidate type (Local and Remote): "host" = a host/interface candidate, "srflx" = a public NAT mapping discovered through STUN, and "relay" = a TURN allocation. Interpret the selected pair together. A pair containing relay uses TURN; host on both ends often indicates a LAN path. - Available outgoing bitrate: what the congestion controller believes the selected path can currently carry. It is an estimate, not proof of the physical upload ceiling. - Quality limited by: why the encoder is holding back. Values: none, bandwidth, cpu, other. "none" means the browser is not currently limiting resolution or frame rate; it does not promise that bitrate will hit a target. - Scale factor / Requested resolution: VDO.Ninja deliberately asks senders for a resolution matching how large the video is drawn on the viewer's display, in device pixels. A downscaled stream is usually intentional bandwidth optimisation, NOT a fault. - Mic level (sent): audio level reaching the encoder, 0 to 1. If it stays at zero while the sender speaks, the microphone pipeline is producing silence. - Audio Level: received audio loudness, 0 to 1. - Capture settings vs Resolution: what the camera produces vs what is actually being encoded for a given viewer. They differ when scaling is applied. - Video init width/height/frameRate: what the SENDER asked their camera for, not what is currently being sent. - A missing "Audio track" or "Video track" section means that track is not being received at all. Absence is a finding, not missing data. - A "⚠️" next to a bitrate means the track exists but nothing is flowing. - Reliability counters: internal recovery telemetry. Almost all zero is normal. A few "Ice candidate error 701" entries are harmless. Sustained growth in "Peer recovery attempts" or "Media stall restarts" indicates an unstable connection rather than a merely slow one. INTERPRETATION RULES 1. Raising the bitrate is the WRONG response to packet loss. More data on a lossy path causes more retransmission and more loss. Recommend lowering bitrate, resolution or framerate instead. 2. When "Quality limited by" is cpu, raising bitrate will not help. Reducing frame rate and/or resolution reduces encoder work. Switching to H.264 often enables hardware encoding. 3. When "Quality limited by" is bandwidth AND video bitrate is close to available outgoing bitrate, the path is probably congestion-limited and a higher target is unlikely to help. 4. If several viewers show problems but one does not, the problem is on the affected viewers' end-to-end paths rather than a universal sender limit. If all viewers show the same limit simultaneously, investigate shared sender-side constraints first. Neither pattern proves the exact segment. 5. Do not treat a downscaled resolution as a fault without first checking Requested resolution and Scale factor. 6. Distinguish "degraded" from "flapping": Time active resetting repeatedly, or climbing Peer recovery attempts, means the connection is dropping and rebuilding, which needs a different fix from mere congestion. 7. Battery and thermal state matter for phone senders. Check Power level and Plugged in before recommending settings changes. WHAT I WANT BACK 1. One sentence: what is actually wrong. 2. Which end the problem is on (sender, receiver, or the network between). 3. The specific numbers in the dump that support that conclusion. 4. Concrete next steps, most likely to help first. Use VDO.Ninja URL parameters where relevant. 5. Anything you would need to see to be more certain, including whether you need the other end's stats panel. If the data does not support a confident conclusion, say so and tell me what to capture next. Do not invent values that are not in the dump. Here are my stats: [PASTE YOUR STATS HERE] ``` ## Add your context The prompt works better if you also tell it what you are actually doing. Add a couple of lines before your stats: ``` Setup: publishing from a phone on 5G, viewed in OBS on a wired desktop. Symptom: video freezes for about a second every 30 seconds, audio is fine. My push link: https://vdo.ninja/?push=XXXX&quality=1&codec=h264 My view link: https://vdo.ninja/?view=XXXX&buffer=500 ``` Setup, symptom and both URLs answer most of the follow-up questions an LLM would otherwise have to ask. ## Short version If you just want a quick read and do not need the full glossary: ``` This is a stats dump from VDO.Ninja, a peer-to-peer WebRTC streaming tool. Notes: the "Stream info" section describes the remote sender's machine, not mine. "Quality limited by" says why the encoder is holding back. Raising bitrate is the wrong response to packet loss. Downscaled resolution is usually intentional bandwidth optimisation, not a fault. Tell me what is wrong, which end it is on, and what to change. [PASTE YOUR STATS HERE] ``` ## Capturing both ends Most of the harder cases are only decidable by comparing sender and receiver, so capture both where you can: 1. On the sending machine, Ctrl + click your own camera preview, press **Copy**. 2. On the receiving machine, Ctrl + click the incoming video, press **Copy**. 3. Label them clearly — `--- PUBLISHER ---` and `--- VIEWER ---` — before pasting. Both ends let an LLM cross-check what was sent against what arrived and distinguish many sender, receiver and path problems. They still cannot prove whether loss occurred on the sender's access link, the receiver's access link, or an intermediate network without additional measurements. ## Next * [Diagnosing problems](/guides/stats-menu/troubleshooting.md) — the same reasoning, done by hand * [Reading the viewer panel](/guides/stats-menu/viewer-stats.md) and [the publisher panel](/guides/stats-menu/publisher-stats.md) — full field references --- # 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/llm-prompt.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.