OBS’s dropped-frames counter points to the connection between OBS and the remote stream endpoint, or to a bitrate that connection cannot sustain. It does not by itself tell you whether the limiting factor is your output setting, YouTube ingest configuration, the route from an OVHcloud VPS, or another part of the path.
Start by comparing that counter with OBS’s rendering and encoding indicators and the YouTube Live Control Room health messages. The title alone does not establish where OBS is running, which OVHcloud plan or region is involved, which protocol or ingest endpoint is selected, or what the counters show; diagnose those details before blaming a provider.
What OBS means by dropped frames
OBS uses “dropped frames” for a connection to the remote stream server that is unstable or cannot keep up with the configured bitrate. In this case the remote endpoint is YouTube’s ingest server, not a server operated by OBS. The definition is a useful pointer, but it is not evidence that YouTube or OVHcloud is at fault: congestion, a bitrate that exceeds stable capacity, or a route problem can all produce the same counter.
Keep this symptom separate from encoding overload and rendering lag. Those describe OBS’s ability to render and encode the output on the machine running it. If those counters rise, investigate system capacity and output complexity; if network dropped frames rise while rendering and encoding remain healthy, investigate the outbound connection and ingest configuration first. The OBS Linux Mint playlist guide covers an always-on setup, but for this fault the important first step is to identify which process and machine are actually sending the stream.
Record the session before changing settings
Open OBS’s Stats window while the affected stream is running and note the dropped-frames percentage, rendering lag, and encoding lag. Save the log for that session as well. A snapshot after the stream ends can miss an intermittent fault, so note when the counters begin to rise and whether they recover without intervention.
Record the conditions alongside the counters: date and time, OBS version, VPS region and exact plan, output resolution and frame rate, codec, bitrate, keyframe interval, protocol, and selected YouTube ingest endpoint. Also note whether OBS runs on the VPS itself or on a local computer. If OBS is local, your home or office uplink is part of the sending path; a VPS mentioned in the workflow may only host media or other components.
Use a small table or a text note so you can compare sessions. For example, record “before: network drops rise during the evening; encoding and rendering steady; configured bitrate unchanged” and then capture the same fields after one controlled change. Do not infer a plan limit from the stream setting: a configured bitrate is what OBS attempts to send, not proof of the sustained rate the route can deliver.
Separate rendering and encoding overload
If rendering lag increases, OBS is having trouble producing frames on time. If encoding lag increases, the encoder is not keeping pace with the frames it receives. These are not the same as dropped frames on the network. OBS’s guidance associates rendering and encoding performance problems with GPU or system bottlenecks and suggests reducing output resolution or frame rate when those indicators show a capacity limit. See OBS’s encoding performance guidance for its diagnostic context.
On a VPS, check the actual machine running OBS rather than assuming the plan name describes the encoder’s available resources. Observe CPU and GPU utilisation if available, and check whether another workload starts at the same time as the lag. A software encoder can be CPU-bound; a hardware encoder can still be affected by available resources or configuration. Avoid changing bitrate to solve a rendering problem, because a lower bitrate does not make a late frame render on time.
For a controlled test, reduce output resolution or frame rate one step, keep the source and destination constant, and observe whether rendering or encoding lag changes. If it does, that is evidence for an output-complexity or capacity issue, not proof of a network fix. Restore the original setting if the relevant counters do not improve, then continue to the connection tests.
Compare bitrate with stable upload capacity
A stream can be encoded correctly and still send at a rate the full path cannot sustain reliably. OBS recommends lowering the video bitrate as a connection test and offers 75% of total upload speed as a starting heuristic. Treat that as a starting point rather than a safe-rate guarantee: the useful capacity is sustained throughput to the selected YouTube ingest endpoint, at the time the problem occurs, with room for variation.
First check the recommended range for the actual ingest codec, resolution, and frame rate on YouTube’s encoder settings page. For example, its H.264 recommendations list 17 Mbps for 1080p at 60 fps and 14 Mbps for 1080p at 30 fps; those figures are ingest recommendations, not a measurement of your OVHcloud route. YouTube lists different recommendations for other codecs, so do not apply an H.264 row to AV1 or H.265 output.
| What you are comparing | What it tells you | What it does not tell you |
|---|---|---|
| YouTube’s recommended rate for the selected codec and output | Whether your encoder settings align with the ingest guidance | Whether your route can sustain that rate |
| Repeated upload observations during the affected time window | Whether measured capacity appears variable or limited | Whether a generic test follows the same route as YouTube ingest |
| OBS dropped frames at the current and reduced bitrates | Whether a lower sending rate changes the symptom | Which network segment caused the original loss |
| Rendering and encoding counters | Whether local output production is keeping up | Whether the remote ingest connection is healthy |
Lower bitrate temporarily, keeping resolution, frame rate, codec, and endpoint unchanged. If network drops fall materially while the other counters remain steady, the original rate may have been too close to or above what the path could sustain. That is useful evidence, not proof that the VPS plan is inadequate. If the change makes no difference, restore or reconsider it only after checking ingest messages and route conditions.
For additional context, the 1080p 60fps bitrate guide discusses the output-rate question. Treat any generic recommendation as a comparison point, not a substitute for YouTube’s current codec-specific guidance and a test of your own route.
Review YouTube ingest configuration
Check the YouTube Live Control Room health indicator while the test is running. YouTube provides timestamped messages that can flag ingest problems such as an incorrect bitrate, format, audio or video settings, resolution, frame rate, or keyframe frequency. Match a message to its timestamp and fix a clear configuration error before concluding that the network path is the issue.
Use the encoder requirements for the codec and output you have actually selected. YouTube supports RTMP and RTMPS ingest with H.264, H.265, or AV1 video, and its guidance recommends CBR and a two-second keyframe interval, with intervals not exceeding four seconds. Confirm the current requirements on the official page rather than relying on a saved preset or an old tutorial. YouTube also recommends testing before an event with representative movement and audio, then monitoring stream health.
If Control Room shows no matching configuration error and OBS’s network dropped counter rises, continue investigating capacity and route. A clean health display is not a guarantee that every packet travelled well, just as an ingest warning is not proof that the selected VPS plan is the cause. If you are setting up a continuous playlist as well as diagnosing transport, the OBS display-sleep troubleshooting guide addresses a separate interruption mechanism; do not confuse a stopped source with network drops.
Investigate the VPS and network path
Identify the path that carries the encoded stream. If OBS runs on the VPS, the outbound route begins there; if OBS runs on a local computer, the local connection is in the path even if the media is stored on a VPS. Note the OVHcloud region, the YouTube ingest endpoint chosen in OBS, and the protocol. A VPS plan’s published bandwidth is specific to the offer and market, and a nominal rate does not guarantee stable throughput to one destination.
OVHcloud documents several tools that can add context: Looking Glass can show routes and routing tables from a data centre, Proof provides network speed tests, Smokeping observes ICMP reachability, latency and path changes, and Weathermap shows backbone link load. Consult OVHcloud’s network tools for current descriptions. These are supporting observations. A generic speed test, ICMP response, or traceroute does not prove that the precise stream flow to the selected YouTube ingest endpoint is healthy.
Compare observations near the times OBS shows drops, and repeat them rather than relying on one result. A route test from a different point in the network may be informative but cannot reproduce every part of the sending path. If OBS offers a different ingest server or endpoint, test it with the other output settings held constant where possible. A successful test to a different destination suggests a destination- or path-specific difference; it does not establish which provider is responsible.
Only inspect firewall rules, VPNs, security software, network prioritisation tools, or drivers when the machine and evidence make them relevant. OBS lists these, along with Wi-Fi and local network hardware, as possible connection factors. If OBS is running entirely on a VPS, your home Wi-Fi is not its outbound route. If OBS runs locally, local router, cable, or last-mile conditions may matter. The OVHcloud VPS FAQ can help you check product and security details, but it does not diagnose your particular stream.
If a lower bitrate and endpoint comparison do not change the symptom, assemble timestamps, the OBS log, region and plan, the affected destination, and repeated route, latency, or throughput observations before contacting OVHcloud support. If the sender is local and evidence points to the last-mile connection, OBS advises checking software and hardware factors and then involving the relevant ISP. Do not label a route faulty based on one traceroute or test.
Change one setting and test again
A useful test changes one variable at a time. Keep the same source, session duration, ingest endpoint, and output codec while testing bitrate; then restore the baseline before separately testing an endpoint or resolution. If you change bitrate, endpoint, and frame rate together, an improvement will not tell you which change mattered.
Use a repeatable test that includes the movement and audio of the real programme. Note the start time, counters, and any Live Control Room messages before and after each change. A short test may not reproduce a fault that appears intermittently, so compare at the time window when the issue normally occurs where practical. Do not leave a temporary low-quality setting in place simply because the counter briefly settled.
OBS documents Windows-only network optimisations and TCP pacing, binding to the default IP, trying IPv4-only as a reversible test, and dynamic bitrate as possible options. Applicability depends on the operating system and setup. Dynamic bitrate can reduce quality when the connection cannot keep up; it may mask the symptom, but OBS says it does not resolve the underlying connection issue. If IPv4-only makes no difference, restore the default IPv4/IPv6 setting rather than treating the test as a permanent fix.
For a channel whose main requirement is to keep an uploaded recording broadcasting without leaving OBS open on a machine, a file-based workflow can remove the need to diagnose a persistent desktop encoder session. StreamNeo may help with that specific operational pain: you upload the file and use your YouTube stream key, so your computer can be switched off while the broadcast runs. It is YouTube-only, and it does not replace checking that your channel, file, and live setup are ready.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does OBS dropped frames mean OVHcloud is the problem?
No. OBS defines the counter in terms of an unstable remote connection or a bitrate the connection cannot sustain, and the counter does not isolate the failing segment. Compare the OBS log, YouTube health messages, bitrate test, and route observations before attributing cause.
Should I lower the bitrate first?
It is a reasonable controlled test when network dropped frames rise and rendering or encoding indicators are steady. Keep the other settings constant and compare the counter; a lower rate helping is evidence that the prior setting was difficult for the route to sustain, not a definitive diagnosis of the plan or provider.
Is a YouTube-recommended bitrate guaranteed to work from my VPS?
No. YouTube’s recommendation is tied to the selected codec, resolution, and frame rate; it does not measure the stable throughput between your VPS and the chosen ingest endpoint. Verify current guidance, then test your actual route under the conditions that produce the problem.
What should I send to support?
Include the affected time, OBS session log, counters, VPS region and plan, bitrate and output settings, protocol and endpoint, and repeated network observations. This lets support investigate a specific interval and destination rather than relying on a general claim that the VPS is dropping frames.