A prerecorded YouTube live stream sends a video file to YouTube as an encoder broadcast: viewers encounter a live event, even though the pictures and sound were recorded earlier. Docker supplies a repeatable place to run FFmpeg; it does not make the broadcast continuous or remove the need to monitor the event.
You need a channel able to go live, permission to broadcast the media, a file that FFmpeg can read, and the stream URL and key from YouTube Live Control Room. This guide uses a one-pass feed as its baseline, then explains the checks, trade-offs and handover points that matter in practice.
Before you start: channel access and broadcast rights
Confirm that you can open YouTube Studio for the channel and that live streaming is enabled. YouTube Help says first-time live-stream enablement may take up to 24 hours, so do not schedule a launch on the assumption that a newly enabled channel will be ready immediately. Check the current YouTube encoder setup guidance for the steps and account requirements; platform instructions can change.
The account needs permission to create or manage the broadcast. If you are setting this up for a devotional channel, shop, school or community organisation, agree who controls the YouTube account, who can create events, and who is authorised to start and end them. Keep the number of people with access to the stream key small. Someone who has it can send a feed to the event.
Also confirm that the channel has permission to broadcast every part of the file: video, music, photographs, spoken material and any third-party content. A licence for a song in an offline video does not necessarily grant the right to broadcast it on YouTube. YouTube’s copyright and live-stream policies are the relevant starting points; check the current official rules for your circumstances rather than treating this technical guide as rights advice.
A prerecorded file is still transmitted as a live event. That affects how viewers find and experience it, but it does not make the material automatically eligible for monetisation. Review YouTube’s current monetisation policies and the terms applying to your channel; do not assume that a file loop or encoder feed qualifies simply because it is live.
Create or schedule the encoder stream in YouTube Studio
In YouTube Studio, open Create → Go live. Create a new stream or use Manage to schedule an event. Choose its title, description, audience setting, privacy and start time deliberately. Scheduling the event lets you prepare its page and metadata before the encoder sends video. It does not start the file feed for you.
In the stream settings, choose the encoder workflow and copy the ingest URL and stream key shown for that event. Prefer the RTMPS URL offered in Live Control Room when your FFmpeg build supports it. RTMPS encrypts the connection between the sender and YouTube; the key remains a credential even when the transport is encrypted. Do not substitute an endpoint remembered from an old tutorial: use the URL shown for the current stream.
The exact form of the destination can vary with the encoder instructions. In the template below, the URL and key are joined with a slash, but confirm the arrangement shown in your own Live Control Room. If YouTube supplies a complete destination rather than separate fields, adapt the command accordingly and avoid adding the key twice.
If you have not used YouTube’s stream settings before, its current live encoder settings are the authority for supported codecs, frame rates, keyframes and bitrate recommendations. Use those settings as guidance, not a promise that a particular encoding will be accepted in every circumstance. The applicable bitrate depends on resolution, frame rate and codec.
Keep the stream key private
Treat the stream key like a password for sending video to a specific live event. Do not paste it into a public issue, a screenshot, a chat, a shared document, a Dockerfile or a command that you later publish. Do not commit a file containing it to version control. A Dockerfile ENV instruction is especially unsuitable: Docker documents that ENV values persist in the image created from that Dockerfile.
Pass the key when the container runs, using a secret facility provided by your deployment environment or a protected runtime configuration with access restricted to the people who need it. The example uses environment variables for clarity; that is not a claim that every environment protects them in the same way. Inspect your hosting or orchestration documentation, and consider whether its logs, process inspection tools or deployment history could expose the value. Avoid enabling shell tracing or printing the assembled destination.
The same caution applies to the stream URL if it contains the key. Keep the credentials out of image layers and source control, and do not paste a full FFmpeg command containing them into support requests. If the key is exposed, replace or reset it in Live Control Room and update the runtime configuration before sending again. The ingest URL troubleshooting guide is useful when separating an endpoint mistake from other connection failures.
Prepare Docker and the media file
Choose an FFmpeg container image suitable for your system and pin it to a specific version or immutable image reference that you have checked. A floating tag can change between runs, which makes it harder to explain why a previously working command behaves differently. Confirm that the chosen build includes the required input demuxers, output muxer and RTMPS protocol support. The command below is a template, not a verified invocation for every image; some images do not provide a shell or use a different entry point.
Place the authorised media file where Docker can access it. The example mounts one file read-only at /media/video.mp4, which avoids baking media into the image and makes the input path explicit. On Windows or a hosted deployment, adjust the source path and mount syntax for that environment. Check file permissions from inside the container as well as on the host: a file visible in your terminal may not be readable by the container process.
Before sending, inspect the input. Confirm that it plays from beginning to end, has the intended audio track, and has a sensible aspect ratio and duration for the event. Use FFmpeg’s inspection tools, such as ffprobe, to identify its video and audio codecs and dimensions. A file ending normally is different from a file with a damaged final segment or no audio stream.
The media’s existing codec and container determine whether stream copy is feasible. Copying avoids decoding and re-encoding, so it can save processing, but it only works when the streams and output muxing are compatible with the ingest requirements. If they are not, re-encode the audio and video to supported formats. Re-encoding uses more compute and requires you to choose output settings that match YouTube’s current recommendations. There is no universal bitrate to paste into every command.
Pace FFmpeg and send the file in real time
A file can be read faster than its playback duration unless the input is rate-limited. FFmpeg’s -re option reads at the input’s native frame rate. Put it before the corresponding -i input; it is an input option, and its position matters. Without pacing, FFmpeg can process a file much faster than real time, which is not the intended behaviour for a live file feed.
Here is a one-pass template. Replace the image placeholder with a pinned image you have verified, and provide the two environment variables using protected runtime configuration. Confirm the URL/key arrangement and the image’s command interface before using it:
docker run --rm \
--mount type=bind,src="$PWD/video.mp4",dst=/media/video.mp4,readonly \
--env YOUTUBE_RTMPS_URL \
--env YOUTUBE_STREAM_KEY \
YOUR_PINNED_FFMPEG_IMAGE \
sh -c 'ffmpeg -re -i /media/video.mp4 -c:v copy -c:a copy -f flv "$YOUTUBE_RTMPS_URL/$YOUTUBE_STREAM_KEY"'
This demonstrates the flow, not a guarantee that stream copy will suit your file. The container needs a shell for this exact form, and the selected FFmpeg build must support the protocol and output format. If copy fails or YouTube rejects the media, inspect the streams and use an explicit re-encoding command with supported video and audio codecs. Keep the endpoint out of logs when diagnosing errors.
YouTube’s current encoder settings list H.264, H.265/HEVC and AV1 for RTMP/RTMPS, support frame rates up to 60 fps, and recommend constant bitrate with a keyframe interval of two seconds (not exceeding four seconds). Audio recommendations include AAC or MP3, with 5.1 audio over RTMP/RTMPS supported only for AAC. These are platform recommendations; consult the live settings table before choosing your output. For example, its 1080p30 row gives different bitrate recommendations for H.264 and for AV1/H.265. That is why a single figure should not be treated as universal.
If you need to transcode, set the output encoder, bitrate and keyframe interval explicitly, using current YouTube guidance for the selected resolution, frame rate and codec. Then test with a short private or unlisted event before relying on the setup for a public scheduled stream. If your channel’s stream needs a steadier upload path, compare the practical bandwidth guidance in this YouTube Live upload-speed guide and the bitrate settings guide. The source file’s bitrate is not by itself a substitute for checking the actual outgoing feed.
Start the feed and verify the incoming preview
Start the container with the intended event selected in Studio, then watch Live Control Room for an incoming preview and stream health. A running Docker process only tells you that a process is running; it does not prove that YouTube is receiving a usable picture and sound. Check that the preview shows the expected opening frames, that audio is present, and that the event metadata and privacy are correct.
For a scheduled event, sending the feed is not necessarily the same as making the event public. Wait for the preview and check the status in Live Control Room. When ready, use Go live there. If you intend the stream to remain private or unlisted, verify that setting rather than assuming that starting FFmpeg determines who can watch.
Keep an eye on the sender and the Control Room during the handover. A container can exit because the file ended, an error occurred, the host stopped, or the network failed. Docker does not prevent any of those conditions. If an unattended broadcast matters, decide who will notice a failure and what they should check before starting the sender again. A plan for monitoring and recovery is more useful than assuming the container will run uninterrupted.
When the event is finished, end it in Live Control Room and stop the container. For a finite input, reaching end-of-file is expected: FFmpeg finishes and exits. That is appropriate for a single scheduled programme, but not for a channel that needs continuous content. For a playlist or repeated feed, explicitly design and test the transitions; the guide to removing dead air between replay files covers one practical part of that job. Do not assume a loop is enabled by the template above.
YouTube Help states, “All streams under 12 hours will be automatically archived.” Treat that as current platform guidance, not as a substitute for ending the event cleanly or checking the archived result. Review the current encoder setup page for any limits or changes before planning a long broadcast.
Choose the runtime that fits the job
Docker is useful when you want FFmpeg and its dependencies packaged in a repeatable runtime. It can make a command easier to move between compatible hosts, but it does not remove the need to keep the host, network connection and event settings in working order. A prebuilt image is quicker to start with; building and maintaining your own image gives you more control over the FFmpeg build and dependencies, but adds update and testing work.
| Choice | What it helps with | What you still need to manage |
|---|---|---|
| Stream copy | Less processing when the input streams are compatible | Whether the codecs, container and ingest settings work together |
| Re-encoding | Control over output codec, size and keyframes | CPU capacity, output settings and a test before the event |
| Existing computer | Reuses equipment you already have | Power, sleep settings, network stability and local monitoring |
| Hosted machine | Can run away from your desk | Host access, deployment secrets, billing and a way to detect failure |
For a one-off programme, a computer you can monitor may be simpler than arranging a remote host. For an unattended schedule, a hosted machine may suit your operating needs, but you must still monitor the sender and protect the credentials. There is no capture card requirement when the input is already a media file and FFmpeg is sending it; a capture card serves a different workflow where the source is live hardware video.
If the operational burden is chiefly keeping a file-based channel going without leaving your own computer on, StreamNeo removes that specific task by taking an uploaded video and running it as a YouTube live stream with monitoring and automatic restarts if the feed drops. It is YouTube-only, so it is not a fit if you need a different platform or require direct control of a Docker/FFmpeg workflow. Whichever route you use, confirm that the content, channel settings and event are ready before relying on it.
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 Docker make a prerecorded broadcast uninterrupted?
No. Docker runs the process in a container, but it cannot guarantee that the host stays on, the network remains available, or YouTube accepts the feed. Watch the incoming preview and stream health, and decide how you will notice and respond if the sender exits.
Why does FFmpeg stop when the video finishes?
The template sends one finite input, so FFmpeg exits when it reaches the end of that file. That is normal for a one-pass event. A continuous channel needs an explicitly designed playlist or repeat workflow, with transitions and recovery tested rather than assumed.
What should I do if Live Control Room shows no preview?
Check that you copied the current ingest URL and key for the selected event, that the FFmpeg build supports RTMPS, and that the host can reach the network. Then inspect FFmpeg’s output and the stream health information in Control Room without sharing the key in logs or messages.
Does prerecorded content qualify for monetisation because it is live?
Not automatically. A file sent as an encoder feed is presented as a live event, but monetisation eligibility depends on YouTube’s current policies and the channel’s circumstances. Check the official rules rather than inferring eligibility from the broadcast method.