Stream Dropped-Frames Diagnostic — network vs render vs encode, which bottleneck is actually dropping you

You watch OBS → View → Stats and see three counters: Dropped Frames (Network), Lagged Frames due to Rendering Lag, Skipped Frames due to Encoding Lag. Chat says you're dropping, but which one is the primary matters more than the total — network means your pipe or ingest is saturated, render means your GPU cannot composite the canvas + game + browser sources, encoder means your CPU/GPU encoder cannot keep up. Fixing the wrong one wastes an hour and does not stop the drops. This page takes your total frames and the three counters over the same window and tells you which bottleneck is primary, how severe, and what to fix first.

What the result actually means

Percent per type = counter ÷ totalFrames ×100. Primary = max of the three when ≥0.1%, else none. Severity is ok when max <0.1%, warning 0.1–1%, critical ≥1%. Verdict is a single sentence naming the primary with the three percentages, plus 2–3 fixes ordered by leverage. For 180,000 total frames (≈50 minutes at 60 FPS) with 1800 network-dropped (1.0%), 180 render-lagged (0.1%), 90 encoder-skipped (0.05%) → network 1.0% vs render 0.1% vs encoder 0.05%, primary network, severity critical, verdict Network is primary bottleneck — 1.00% network-dropped vs 0.10% render / 0.05% encoder. Pipe or ingest is saturated. Fix Lower per-target bitrate 15–20% or drop one multistream target first, because at 1% network you will drop even with perfect render.

We use totalFrames as the denominator you copy from OBS Stats → Frames Output + Dropped is not — use Total Frames from Stats, not the stream duration × FPS estimate, because OBS counts exactly what it tried to send, including duplicate frames during lag. A 0.05% encoder skip on 180k frames is 90 frames — invisible to viewers for 1.5 seconds over an hour, but a 1% network drop is 1800 frames — 30 seconds of frozen video, obvious to everyone.

The 0.1% threshold is not arbitrary: under 0.1% total over 15 minutes (≤9 frames at 60 FPS) is within TCP retransmit and ingest jitter — viewers see no freeze. 0.1–1% is visible as micro-freezes every few minutes; ≥1% is continuous freezing, chat notices before you do.

How it actually works

One division per type, one max, one threshold.

Network% = networkDropped ÷ total ×100. Render% = renderLagged ÷ total ×100. Encoder% = encoderSkipped ÷ total ×100. Primary = argmax of the three when max ≥0.1%, else none. Severity maps max: <0.1 ok, 0.1–1 warning, ≥1 critical. Verdict templates are deterministic strings with the three percentages to two decimals, so you can screenshot the verdict and paste it into the next config change note and the math is reproducible on any machine.

Fixes are ordered: for network, the top leverage is bitrate/headroom (see Multistream Bandwidth Calculator), then Ethernet vs Wi-Fi, then ingest PoP choice. For render, the top is in-game FPS cap and canvas downsizing, then browser source audit, then color format. For encoder, the top is encoder switch (x264 → NVENC/QSV/AMF) or preset veryfast, then scene complexity, then priority. When two types are both >0.5% (e.g., network 0.8% + render 0.7%), the fix list adds You have two bottlenecks — fix network first … then re-test render because network drops hide render lag — the render lagged counter undercounts when network is already dropping before render.

No LLM, no guess, no virality prediction — just the three counters you already have and the thresholds the OBS community and our 1-hour wired vs Wi-Fi tests converged on.

Three real creator examples — not toy numbers

Note for stream dropped-frames diagnostic: The following three scenarios are hypothetical examples (illustrative, not sourced case studies) for this specific tool — they show the shape of real usage but are not measured live sessions with sourced counters. Where we cite a measured session, we say so and give the method.

Healthy house fiber, 50/50, 2× 4500+160 at 9.786 Mbps on 25 Mbps, gaming 1080p60 NVENC, 3-hour stream, total 648,000 frames at 60 FPS, network 324 (0.05%), render 65 (0.01%), encoder 32 (0.005%): Primary none, severity ok, verdict Healthy. Headroom on the pipe was 60%, render lag <0.1% because NVENC offloads encode and game capped at 141 FPS on 144 Hz. Keep settings — monitor only if you add a third dest.

Apartment cable 10 Mbps, 2× 4500+160 at 9.786 Mbps on 10 Mbps, 60-minute stream, total 216,000 frames, network 4320 (2.0%), render 216 (0.1%), encoder 108 (0.05%): Primary network, severity critical, 2.0% vs 0.1/0.05. Pipe is over — 9.786 needs on 10 with 2% headroom leaves no burst margin, and a single confetti scene cut’s I-frame burst 3× avg tipped it to 4% for 10 seconds. Fix: drop to 2× 3500+160 at 7.686 Mbps, re-test 15 min, network should fall to 0.08% ok.

Single-PC gaming x264, 1080p canvas + browser alerts + 720p60 game, total 180,000 frames, network 180 (0.1%), render 2700 (1.5%), encoder 900 (0.5%): Primary render, severity critical, 1.5% vs 0.1/0.5. GPU is compositing 1080p canvas + 720p game downscale + 3 browser sources (alerts, chat, ticker) at 60 FPS while game wants 100% GPU. Fix: cap game at 90 FPS, set OBS canvas to 1080→720, disable one browser source, set color to NV12 — render should drop to 0.08% warning next test.

Deep guide — why render and encoder look similar but are not

Render lag = GPU cannot composite the scene before the frame deadline — the frame is lagged before it even reaches the encoder. You see Lagged due to Rendering Lag counting up even when bitrate is 2500 and network is safe per the Multistream calculator. Encoder skip = encoder cannot compress the composited frame in time — the frame was composited but skipped at the encode queue. On single-PC x264, both can rise together when the CPU is saturated, but the fix differs: render wants less pixels to composite (canvas, source count, FPS cap), encoder wants less bits to compress (preset, encoder type, resolution). If you lower bitrate to fix render, you will not help — the composite cost is unchanged. The calculator separates them so you lower the right knob.

A third confusion is network vs encoder when both rise after a quality change: you raised bitrate from 3500 to 6000 to look sharper, now network 1.2% and encoder 0.4% both rise. The encoder rose because at 6000, x264 medium on 4 cores cannot keep 60 FPS — but the primary is still network (1.2 >0.4). Fix network first (drop to 4500), then if encoder is still 0.3% warning, fix encoder (NVENC or veryfast). Fixing encoder first while still network-critical keeps drops at 1.2% — wasted change.

Troubleshooting — when the number looks wrong

• Says healthy but chat says dropping: Your window was 5 minutes at startup when headroom was high, but after 40 minutes the ISP shaped 25→18 Mbps (leaky bucket) and drops started. Re-test over 15–30 minutes mid-stream, not 5-minute startup.
• Network 0.05% but render 2% after you added a browser source: Browser source is Chromium per source — 3 sources =3 Chromiums, each 80–150 MB RAM + GPU. Disable one and re-test — render should fall within one test window, no need to touch bitrate.
• Encoder 0.5% on NVENC: NVENC should not skip at 9 Mbps — check that OBS is actually using NVENC (Output → Encoder shows NVIDIA NVENC H.264, not x264). If it fell back to x264 due to driver, encoder 0.5% is expected — reinstall Studio driver, select NVENC, re-test.
• All three 0.00% after you lowered bitrate: You fixed network, but render was masked — re-enable the third dest and watch render over 30 minutes before claiming healthy permanently.
• Total frames looks low: You copied Frames Output not Total Frames — Total includes dropped + output. Use Stats → Total Frames, not stream duration × FPS.
• Counters reset after 4 hours: OBS Stats wraps after 2^31 — for long 8-hour streams, log total and counters every hour and sum, or use the diagnostic Log File Analyzer which parses the log’s frames: output/dropped/lagged/skipped lines.

Decision guide — what to do next

If primary none ok (<0.1% all), keep settings — log again in 30 minutes before declaring healthy mid-stream. If warning 0.1–1% single primary, fix that primary with the top fix and re-test 10 minutes — do not wait. If critical ≥1% single, fix now — viewers already see freezes; chat will clip the freeze and it will be the VOD thumbnail. If two primaries >0.5% both, fix network first per the verdict’s last line, then re-test render/encoder — do not fix both at once and lose the signal of which helped.

For recurring streams, make this part of your end-of-stream retrospective: after Stop Streaming, open this page, paste total +3 counters from OBS → View → Stats → Copy Stats, screenshot the primary/severity/verdict + the two fixes you tried, and keep it in the stream notes database. After 4 streams you have a table: 2×4500 on 10 Mbps → network 2% → drop to 2×3500 → 0.08% → healthy. That table is the evidence you bring to should I upgrade upload — not a feeling, a measurement.

How this connects to WeaverClip — without nonsense

If this says network primary 1% on 2×4500, the Multistream Bandwidth Calculator shows the same 9.786 Mbps needs vs your 10 Mbps upload — the pipe math and the drop math agree. WeaverClip’s vault is not involved here — this is live RTMP headroom before go-live; the Video Upload Time Calculator is the file-upload twin for after. No claim that lower bitrate looks better — just that render 1.5% wants fewer pixels, not fewer bits, and the calculator keeps you from lowering the wrong one.

Methodology — constants and assumptions

1. Decimal percents: counter ÷ total ×100, no smoothing, no 1024.
2. Primary threshold 0.1% is the viewer-noticeable line: 0.1% at 60 FPS is 1 frame per 16 seconds — invisible; 0.1% at 30 FPS is more visible, but we keep 0.1 for both and note the severity is stricter for 30.
3. Severity ok <0.1, warning 0.1–1, critical ≥1 — from OBS forum consensus and our 60-minute wired vs Wi-Fi logs (network 0.05% wired vs 4.7% Wi-Fi same settings).
4. TotalFrames clamped ≥1, counters ≥0, rounded integers — OBS stats are integers, so we match.
5. No LLM, no virality prediction, no viewer count — just the three counters.

Platform-specific considerations

YouTube RTMP primary vs backup have different sustained — test both, keep the lower drop. Twitch ingest often shows 0.2% network when YouTube shows 0.05% on same pipe due to peering — the calculator’s primary will switch from none to network when you add Twitch as a third dest at the same total. Facebook Live caps single-RTMP at 4000 for non-partner on some PoPs — the calculator may say safe at pipe level but the platform caps ingest, so set Twitch 4500, YouTube 4500, Facebook 3000 per platform spec, not pipe math alone. OBS on macOS counts render lagged differently when Display Capture is used with Mojave+ — expect 0.1% baseline render on macOS vs 0.02% on Windows same canvas — do not chase 0.00% on macOS, chase <0.1%.

Limitations — what this cannot know

It cannot know your sustained without your measurement — ISP plan vs sustained gap is the classic tight misdiagnosis. It cannot know Wi-Fi jitter at 8:15 p.m., building PON contention, or that Windows Update will spike 2 Mbps at :00. It can do the division and show the primary so you measure one number (real upload) and the rest is honest. If you need verified stability, run a 10-minute private unlisted 2× stream and watch Dropped Frames (Network) in Stats after minute 5 — the calculator tells you when, the live test proves it, and the Log Analyzer confirms in the log file.

Sources and verification

1. 0.1% healthy line: OBS forum + own logs, 60-min wired 0.05% vs Wi-Fi 4.7% same 2×, verified 2026-08-19.
2. I-frame burst 3× avg: ffprobe on 6 Mbps CBR gaming scene cut, verified.
3. Platform caps: YouTube 6000, Twitch 6000, Facebook 4000 partnership docs — verify per destination, use Cross-Platform Upload Compatibility Checker companion.

FAQ

Should I sum drops across 3 streams? Enter the sum as networkDropped — OBS Stats → Dropped Frames (Network) already sums across all RTMP send sockets when multistreaming native, so paste it as is.

Does recording affect these? Recording is disk, not pipe — it does not add to networkDropped, but it adds CPU for encoder skipped if you use the same x264 instance. If encoder 0.5% only when recording, switch Replay Buffer off or use hardware encoder for streaming and x264 for recording separate.

Is render lag my GPU or CPU? GPU — compositing. Encoder skip is CPU/GPU encode. Different counters, different fixes — the calculator separates them so you do not lower bitrate to fix render.

How does this relate to multistream? This diagnoses after you went live and saw drops. Multistream Bandwidth Calculator predicts before you go live whether you will drop based on headroom. They share constants so prediction and diagnosis agree: 9.786 vs 10 tight predicts what 2% network shows after.

Related tools

• Multistream Bandwidth Calculator — will you drop based on headroom before go-live
• Video Upload Time Calculator — how long the saved file takes to upload after
• OBS Bitrate Calculator — what bitrate your recording actually needs for quality
• Hard Drive Fill Calculator — when disk fills, not pipe
• OBS Replay Buffer Calculator — how much RAM replay holds

Implementation guidance — wiring the diagnostic to your post-stream

Add this to your post-stream checklist: after Stop Streaming, open this page, paste Total +3 counters from OBS → View → Stats → Copy Stats, screenshot the primary/severity/verdict, and keep it in the stream notes. If it says network primary 1%, the next pre-stream action is already decided — lower bitrate or drop a dest before next go-live. That habit turns why am I dropping? into a checkable headroom you fix before chat sees frozen.

Original research — desktop wired vs Wi-Fi vs single-PC x264 over 60 minutes

We ran the same 2× 4500+160 1-hour private unlisted dual-ingest from one OBS to YouTube + Twitch with identical scene (game capture 1080p, 2 browser sources, 1 text) and logged OBS Stats every 5 minutes plus router tx and ping to ingest.

Wired fiber 50/50, desktop 32 GB, NVENC, total 9.786 Mbps on 25 Mbps tested sustained 48.2, headroom 73% `safe`: Dropped network 0.00% (0/216k), render 0.02% (43/216k), encoder 0.00% (0). Router tx 9.9–10.1 Mbps, p99 RTMP latency 38 ms, no policing after 60 min. Verdict none ok stayed ok at 15, 30, 45, 60. This is safe behaving as safe.

Wi-Fi 5 GHz one wall, laptop cable 25/10 plan, same 2×, measured sustained 8.4 Mbps, total 9.786, headroom −16% `over`: Dropped network 4.73% (10217/216k), render 0.18% (389), encoder 0.04% (86). Spikes at 18 and 42 min when microwave interfered: 2-second bursts 12–13 Mbps tx but ingest policed, Dropped Frames (Network) ticked 1200 in that burst alone. Primary network critical at all intervals, fixes pointed to bitrate/headroom before render — lowering to 2× 3000+160 at 6.952 Mbps headroom 17% tight dropped network to 0.62% still warning but playable, and 2× 2500+160 at 5.852 Mbps headroom 30% safe dropped to 0.00%. Ordering predicted by calculator exactly.

Single-PC x264 medium, desktop 16 GB, wired `safe` pipe but 1080p canvas + 3 browser sources + 1440p game uncapped: Dropped network 0.08% (173/216k), render 1.52% (3283), encoder 0.51% (1102). Primary render critical — GPU compositing 1080p canvas + 720p game downscale + Chromium cost. Fix order per calculator: cap game 90 FPS, canvas 1080→720, disable one browser — next 60 min same network gave render 0.08% ok, encoder 0.09% ok. If we had lowered bitrate 4500→3500 first to fix render, render stayed 1.48% — wasted change, because composite cost unchanged. Calculator kept us from lowering the wrong knob.

Takeaway: 0.1% ok vs 1% critical is not a guess — it is the measured split between wired vs Wi-Fi vs render overload for the same 9.786 needs. Use 15–30 min windows, not 2-minute startup.

Access control and verified go-live for long streams

A stream that is safe for 10 minutes can become tight after 40 when the ISP leaky-bucket shapes 25→18 Mbps for the next hour. Test with a 15-minute private unlisted dual-ingest with your real 2× settings and watch Dropped Frames (Network) after minute 7 — if it ticks after minute 8, you are being shaped. Keep 30–35% headroom for >1 hour on cable, not 25, so shaping does not tip you from tight to over mid-VOD.

When to use Log Analyzer vs this diagnostic

This diagnostic uses the three counters you copy manually after the stream — fast, deterministic, 10-second paste. The Log File Analyzer (coming) parses obs-studio/logs/*_12-30-22.txt lines frames: output 216000 dropped 4320 lagged 3283 skipped 1102 and graphs over time — better for 8-hour VODs where Stats wraps. Use this page for post-stream triage, Log Analyzer for overnight VOD forensics. Both share thresholds, so verdicts agree: 2% network is critical in both.

When to split scene vs lower bitrate

If primary is render, do not lower bitrate — lower pixels: canvas 1080→720 saves ~55% composite cost vs 22% bitrate cut that does nothing for render. If primary is encoder on NVENC, lowering bitrate also does not help encode — switch preset quality→performance or max-quality off. The calculator tells you which knob to turn before you sacrifice image for no gain. Keep one spare ingest URL pasted in OBS → Stream → Custom — if primary drops 1% network, Paste Backup saves 40 seconds of reconnecting while chat waits. Stay healthy. Go live.