A Linux VPS can send a prerecorded gaming video to YouTube as a live event when FFmpeg reads the file at real-time pace and publishes it to the ingest address for your encoder stream. The settings that work depend on the source, chosen resolution and frame rate, codec, VPS CPU allocation, and sustained outbound capacity.
This is a hands-on workflow: prepare a file the server can access, create or select a YouTube stream, protect its key, start FFmpeg, then check the preview and stream health before ending the event. Test the exact command and output mode before relying on it for a scheduled broadcast.
Prepare the VOD and VPS
Start with the video file, not the FFmpeg command. Make sure the VPS can read the full VOD from local storage or a mounted location that remains available for the whole broadcast. If you transfer it over a network, wait for the transfer to finish and check that the file opens before you schedule the stream. A partial upload or a path that changes after a reboot can stop playback even when the YouTube settings are correct.
Inspect the input before mapping streams. FFmpeg can report the available video and audio streams, codecs, dimensions, and frame rate with its inspection tools. A simple source may contain one video track and one audio track, but gameplay captures can also contain commentary tracks, game audio, language variants, or no audio at all. The example command later assumes one video stream and one audio stream; change the mapping deliberately if your file differs.
Check that the server is suitable for the output you have chosen. Software encoding consumes CPU, and the demand changes with resolution, frame rate, codec, and encoder preset. A faster x264 preset usually reduces encoding work at the cost of compression efficiency; a slower preset may use more CPU. There is no universal core count that makes every setting safe, so test the actual mode on the VPS and watch for sustained CPU saturation or output falling behind.
The network needs enough sustained outbound capacity for the encoded stream, with allowance for ordinary variation and other traffic on the VPS. Compare the target video and audio bitrates with the provider’s network and traffic policies. A nominal connection speed alone does not establish that a long-running stream will stay steady. If the provider limits sustained traffic or terminates long-running processes, those policies matter as much as the command.
For a continuously running channel or a repeated playlist rather than a single VOD event, the operational questions differ. See the guide to choosing an Indian VPS for a 24/7 YouTube lofi radio stream for a broader look at capacity and provider constraints. This VOD workflow remains focused on one file and one event.
Create or select a YouTube encoder stream
In YouTube Studio, open Live Control Room and create or select an encoder stream. Copy the stream URL and stream key shown for that stream. YouTube’s encoder setup guidance describes this workflow and the settings that apply to a live encoder feed. If you already have a stream configured for the channel, confirm that you have selected the intended one rather than reusing credentials from a different event.
Treat the key as a password. Do not put it in a public repository, paste it into a screenshot, or leave it in a shared document. A command entered directly in a shell can also remain in shell history; use an access-controlled configuration file or another protected secret source if that is a concern. Restrict file permissions, avoid logging the expanded command, and reset the key through YouTube if you believe it has been exposed. YouTube’s stream settings help explains stream keys and managing them.
Choose settings from YouTube’s current encoder table for the mode you intend to send. YouTube recommends RTMPS and publishes recommendations by codec, resolution, and frame rate; bitrate figures are not interchangeable across modes. For example, its current H.264 guidance lists 17 Mbps for 1080p at 60 fps and 14 Mbps for 1080p at 30 fps. These are YouTube recommendations, not a statement that your VPS or network can sustain either rate. Read the current table when setting up, as recommendations can change.
YouTube’s encoder guidance also covers H.264, H.265, and AV1 options, up to 60 fps, constant bitrate (CBR), and keyframe intervals. Do not assume that every FFmpeg build supports every codec or that your chosen YouTube mode accepts any arbitrary combination. Start with the codec and mode you can encode and test reliably. If you are scheduling an event as well as preparing the encoder, the YouTube Studio scheduling guide for 4K 60fps streams covers the Studio-side planning context; it does not replace the encoder requirements for your actual output.
Configure FFmpeg with the ingest URL and key
Use the stream-specific ingest address and key in the destination. YouTube recommends RTMPS, which FFmpeg documents as RTMP carried over a secure connection. Use the RTMPS address shown for your stream when available and confirm that your installed FFmpeg build supports the protocol. The URL format and stream key belong together as the output destination; do not share a real URL containing a live key in support requests or examples.
The following is an illustrative starting shape, not a tested universal command. Replace the placeholders, check installed encoder and protocol support, and adapt the input mappings and rates to your source and YouTube’s current table.
ffmpeg -re -i /path/to/gameplay-vod.mp4 \\
-map 0:v:0 -map 0:a:0 \\
-c:v libx264 -preset veryfast -pix_fmt yuv420p \\
-b:v REPLACE_WITH_YOUTUBE_RECOMMENDED_VIDEO_BITRATE \\
-maxrate REPLACE_WITH_YOUTUBE_RECOMMENDED_VIDEO_BITRATE \\
-bufsize REPLACE_WITH_APPROPRIATE_RATE_CONTROL_BUFFER \\
-r REPLACE_WITH_FRAME_RATE -g REPLACE_WITH_KEYFRAME_INTERVAL_IN_FRAMES \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv 'rtmps://REPLACE_WITH_YOUTUBE_INGEST_URL/REPLACE_WITH_STREAM_KEY'
The command selects the first video and first audio stream, encodes video using libx264, and sends an FLV output over the RTMPS-compatible RTMP protocol path. The AAC audio settings shown are example settings, not a substitute for checking the channel’s requirements and source. If the file has multiple audio tracks, an alternate audio stream, or no audio, change the -map options instead of assuming the first track is right. If the source codec is already suitable, stream-copying may reduce CPU use, but only do so after checking that the resulting codec and stream format meet YouTube’s current requirements.
Keep the key out of the command text where possible. For a one-off test, a shell variable or protected configuration can reduce accidental copying, but do not mistake a variable for secure storage if other users can inspect the process or environment. For a persistent job, ensure the service configuration is readable only by the account that needs it and keep secrets out of diagnostic logs.
If the VPS is only being used because you do not want a personal computer left on to send an uploaded file, StreamNeo removes the work of maintaining this FFmpeg process by turning the uploaded video into a YouTube live stream. It is YouTube-only, so it is not a fit if you need to publish the same output to another platform or need to control a custom encoding pipeline directly.
Pace and encode the file for real-time output
The -re option tells FFmpeg to read a file at its native rate, which is useful when a file is being sent as a live stream. Without real-time pacing, a local file can be read and transmitted much faster than its intended playback duration, subject to encoder and network conditions. The output should advance in step with the programme rather than racing through the file.
Set output resolution and frame rate based on the source and what the VPS can encode and transmit consistently. A 60 fps output is not automatically preferable if the source is 30 fps, the VPS cannot encode it steadily, or the network cannot sustain the corresponding bitrate. Upscaling a lower-resolution VOD does not create detail. If the source is 1080p30, for example, a 1080p30 mode may be a more sensible starting point than converting it to a higher frame rate without a reason.
For H.264 output, use YouTube’s current bitrate recommendation for the selected resolution and frame rate as a reference, then verify that the VPS has enough sustained outbound capacity. Configure -b:v and -maxrate in keeping with the chosen rate-control approach; select a suitable buffer size for that rate rather than copying an unrelated value. The sample leaves the buffer as a placeholder because a buffer value should be chosen with the encoder behaviour and target mode in mind.
YouTube recommends a two-second keyframe interval and says not to exceed four seconds. FFmpeg’s -g sets a GOP length in frames for the selected frame rate. At 30 fps, a two-second interval corresponds to 60 frames; use the matching calculation for a different fixed frame rate. That is an interval conversion, not a separate bitrate recommendation. Check your output’s actual frame rate and GOP behaviour rather than assuming that setting -g alone resolves every encoder configuration issue.
The software encoder and preset are a practical trade-off. If CPU is close to saturation, a faster preset, a lower resolution or frame rate, or a more capable VPS may be needed. If CPU remains comfortable but the network is constrained, reducing the target bitrate or choosing a lower output mode may be more useful. Avoid selecting arbitrary settings on the assumption that a VPS can encode any mode: capacity varies by server allocation and the workload, and the command should be tested under the chosen conditions.
For temporary output failures, FFmpeg’s official documentation shows a FIFO muxer example with recovery attempts for RTMP output. Such options can help with some transient failures, but they do not guarantee a seamless YouTube broadcast, and availability depends on the FFmpeg build and configuration. Check the documentation shipped with the installed version and test recovery privately before relying on it. Restart behaviour, stream state in YouTube, and event configuration can all affect what viewers see after a disconnect.
Check preview and stream health
Start FFmpeg and open the stream’s Live Control Room page. Wait for YouTube to receive the feed and show a preview before starting the event if the stream is not set to auto-start. Check the picture, audio, and timing. A successful FFmpeg process alone does not confirm that YouTube is receiving a usable feed or that the event has been started for viewers.
Read the stream health messages in the control room. YouTube’s Live Streaming API documentation describes health issues that can include low bitrate, missing audio or video, a long keyframe interval, or an unsupported codec. These clues point to different fixes: compare actual output bitrate with the chosen mode, inspect audio mapping, verify encoder support, and confirm the keyframe interval.
Watch FFmpeg’s own output as well. Look for a growing delay between the input timestamp and output progress, repeated connection failures, or resource use that leaves no headroom for the process. A process that stays alive while encoding falls behind may still produce a poor live experience. Compare the preview and health information in YouTube with the local logs; each shows a different part of the path.
If you need a troubleshooting sequence when YouTube marks the feed yellow or red, use the stream health fixes guide. It is useful after the first checks, not a substitute for verifying the source file, command mapping, and current encoder settings.
A prerecorded gaming VOD generally does not need the lowest possible viewer latency because viewers are not interacting with a live player in real time. YouTube explains that lower latency can reduce delivery delay but may increase buffering or affect smoothness. Normal latency is a reasonable starting choice for a one-way VOD stream; choose a lower-latency mode only when the broadcast has a reason to prioritise interaction, and check the trade-off in your own viewing conditions.
End the event and understand archiving
When the VOD reaches its end, do not assume that closing a terminal is the complete event procedure. End the broadcast in YouTube Studio, then stop FFmpeg if it is still running. Confirm the event has ended in Live Control Room and check the channel’s video list later for the recording. If the encoder stops first, YouTube’s event state and settings determine what viewers see; finish from Studio and verify the result.
YouTube says streams under 12 hours are automatically archived. Do not rely on that statement for a stream longer than 12 hours; the guidance here does not establish automatic archive behaviour for longer broadcasts. If the recording matters, keep the original VOD and make an independent copy of the source before streaming. The YouTube guidance on keeping a 24/7 devotional stream running past 12 hours addresses a different continuous-channel problem, but its duration warning is relevant when planning an event that approaches that threshold.
For a single gaming file, decide what should happen at the end before going live. A one-time event can end when the VOD finishes. A looping channel needs a deliberate repeat and restart plan, plus a way to detect that playback or publishing has stopped. Those are separate operational requirements from encoding one file correctly.
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 send a gaming VOD from a Linux VPS without encoding it again?
Possibly, if the source’s codecs, pixel format, frame rate, bitrate, and container handling suit the YouTube ingest requirements and your FFmpeg build can publish them as required. Check the source and the current YouTube table first; stream-copying saves encoding work but does not fix incompatible settings.
What bitrate should I use for 1080p gaming footage?
Use the current YouTube recommendation for your selected codec and frame rate, rather than a value copied from a different mode. YouTube’s current H.264 recommendations include 14 Mbps for 1080p30 and 17 Mbps for 1080p60; your network and VPS must still sustain the chosen output.
Does -re make a stream continuous if the VPS disconnects?
No. -re paces file reading at the source rate; it is not a network recovery or uptime guarantee. FFmpeg documents recovery options for some RTMP output failures, but test them with your build and verify how the YouTube event behaves after a drop.
Will YouTube archive a long gaming stream automatically?
YouTube says live streams under 12 hours are automatically archived. Do not assume the same for streams longer than that based on this guidance, and keep your original file if you need a dependable copy.