When an NGINX RTMP relay on a low-cost VPS appears to drop frames on the way to YouTube, first find where the stream starts falling behind. The VPS may be encoding, simply forwarding an already encoded stream, or neither of those may be the source of the problem.
Record the encoder output, VPS measurements and YouTube stream-health messages over the same representative test. Then change one setting that matches the evidence and run the same test again; without logs or measurements, no single root cause or fix can be established.
Locate where frames are being dropped
Think of the route as a chain: video source, encoder, relay, outbound network and YouTube ingest. A warning at the end of the chain tells you that YouTube is receiving an issue, not which earlier link caused it. The first useful question is where the evidence of falling behind appears.
Write down the stream’s actual shape before changing settings: input and output resolution, frame rate, video and audio codecs, bitrate, and whether the VPS encodes the picture or forwards it unchanged. Also note whether the problem is continuous, begins after several hours, or appears only with movement or a change in source. Those distinctions guide the test; they do not prove a cause by themselves.
Start with the encoder. If FFmpeg creates the outgoing video, save its full log and periodic progress output during the affected period. Look for signs that processing is not keeping pace, alongside any reported duplicated or dropped frames. Interpret those messages in context: FFmpeg options and progress fields depend on the command and build, so an isolated frame-rate flag is not a universal detector or remedy. If the source itself has uneven timing, the encoder may report a problem that a relay cannot correct. For footage from phones, this guide to removing variable frame rate before streaming may help you check the input before treating the VPS as the suspect.
Next compare the stream entering the relay with what leaves it. If the encoder stays on pace but the outbound stream stalls or varies, the relay process or network path deserves attention. Finally line up those observations with YouTube’s health timeline. The location of the first repeatable discrepancy is more informative than the phrase “dropped frames” on its own.
There are no logs, host measurements or reproduced failure supplied for this case. A low-cost VPS is therefore a possibility to investigate, not a confirmed explanation. If the evidence does not identify a link yet, collect a test rather than applying several speculative changes at once.
Record YouTube stream-health indicators
Open the YouTube Live Control Room during a test and note the health status and exact warning text, including when it appears and clears. “Not receiving enough video” is an ingestion symptom: it describes what reaches YouTube, not whether the encoder, relay or network is responsible. Save the message or write down its timing so you can compare it with FFmpeg output and host measurements from that same period.
YouTube’s live encoder settings guidance says to test before going live with audio and movement similar to the planned stream, monitor stream health, and use a bitrate suited to a reliable connection. It also recommends constant bitrate (CBR) and a two-second keyframe interval, with a maximum of four seconds. Treat these as platform guidance to check against your configuration, not as proof that a mismatch caused this particular fault.
For a sense of how recommendations vary, YouTube’s current H.264 table lists 10 Mbps for 1080p30 and 6 Mbps for 720p30. These are examples from the table, not universal targets: its recommendations vary by codec, resolution and frame rate. Use the official page for the current settings for your stream, and compare them with what your upload path can actually sustain. The minimum listed in a table is not a guarantee of stable delivery.
If YouTube reports a configuration warning, compare the codec, bitrate, frame rate and keyframe cadence with the official guidance. If it reports insufficient incoming video while the settings appear aligned, correlate the warning’s timing with encoder progress, VPS resources and outgoing traffic before deciding what to change. YouTube recommends a speed test to assess upload bitrate, but a single result should not be mistaken for evidence of stable capacity throughout an overnight broadcast.
Determine whether the VPS transcodes or forwards
The VPS’s role changes what to measure first. In a transcode, FFmpeg decodes and re-encodes video on the host; CPU demand is then a plausible factor to test. In forwarding or stream-copy mode, the host passes through encoded media without re-encoding the picture. In that case, an encoding preset cannot reduce work the VPS is not doing, so check forwarding behaviour and network performance first.
Inspect the actual FFmpeg command or service configuration, not a description of the setup from memory. Options that select a video encoder indicate re-encoding; stream-copy options indicate that the existing encoded stream is being passed onward. Audio may be treated differently from video, so check both paths. If a script generates the command, capture the expanded command used during the failing run.
The distinction matters especially on an inexpensive VPS. A busy CPU is relevant to a transcode, but it does not establish the cause without timing that matches the frame lag. A quiet CPU does not by itself prove that forwarding is healthy: outbound throughput, packet loss, process limits or relay handling may still need checking. Conversely, a VPS with modest resources can forward a stream reliably if the path and workload permit it.
If you are unsure whether your FFmpeg workflow encodes or copies, compare it with the 24/7 playlist streaming walkthrough, then verify the options in the command you actually run. Do not transplant a command blindly: a tutorial’s assumptions about input files, codecs and host capacity may not match your stream.
Measure CPU and resource pressure
Measure while the stream is running and, if possible, during the part of the test when the issue appears. Record CPU use, load, memory pressure and actual outbound throughput. Keep timestamps with the encoder log and YouTube health observations. A snapshot taken after a warning has cleared is less useful than data from the interval in which it began.
If FFmpeg transcodes on the VPS, check whether CPU pressure coincides with the encoder falling behind. If it does, run a controlled test with a less demanding encode preset, or reduce resolution or frame rate, changing one item at a time. Another option is to encode upstream and forward the resulting stream. These are diagnostic branches, not promises that a particular setting will fix a stream. Confirm the output still matches YouTube’s current requirements and remains suitable for the intended channel.
If the VPS only forwards, do not start by changing an encoding preset. Instead, examine whether the relay process is alive and handling the incoming and outgoing session, then compare measured network use with the configured video and audio bitrates. Leave headroom for bitrate variation and other traffic rather than assuming that a nominal link rate is continuously available to the stream.
Memory pressure or other workloads can also coincide with a disruption, but do not infer causality from a busy-looking dashboard. Note what changed, when it changed, and whether the encoder or outbound stream fell behind at the same time. Provider allocations and network conditions depend on the actual VPS plan; no plan details or measurements are supplied here, so a larger server cannot be recommended on evidence alone.
A low-cost host is not automatically inadequate, and the research for this issue provides no measured prevalence rate for VPS-related drops or success rate for any remedy. If your tests do show the host reaching a limit during the failure, compare a more suitable plan or move encoding upstream. If they do not, follow the chain to the next link instead of paying for capacity that may not address the problem.
Check relay and network behaviour
Treat NGINX RTMP as a link to inspect, not as a presumed culprit. Check that the running configuration parses with nginx -t, review the relevant application and host logs, and confirm that the expected stream session remains present during the affected interval. A syntax check tells you about configuration validity; it does not certify that the live media path is healthy.
Compare evidence at both ends of the relay. Is the incoming stream arriving at a steady rate? Does the outgoing side continue towards YouTube when the incoming side is healthy? Use whatever monitoring and logs your deployment actually provides, and avoid assuming that a particular dropped-frame counter or directive exists: general NGINX stream-session documentation describes session processing, but does not establish a universal RTMP dropped-frame setting. A process restart may temporarily restore a session while hiding the cause, so record what happened before restarting where practical.
For the network path, measure outbound throughput while streaming and look for variation at the same times as YouTube warnings. If the sustainable upload is insufficient for the configured stream, lower video bitrate and retest; if necessary, lower resolution or frame rate as well. Check that other host traffic is not competing for the same capacity. A speed test is useful context, but the stream itself is the representative load that matters.
YouTube recommends RTMPS, its secure extension to RTMP, in its ingestion protocol documentation. That security recommendation does not show that RTMP caused frame drops, and changing protocol alone should not be presented as a fix. Use the protocol your setup supports and check for a documented connection or configuration issue before changing it.
Change one variable and retest
Build a short preflight that resembles the real channel: use the same source type, audio, motion, output resolution and intended duration where practical. For a devotional loop, include the actual audio and a representative passage; for local news or a study channel, include the type of scene changes the full stream will contain. YouTube specifically advises testing with similar movement and audio, then monitoring stream health.
Make one change per run and keep a simple record: the setting changed, time, encoder progress, host measurements, outgoing bitrate and YouTube’s health messages. If you lower bitrate, hold other settings steady for that run. If you reduce resolution, do not also change the encoder preset and relay configuration, or you will not know which change affected the result.
Use the branch suggested by the measurements. For a transcode that falls behind alongside high CPU pressure, reduce encode complexity or move encoding upstream and compare. For a forward-only relay with healthy CPU but unstable outbound traffic, investigate capacity and path stability before considering encoding changes. For a YouTube configuration warning, align settings with its current encoder guidance. If the same symptom persists without a corresponding measurement, gather more evidence rather than increasing buffers by reflex.
Keep the intended operating trade-off in view. Lower bitrate may make delivery more sustainable but can reduce picture detail; lower frame rate or resolution changes the viewing experience. More CPU-efficient encoding may alter quality or compression efficiency. Choose the least disruptive adjustment supported by the test, and make a separate representative run before relying on it for a long broadcast.
Document results before choosing a fix
A small incident record makes the next decision less speculative. Note the stream shape, whether the VPS transcodes or forwards, the start and end time of the symptom, encoder messages, CPU and memory observations, outbound throughput, relay log entries and YouTube health text. Include the exact command or relevant configuration version so a future test can be compared with the same setup.
A useful comparison is not simply “before” and “after”. It is two runs where you know what changed and whether the suspected link improved. If the warning disappears but the encoder still falls behind, the test may not have addressed the encoder issue. If CPU remains steady during a relay-only stream while outgoing traffic fluctuates, investigate the path rather than attributing the result to transcoding.
| Evidence during the affected interval | What it points towards | Next controlled check |
|---|---|---|
| Encoder progress falls behind during VPS transcoding, with CPU pressure at the same time | Encoding load is plausible | Test a simpler encode or encode upstream, one change per run |
| VPS forwards an existing stream; CPU is not pressured, but outgoing traffic varies | Relay or network path needs attention | Compare incoming and outgoing behaviour and measure outbound capacity |
| Encoder and VPS measurements look steady, while YouTube reports a configuration warning | Settings may not match platform guidance | Check codec, bitrate, frame rate and keyframe interval against YouTube’s current page |
| No measurements line up with the warning | Cause remains unknown | Capture a representative test with synchronised logs and health observations |
This table is a way to choose the next test, not a diagnosis for a machine whose logs have not been examined. If a host-capacity problem is measured, compare the cost and operational burden of a better-suited VPS with encoding elsewhere. If your main difficulty is keeping a prerecorded loop running without leaving your own computer on, StreamNeo can remove the need to maintain that local machine for the broadcast; it does not change the need to verify the video and channel settings.
For recurring streams, save a known-good configuration and test again after material changes to the source, encoder, relay or provider. YouTube may revise its guidance, so check the official page rather than treating an old bitrate table as permanent. The dropped-frame troubleshooting guide for prerecorded YouTube streams offers a complementary way to think about symptoms across a stream path, while this diagnosis keeps the VPS’s actual role explicit.
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 a YouTube “not receiving enough video” warning mean the VPS is too slow?
No. It says YouTube is receiving insufficient video, but does not identify whether the encoder, relay or outbound path is responsible. Compare the warning’s timing with encoder output and VPS measurements before changing host plans.
Should I lower bitrate first?
Only if the evidence suggests the configured bitrate is not sustainable on the upload path, or a controlled test is needed to check that possibility. Lowering it can affect picture quality, and the right setting depends on codec, resolution and frame rate; consult YouTube’s current guidance and retest under representative conditions.
Should I change FFmpeg’s preset on a low-cost VPS?
That is a reasonable test only if FFmpeg is actually encoding on the VPS and measurements show pressure that coincides with falling behind. If the VPS forwards an already encoded stream, a preset change is not the first remedy; investigate forwarding and network behaviour instead.
Will switching from RTMP to RTMPS stop dropped frames?
YouTube recommends RTMPS as a secure ingestion protocol, but that recommendation does not establish that RTMP caused a particular frame-drop problem. Check the connection evidence and configuration, then test a protocol change only if it addresses an observed issue.