An Ubuntu VPS can run FFmpeg to send a prerecorded gameplay file to YouTube Live, without keeping your home computer switched on. The setup is a technical route for playback, not permission to rebroadcast a game or a guarantee of monetisation.
The careful order is: check rights and channel access, prepare the file and VPS, create an encoder stream in YouTube Studio, connect FFmpeg with the supplied ingest details, then test and monitor the result. The steps below favour checking each link in that chain before you make a rerun public.
What an Ubuntu VPS rerun does
A rerun sends an existing gameplay recording to YouTube as a live feed. FFmpeg reads the file and publishes its video and audio to the ingest destination YouTube provides. In this arrangement, the VPS replaces a computer in your home that would otherwise need to play the file and maintain the encoder connection.
The word “live” describes the delivery format here; it does not mean the footage is being captured in real time. Nor does putting a recording through an encoder change who owns the gameplay, music, voice chat or other material in it. A game publisher’s streaming rules and YouTube’s copyright and monetisation policies remain separate from whether FFmpeg can transmit the file.
The same broad distinction applies to other continuous file-based channels. For example, how a 24/7 background-music stream is put together may help you think through source material and continuity, but gaming footage brings its own publisher terms and audiovisual rights to check.
A VPS does not make every part of the setup automatic. You still need a valid file, an FFmpeg build that can read and encode it, enough sustained outbound bandwidth, correct YouTube ingest details and a way to notice when the feed stops or develops problems. A process that is still running is not proof that viewers are receiving sound and picture.
Check game and content permissions first
Before selecting a VPS plan or uploading a long recording, identify the game and the material inside the recording. Read the publisher’s current streaming or video policy, including its rules for continuous broadcasts, commercial use, edits, music and other third-party content. Because the game is unspecified, no general setup guide can determine whether a particular rerun is allowed.
Check the rights to more than the game image. A recording can include licensed soundtrack music, a co-player’s voice, a tournament overlay, chat or footage from another creator. Each may be subject to a different permission. If a rights holder has given you a licence, confirm that it covers this use and follow any channel-allowlisting process they require.
YouTube says it scans live streams for third-party content. A detected match can lead to an interruption, and YouTube notes that a rights owner may need to allowlist a licensed channel. See YouTube’s live-streaming copyright guidance for the current process. A successful test does not establish that the content will remain uninterrupted later.
Treat monetisation as another check, not an outcome of the encoding setup. YouTube’s channel monetisation policies apply to live streams and discuss reused, repetitive and mass-produced content. A stream that technically runs may still raise eligibility questions. Review the current policy for your channel and material; do not assume that keeping a game on a continuous loop qualifies for revenue.
Prepare the Ubuntu VPS and gameplay file
Choose a supported Ubuntu image and install FFmpeg from a package source appropriate to that release. Package versions and available codec support vary, so check what is actually installed rather than relying on a command or version copied from a different server. FFmpeg’s documentation is regenerated for current revisions; consult the local build’s help and documentation when its behaviour differs from an example.
Before a long broadcast, inspect the input file. Confirm that it opens, that it contains the expected video and audio streams, and that playback includes representative motion and sound. A file can be valid while still having an unexpected frame rate, resolution, codec, aspect ratio or audio track. These details affect your output settings and what you should look for in the YouTube preview.
Keep the source file in a location the account running FFmpeg can read. Check available disk space, permissions and the file path, and avoid beginning a test with an incomplete upload. If the recording is large, transferring it to the VPS can take time; verify the finished file before scheduling a public run. Do not delete your only good copy just because the server copy appears to be in place.
A VPS comparison should look beyond the advertised port speed. Ask whether outbound transfer is capped or subject to fair-use terms, and whether the provider describes sustained throughput rather than a brief peak. Consider the route from that server to YouTube’s ingest point, the CPU available for encoding, storage for the source and logs, and how you will access the machine if the process stops. A cheap plan that cannot sustain the chosen bitrate or has a restrictive transfer allowance may not suit a continuous feed.
Start with a short, controlled test rather than an unattended all-night run. This helps separate file, codec, key and network problems while you are available to inspect them. You can also borrow the practical lesson from checking NVENC support in FFmpeg on a VPS: verify the capability on your actual build before relying on a particular hardware encoder. Do not assume a VPS offers a GPU or that hardware encoding will be available.
Create a YouTube Live stream
In YouTube Studio, open Live Control Room and create or schedule a stream using the encoder workflow. YouTube’s encoder setup instructions describe where to obtain the server URL and stream key. Copy those details carefully; the URL is the destination and the key identifies your channel’s ingest session.
A scheduled stream can help you plan the start and give viewers a page to find, but scheduling does not validate your file or rights. For a first test, choose private or unlisted visibility if that suits your channel and purpose. Confirm what visibility setting you selected before you announce or share the stream.
Treat the stream key as a password. Do not include it in a public post, screenshot, article, ticket or screen recording. Avoid pasting a real key into shell history or a service file that other users can read. YouTube describes the key as encoder credentials and allows channel owners or managers to reset it. If it is exposed, reset it in Studio and update the configuration that uses it.
YouTube’s stream settings also matter to expectations about duration and recordings. Its guidance says streams under 12 hours are automatically archived; do not assume that a longer continuous session will be archived in the same way or that one encoder session can run indefinitely. Plan to check the current stream settings and decide how you will handle a long broadcast before making it public.
Configure FFmpeg with the stream URL and key
FFmpeg’s documented RTMP publishing pattern is:
ffmpeg -re -i INPUT -f flv RTMP_OUTPUT
This shows the shape of a command, not a complete universal recipe. Replace INPUT with the path to your media file. Construct RTMP_OUTPUT from the ingest URL and key shown for your stream, using the secure endpoint YouTube supplies when available. Never publish a real key in a guide or copy one into a shared command transcript.
The -re option paces reading so a file is sent in real time rather than as fast as the process can read it. The FLV output format is part of FFmpeg’s documented RTMP example. You may need explicit video and audio encoders and output settings for your source and YouTube’s current requirements; an input that plays locally does not prove it can be sent as-is to the ingest service.
FFmpeg documents RTMP as streaming media over TCP/IP and RTMPS as the corresponding secure connection. Exact endpoint syntax and build support can differ, so follow the URL YouTube gives you and verify the local FFmpeg protocol support. If the command exits immediately, read the error rather than repeatedly launching it: an invalid path, unsupported codec, malformed destination or inaccessible file needs a different fix.
For a first test, keep the command and its output private. Do not put the key directly into a script that is world-readable or share a terminal capture with credentials visible. If you choose to manage the command as a background service later, protect the configuration, make logs useful without logging secrets, and know how to stop the process before starting a second copy. Two encoders using the same stream details can make diagnosis harder.
Once FFmpeg starts, check both ends. The process should be producing output without repeated fatal errors, and Live Control Room should receive a preview. If FFmpeg reports that it is sending data but Studio shows no usable picture or audio, do not treat the process status as success. Recheck the endpoint, key, selected stream, codecs and source streams.
Choose settings for the source and available network
Match the output to the recording and the connection you can sustain. YouTube lists H.264 as supported, recommends constant bitrate (CBR), and recommends a two-second keyframe interval that should not exceed four seconds. Its current H.264 guidance gives the following recommended video bitrates. These are ingest recommendations, not a promise of a particular visual quality or a guarantee that your VPS can sustain them.
| Output profile | YouTube-recommended H.264 video bitrate |
|---|---|
| 720p at 30 fps | 8 Mbps |
| 720p at 60 fps | 8 Mbps |
| 1080p at 30 fps | 14 Mbps |
| 1080p at 60 fps | 17 Mbps |
Values are from YouTube’s encoder settings, checked for this guide in October 2026. YouTube also lists AAC or MP3 audio. Check its current table before you configure a real broadcast, as encoder recommendations may change.
Do not select 1080p60 merely because the source or server can name that mode. If the recording is 720p30, encoding it to a higher frame rate or resolution does not restore detail that is absent from the source. A conservative profile that matches the actual recording is easier to test and can require less outbound capacity. The right choice depends on the source, how much motion is present and the bandwidth available from that specific VPS.
YouTube advises that total stream bitrate must fit within available upload bandwidth and recommends leaving about 20% headroom. Include audio when considering the total, and do not use a provider’s port-speed label as proof of sustained capacity. A VPS route can vary, and a transfer cap can make a technically stable stream expensive or unsuitable over time. Check the provider’s terms and test the server’s outbound path before relying on it.
If the network cannot hold a higher profile steadily, choose a lower setting and test representative gameplay. Watch the preview and stream-health messages while the recording includes both quiet menus and fast movement. A still menu can hide blockiness, dropped frames or audio trouble that appears during action. Make one change at a time so you can tell whether the result improved.
Use RTMPS and verify stream health
Use the secure ingest URL YouTube provides when your FFmpeg build supports it. YouTube recommends RTMPS for encoder connections. Confirm that the address you use is the one displayed for your stream, rather than assuming that a remembered URL or example from elsewhere is current.
Before a public run, send a short private or unlisted test and inspect the Live Control Room preview. Check that the image is the expected game, motion looks coherent, audio is present and not distorted, and the selected resolution and frame rate are sensible. Look at the health panel for warnings and give the test enough varied content to expose problems beyond a static opening screen. YouTube’s live-streaming tips recommend preparing the encoder and checking the preview and stream quality before going live.
If health warnings appear, work through likely causes rather than changing everything at once. Compare the configured bitrate with what the VPS can sustain; check whether the file’s frame rate or codecs differ from your assumptions; inspect FFmpeg output for encoding or connection errors; and confirm that the key belongs to the intended stream. A preview with a picture but no sound is not ready. Nor is a clean preview in a short test proof against future interruptions, content claims or a provider-side limit.
For a longer run, decide how someone will notice a stopped process or unhealthy feed. You can arrange a periodic manual check or a process supervisor that restarts a crashed FFmpeg process. That can help recover from a process exit, but it cannot correct a bad key, a broken source file, insufficient bandwidth, a transfer restriction, a rights claim or a YouTube policy decision. Avoid presenting any restart rule as an uptime guarantee.
Make a simple operational note for whoever checks the channel: which Studio stream is scheduled, where the protected configuration is stored, how to stop FFmpeg cleanly, and where to inspect the preview and process logs. If the stream key has been exposed, reset it rather than relying on the old value. This small handover is useful if the person who configured the VPS is not available when an alert arrives.
When the file and channel are ready, how playlist order is handled for a YouTube gaming rerun in India may help with planning a different playback workflow. An OBS playlist and an FFmpeg file command are not the same configuration, so do not copy settings between them without checking what each tool is doing.
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
Can I use FFmpeg to play prerecorded gameplay as a YouTube live stream?
Yes, FFmpeg can publish a file to a live ingest destination, provided the source, build and output settings are suitable. That answers the technical question only; check the publisher’s current rules and YouTube policies for the specific footage and channel.
Do I need to leave my own computer running?
If FFmpeg is running on the VPS and can access the media file, your home computer does not need to perform the playback. You still need a way to check the VPS process and YouTube’s preview, and a VPS failure or network problem can stop the feed.
Does an uninterrupted test mean the rerun is permitted or monetisable?
No. A test only shows that the connection and media worked at that time. Rights holders can have separate rules, YouTube can detect third-party content, and monetisation eligibility depends on current channel and content policies.
What should I check first if YouTube shows no preview?
Confirm that FFmpeg is still running without fatal errors, that the server URL and key match the intended Studio stream, and that the source path and codecs are usable. Then check the health messages and connection capacity; avoid sharing terminal output until you have removed any stream key.