Dropped frames on a 24/7 YouTube stream hosted on Hetzner can come from the source, encoder timing, CPU contention or delivery to YouTube. Start with YouTube Live Control Room’s exact health message and your encoder logs; changing server size before isolating the fault can leave the real cause untouched.
Then compare the server you actually have—shared cloud, dedicated-CPU CCX or a dedicated root server—with the stream’s sustained workload, traffic terms, route and recovery needs. Predictable resources and a published traffic allowance can help you plan, but neither guarantees uninterrupted video.
Start with the evidence, not the product label
“Dropped frames” is not a diagnosis. It may describe frames an encoder deliberately drops to meet a timing mode, a process that cannot produce frames quickly enough, or a stream that is produced properly but does not reach YouTube steadily. Find where the fault appears before buying a larger instance or changing encoder flags.
During a representative period, record the precise health text and timestamps in YouTube Live Control Room. Keep the full encoder command and logs, version, resolution, frame rate, bitrate, CPU utilisation, load, network throughput and errors. Also note the Hetzner product, location and current traffic use. If the problem appears only at certain times, include those periods: a brief spot check can miss a recurring workload spike or input interruption.
YouTube lists health errors covering such areas as codec and format, bitrate, video settings and keyframe frequency. Treat the specific message as a lead, not a reason to alter several settings at once. Make one relevant change, then check whether the same message and timestamps recur. The official troubleshooting guidance also points operators to encoder version, preview, CPU load, local archive and outbound internet strength.
Compare what YouTube receives with what the encoder produces. If a local preview or archive is already stuttering, investigate the source, decoder, filters and host workload. If the local output is smooth but YouTube reports insufficient video, look at the outbound path and ingest health. A local archive is useful evidence, but it cannot by itself establish that the delivery path is healthy.
Compare CPU predictability across server types
A stream that loops a prepared file may have a modest, steady workload; scaling, overlays, multiple outputs or expensive filters can change that substantially. Measure the actual encoder process during the moments drops occur. Product labels do not tell you how much CPU headroom your particular command needs.
| Hetzner choice | What to expect | When it may fit | What to verify |
|---|---|---|---|
| Shared-resource Cloud | A virtual machine uses physical-host resources shared with other workloads. Available CPU performance may vary with contention. | A measured, relatively light workload where cost and simple provisioning matter. | CPU use and load during drops; whether contention corresponds with the fault; the current product terms. |
| Dedicated-CPU CCX | A Cloud option with dedicated CPU resources rather than shared CPU allocation. It improves resource predictability, not end-to-end delivery certainty. | Encoding stays CPU-bound or varies under a shared-resource workload, and measured evidence justifies a more predictable allocation. | The exact plan and location, sustained workload, memory and network needs, and current listed terms. |
| Dedicated root server | A physical server gives you control of the machine and its capacity, but still needs correct configuration and a working route to YouTube. | A sustained workload or broader deployment that warrants a physical machine and its administration overhead. | CPU model and capacity, disk and network setup, location, traffic terms, maintenance and recovery responsibilities. |
Hetzner describes Cloud servers as virtual machines on physical servers and distinguishes shared from dedicated resource classes in its Cloud overview. CCX is not a root server: it remains a Cloud product, with a different CPU-resource model. A dedicated root server is a separate physical-server choice. Keep those distinctions clear when comparing performance and costs.
A CPU graph that reaches capacity at the same time as encoder lag points towards an encoding bottleneck, but utilisation alone is not conclusive. Look at the process, system load and logs together. If the output is choppy even when CPU has headroom, check input timing, storage reads, filters and frame-rate handling before moving the job to a larger machine.
If the evidence shows shared-resource contention, a dedicated-CPU Cloud plan is one comparison to make. If sustained encoding needs more capacity or machine-level control, evaluate a root server. If neither server class changes the encoder’s timing or YouTube route, neither is a fix. A helpful precedent for separating stream resilience from host choice is this guide to keeping an FFmpeg stream running through outages.
Estimate outbound traffic and overage exposure
A 24/7 stream sends the same programme continuously, so estimate monthly transfer from the configured outbound bitrate rather than a speed-test peak. As a rough planning method, convert the video-and-audio bitrate to bytes per second, multiply by the hours you expect to stream, then allow for protocol overhead and any other traffic. This is an estimate, not a throughput guarantee or an invoice forecast.
A steady stream configured at a higher bitrate uses more outbound data than the same stream at a lower bitrate. Compare this estimate with the allowance for the actual server product and location. Hetzner’s traffic page publishes different included traffic by product and region. For example, its EU Cloud entries show 20 TB for CX, CPX and CAX; that example is not a universal allowance and does not establish what applies to CCX or a particular root-server offer. Check the current terms for your own account and plan before relying on any figure.
Included monthly traffic and available moment-to-moment upload capacity are different questions. An allowance describes a transfer policy; it does not mean an instance can deliver a particular bitrate continuously. Check the account’s usage counter and terms for overage exposure, and measure sustained upload behaviour from the server. If your bitrate is close to the path’s reliable capacity, lowering it or resolution may be more useful than buying a larger traffic allowance.
Choose bitrate using the actual resolution and frame rate configured in Live Control Room. YouTube’s live encoder settings describe recommended settings including CBR, H.264, AAC or MP3 audio and a two-second keyframe interval, not over four seconds. Recommendations depend on configuration; follow the specific ingest profile and health message for your stream rather than copying a setting from another channel.
Consider region and route to YouTube ingest
The server’s location affects the route packets take to YouTube’s ingest endpoint. A geographically nearer region may reduce path length, but distance alone does not establish that a route is stable or uncongested. Likewise, good results from one speed test do not prove that the route will sustain your stream at every hour of the day.
Use the relevant YouTube ingest destination shown for your stream and observe throughput and errors from the server over a representative period. Compare those observations with YouTube’s health timestamps. If delivery falters while local output remains clean, test the route and check whether an alternate region is available on the product you are considering. Do not assume a move will fix the problem without comparing the new path under the same stream settings.
Record the product family and datacentre location as part of any comparison. Cloud traffic terms and product availability can differ by region; root-server availability and terms are not interchangeable with Cloud terms. If you change region, re-check traffic allowance, network setup and the account’s public connectivity requirements. The machine still needs a configured public network path to send video to YouTube.
The YouTube health panel helps distinguish an ingest problem from a local encoding problem, but it cannot tell you that a particular Hetzner route will remain sound. Preserve timestamps so you can compare events with local CPU, encoder and network evidence. This is more useful than treating “server location” as a single explanation for every dropped-frame alert.
Compare monthly costs without assuming today’s price
A meaningful monthly comparison includes more than the headline server line. Account for the actual plan, location, traffic exposure, any storage or IP-related costs, and the work needed to maintain and recover the encoder. Prices and product terms can change, so do not base a decision on an undated figure copied from an old comparison.
Check the current Hetzner listing for the exact Cloud, CCX or root-server product and location you would use. When stating a price in your own budget notes, record the source and date—for example, “as listed on Hetzner’s site in September 2026”—and re-check it before committing. This article does not assert current Hetzner prices. A traffic allowance that looks generous is not a substitute for checking overage policy and sustained delivery conditions.
| Cost question | Shared Cloud | Dedicated-CPU CCX | Dedicated root server |
|---|---|---|---|
| What are you chiefly paying for? | A virtual machine with shared-resource characteristics. | A Cloud VM with dedicated CPU resources. | A physical machine and its associated service terms. |
| What performance question matters? | Does measured CPU performance remain sufficient during the whole workload? | Does dedicated CPU capacity resolve the measured contention? | Is the physical machine’s capacity appropriate for your continuous workload? |
| What should you check on the bill? | Exact plan, location, traffic and any additional items. | Exact CCX plan, location, traffic and any additional items. | Server offer, location, traffic and any additional items. |
| What work remains yours? | Encoder configuration, observation and recovery planning. | Encoder configuration, observation and recovery planning. | Those tasks plus the operating and maintenance choices associated with a physical server. |
Choose the least complex option that meets measured needs with useful headroom, rather than paying for a label. If you are encoding a single prepared loop and the process stays well within capacity, moving to a physical machine may add administration without solving anything. If evidence ties drops to shared CPU contention, a more predictable allocation can be worth testing against the full monthly cost.
Plan for interruption and recovery
A 24/7 stream needs an operational plan for when an encoder exits, the source stalls, the network breaks or YouTube disconnects the session. A bigger server does not restart a failed process by itself. Decide how the process is monitored, how it is restarted, what happens after a host reboot and how you will notice a failure that does not recover cleanly.
For a self-managed setup, test recovery rather than assuming a service manager or script behaves as intended. Confirm that the encoder restarts with the correct input and stream key, that logs are retained, and that a failed source does not create a rapid restart loop. Keep a safe, private record of credentials and test a recovery without exposing the key. Check the Live Control Room after a restart to confirm that YouTube is receiving the stream and that the health message has cleared.
Monitor the evidence that separates likely causes: process state, encoder logs, CPU and load, network errors and YouTube health. YouTube’s health status documentation describes health status and issues including insufficient incoming video. Set an alerting approach that matches the cost of an unnoticed interruption; official guidance does not prescribe a particular interval for every continuous stream.
Hetzner’s Cloud SLA describes commercially reasonable efforts towards 99.9% monthly server availability, subject to its definitions and exclusions. That availability measure concerns server operation, not frame-perfect encoding, the path to YouTube ingest or uninterrupted playback for viewers. A server availability statement should therefore inform one part of a risk assessment, not replace stream monitoring and recovery tests.
If the main operational burden is keeping a computer and encoder process running continuously, StreamNeo removes that specific host-and-restart task by turning an uploaded file into a YouTube live stream that runs without your computer switched on. It is relevant to a prepared-file loop, not to every live production: a channel that needs a custom encoder pipeline, live inputs or control beyond YouTube-only streaming should assess those requirements first.
Choose by encoding and relay requirements
The right server depends on what you are asking it to encode. Replaying a prepared video, decoding a network feed, compositing overlays and transcoding multiple renditions are different workloads. Write down input type, output resolution and frame rate, filters, audio handling, and whether a local archive is required. Then observe that pipeline under its normal and peak conditions.
If you use FFmpeg, preserve the complete command and inspect timing options before changing them. Its documentation explains that -fps_mode cfr can drop or duplicate frames to achieve the requested constant frame rate, while vfr may drop frames to avoid duplicate timestamps. That behaviour can look like a host problem when the underlying issue is input timestamps or output timing. Check logs and the source’s pacing rather than adding a flag because it helped a different command.
The -re or -readrate options govern input reading. FFmpeg cautions against applying a low read rate to a real capture device or live input because packet loss can result. A file being replayed is not the same as an already paced live feed. Identify which kind of input you have, then select timing behaviour that fits it. A continuous OBS playlist workflow is a different operating model from a headless FFmpeg relay and should not be treated as a command-line recipe.
For a useful fault split, check whether a local preview or archive has the same stutter. If it does, look earlier in the chain: file reads, source decoding, filters, CPU contention or frame timing. If local output looks sound but YouTube says it is not receiving enough video, test sustained outbound delivery and review the ingest health message. A guide to recovering an aarti stream after YouTube disconnects the encoder can help you think through what should happen after a disconnection; it does not replace checking the cause of the current fault.
A relay requirement also changes the comparison. If the server must receive and forward a live source, investigate its input link and timing as well as its YouTube output. If it only has to repeat a stored file, disk access and loop behaviour may matter more. The file-system guide for storing stream videos is relevant when storage behaviour is part of the source path, but it cannot diagnose an unstable network route or an overloaded encoder.
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 changing to a larger Hetzner server fix dropped frames?
Only if evidence points to a resource limit the larger choice addresses, such as sustained CPU contention while encoding. It will not correct a bad frame-rate mode, a misconfigured bitrate, a failing input or an unstable route to YouTube. Compare logs and health timestamps before changing capacity.
Is CCX the same as a Hetzner dedicated root server?
No. CCX is a Cloud product with dedicated CPU resources, while a dedicated root server is a separate physical-server option. Compare their current product terms and administration needs separately rather than treating “dedicated” as one category.
What should I check first when YouTube says it is not receiving enough video?
Check whether the local encoder output or archive is already choppy, then compare the message timestamps with CPU, encoder and network evidence. If local output is healthy, examine sustained outbound delivery and the ingest route, and follow the exact Live Control Room message. Avoid changing several settings at once.
Does Hetzner’s availability figure guarantee my stream stays live?
No. The Cloud SLA’s availability language is about server operation under its definitions and exclusions. It does not guarantee encoder health, delivery to YouTube or uninterrupted playback, so you still need monitoring and a tested recovery plan.