A good Docker setup for a 4K 60fps FFmpeg YouTube Live playlist depends on your host, source files, filters, upload connection and recovery needs. There is no Compose file that is best for every machine: decide first whether CPU encoding can sustain your workflow, whether GPU access is supported on your host, and how the playlist should behave at file boundaries and after an interruption.
Treat the container as one part of the broadcast system. FFmpeg reads and processes media, produces the chosen output, and sends it to YouTube; Docker packages that process and helps manage its lifecycle. The design below is a starting point to test against your own files and host, not a promise of gapless looping or uninterrupted recovery.
Define what “continuous” means for your channel
A playlist can be continuous in more than one sense. You may mean that FFmpeg stays connected to YouTube while changing files, that every item plays in a defined order, or that the last item transitions to the first without a visible or audible break. Those are different requirements, and a simple repeat option does not by itself establish that transitions will be seamless.
Write down the expected behaviour before building the container. Should the playlist repeat forever, play new files in a schedule, or stop at a particular time? If an input file is missing or damaged, should the process skip it, stop for attention, or continue with a fallback? After an internet outage, do you expect the same FFmpeg process to reconnect, a supervisor to restart it, or an operator to intervene?
Also decide whether viewers need a persistent YouTube live event or whether a new broadcast after a failure is acceptable. YouTube ingest, stream health and the viewer-facing event are related but not identical. Test the behaviour in YouTube Studio rather than inferring it from a container's “running” status.
For timed programming, keep scheduling separate from the mechanics of encoding. A channel that must introduce a new episode at a particular hour has a different playout problem from one that repeats a fixed ambience video. The scheduling questions in this guide to playing a new podcast episode at a set time are useful even if your content is not a podcast.
Inventory the host, media and connection
Start with the host operating system, CPU, memory, storage, GPU model if present, driver situation and Docker runtime. Record whether the machine is physical or virtual and whether Docker runs natively or through another layer. GPU access varies across these arrangements, so do not assume that a device visible on the host will also be usable inside the container.
Inspect the media before choosing an encoder. Note each file's resolution, frame rate, video and audio codecs, number of streams, colour characteristics and duration. A library made from consistent 2160p60 SDR files is simpler to playout than a mixture of frame rates, HDR and SDR, stereo and multichannel audio, or portrait and landscape clips. Mixed inputs may need scaling, frame-rate conversion, colour handling, audio resampling or stream selection. Every such filter changes the workload and can affect output quality.
Decide where the playlist and configuration live. A read-only media mount reduces the chance that the playout process alters source files; a separate writable location can hold logs or temporary files if the workflow needs them. Keep the stream key out of a public Compose file and out of the image. Use an environment file or a secret mechanism appropriate to the host, and restrict access to it.
The upload connection matters continuously, not just when a speed test looks good. YouTube's published 4K/2160p60 recommendations are 50 Mbps for H.264 and 35 Mbps for AV1 or H.265; the corresponding listed minimums are 14 Mbps and 10 Mbps. These are YouTube's current encoder settings, accessed 3 October 2026, not a guarantee that a particular line can sustain a stream. Allow headroom above the selected video bitrate plus audio, and assess stability over time, including busy periods on shared connections.
If H.264 is your chosen output, a practical first check is whether the connection can hold a stable upload around the published recommendation plus audio, rather than merely touching the minimum. If it cannot, consider whether another supported codec and compatible encoder are appropriate, or whether 4K60 is not a sensible target for that host and connection. Do not lower quality settings blindly: first identify whether the limit is network, encoding, filtering or source media.
Choose the encoder around the workload
CPU software encoding is the simpler baseline where the host can sustain the selected output format with the filters you need. It avoids GPU passthrough configuration and can be easier to move between machines. Its trade-off is that encoding and filtering consume CPU capacity continuously; a brief successful test does not show that the host will remain within capacity over a long session or under other workloads.
GPU hardware encoding can reduce CPU load, but adds dependencies: a compatible GPU, working host drivers, a container runtime path for the device, and an FFmpeg build with the relevant encoder. NVIDIA's FFmpeg integration documentation describes encoders including h264_nvenc, hevc_nvenc and av1_nvenc; that does not mean every NVIDIA GPU, driver combination or container image supports every option. No hardware threshold can be inferred without testing the actual workload.
Codec choice is a joint decision, not simply “pick the highest number” or “use whatever the GPU exposes”. YouTube's current guidance lists H.264, H.265 and AV1 for live encoder settings and publishes different 4K60 recommended rates by codec. Check that the codec is currently supported for your intended ingest path, the FFmpeg build has an encoder, and your hardware can encode it. For SDR, YouTube specifies Rec. 709; HDR has distinct guidance, so do not apply SDR assumptions to an HDR playlist.
| Decision | Favour this when | Check before committing |
|---|---|---|
| CPU software encode | Portability and simpler device access matter, and the host has sustained capacity | Test the complete filter chain at the target frame size and rate, not just a short encode without filters |
| GPU hardware encode | CPU load is the constraint and the host/runtime/encoder combination is supported | Verify device access inside the container, encoder availability, sustained output and visual quality |
| H.264 output | Compatibility with a well-understood workflow is the priority | YouTube's current 4K60 recommended video rate is 50 Mbps, accessed 3 October 2026; check actual upload headroom |
| H.265 or AV1 output | The full ingest and encode path supports the codec and its bitrate target suits the connection | YouTube's current 4K60 recommendation for either is 35 Mbps, accessed 3 October 2026; confirm hardware and FFmpeg support |
For another view of codec and bitrate decisions, see this NVIDIA GPU playlist bitrate guide. It is still necessary to test your own files and filters: a bitrate recommendation is not a substitute for measuring sustained encode performance and checking the picture.
Plan Docker device access deliberately
For a CPU-only service, keep the container definition as portable as practical: a pinned or otherwise controlled FFmpeg image, a read-only media mount, a configuration mount if needed, and an explicit restart policy chosen for your operating practice. A restart policy can restart a stopped container under its documented conditions; it cannot determine whether the content is correct, whether YouTube accepts the stream, or whether a process that remains alive is making useful progress.
If you use an NVIDIA GPU, install and validate the host-side driver and NVIDIA Container Toolkit according to the relevant official documentation before changing Compose. Docker Compose's device reservation syntax requires the gpu capability. Use either a device count or device_ids, not both. The exact supported syntax and prerequisites depend on Docker and the host setup, so validate on the deployment machine rather than treating a snippet as universal.
A starting shape for the GPU reservation is shown below. It only describes a device request; it is not a complete service and does not install drivers, provide an NVENC-enabled FFmpeg binary, mount your media, or configure YouTube ingest.
services:
playout:
image: your-tested-ffmpeg-image
restart: unless-stopped
volumes:
- ./media:/media:ro
- ./config:/config:ro
deploy:
resources:
reservations:
devices:
- capabilities: [gpu]
If the host needs a specific GPU, add a suitable device_ids selection instead of count; do not put both fields in the same reservation. Then check what the container can actually see and what the FFmpeg binary can use. Docker's Compose GPU support guide and Docker Engine GPU access documentation describe the reservation and runtime requirements. NVIDIA's FFmpeg integration guide covers its encoder integration.
On a different GPU vendor or host platform, the setup and supported acceleration path may differ. If exposing hardware makes the deployment fragile or unportable, a CPU-only container may be a better operational decision even if it requires a more capable host. Keep a known-good CPU workflow or recovery plan only if you have tested it; a fallback that cannot sustain the stream is not a fallback in practice.
Build a playout workflow you can inspect
Keep the responsibilities clear: decide the order of files, prepare consistent inputs or filters, encode one output format, then deliver it to YouTube. FFmpeg can read, filter and convert media, and its protocol documentation covers RTMPS, but command-line options depend on the build. Before writing a long command, inspect the actual binary inside the image with ffmpeg -version, ffmpeg -protocols and the relevant encoder help output. Confirm the intended codec and RTMPS are present.
For a simple, fixed-format playlist, -stream_loop -1 may be worth testing as part of an input workflow, but do not treat it as a guarantee of gapless transitions. File boundaries can expose differences in timestamps, frame rate, codecs, stream layout or duration. A playlist file, a shell loop that launches FFmpeg repeatedly, and one long FFmpeg process each have different implications for continuity and failure handling. Choose only after testing the precise files and command you intend to use.
Where possible, normalise the library before broadcast. Matching frame size, frame rate, colour treatment, audio sample format and channel layout reduces surprises at transitions. This can be a pre-processing step outside the live container, or deliberate filtering during playout. Pre-processing uses storage and takes preparation time; live filters add work to the continuous encode path. Keep a sample of the hardest files in the test playlist, not only the easiest clip.
A starting command should be specific to a stated assumption set: for example, local SDR files with compatible streams, a selected encoder, a known output bitrate and a tested FFmpeg build. Map the intended audio and video streams explicitly when input layouts vary. Set output frame rate, video codec, bitrate control and keyframe behaviour to match YouTube's current guidance. Keep the key in a secret or environment mechanism rather than placing it in a command that will be committed, logged or shared. RTMPS is YouTube's recommended secure ingest option.
A 24/7 channel also has editorial and archive consequences beyond encoding. If background audio is part of a recorded programme, check how it is mixed and what viewers will hear at file boundaries; the background music workflow for a recorded lecture stream raises those practical considerations. If the channel is a radio-style loop, consider archive duration and whether repeating long files is useful to viewers, rather than assuming technical repetition is the whole programming plan.
Validate YouTube ingest and stream health
YouTube's current live encoder guidance, accessed 3 October 2026, says to use constant bitrate (CBR), recommends a two-second keyframe interval and says not to exceed four seconds. It supports RTMP/RTMPS and recommends RTMPS. For 4K60, its published video bitrate recommendations are codec-specific: 50 Mbps for H.264 and 35 Mbps for H.265 or AV1. Use the current YouTube encoder settings and bitrate table as the authority when configuring a live encoder, and re-check it before a real deployment.
Do not equate successful connection with healthy output. Observe YouTube Studio's stream health indicators alongside the FFmpeg logs, CPU/GPU load, dropped or delayed frames, network behaviour and audio. A process can be running while frames are late, the wrong stream is mapped, or the output format does not match the plan. Check both the incoming stream and what a viewer sees, including audio and colour.
Test at the intended resolution, frame rate, codec, bitrate and filters for a meaningful period before relying on the channel overnight. A short launch can establish that the stream key, protocol and basic output work; it cannot show that the host stays cool, the connection remains stable, or a full playlist reaches its end and repeats correctly. YouTube's displayed status and your own process logs answer different questions, so review both.
RTMPS protects the connection in transit to YouTube's ingest, but it does not protect a stream key stored carelessly on the host. Limit who can read configuration and logs, avoid printing secrets, and rotate the key if it has been exposed. YouTube's Live Streaming API documentation is useful for understanding the platform's live resource model if you are building automation around event or stream management; it does not replace testing the encoder path.
Test looping and recovery as separate failures
Run test cases that reflect the channel's real risks. Let one file reach its end, transition to the next, and then reach the end of the list. Include files with the longest duration, highest decode complexity, unusual audio layout, and any format differences that your normalisation process is meant to handle. Listen across transitions, inspect picture and sound, and review timestamps or logs where available. A clean-looking loop in one pair of files does not prove every file boundary will behave the same way.
Then test failures independently. Stop FFmpeg while leaving Docker up; stop the container; interrupt the network; and, if GPU encoding is used, test what happens when the device or encoder is unavailable at startup. Record whether the container restarts, whether the process returns, whether YouTube continues to show the intended event, and whether an operator receives enough information to diagnose the issue. A Docker restart policy is not a complete recovery design, and reconnect behaviour depends on the exact FFmpeg command, protocol and ingest state.
Use logs that help answer a question: when did the process stop, what input was being read, was the encoder reporting errors, and did the output resume? Monitor both the container and the stream rather than alerting only on a process exit. Decide who is expected to respond during unattended hours, and keep a documented manual recovery procedure. The aim is to know which failure mode is covered and which still needs a person.
If your main operational concern is resuming after an internet interruption, compare the distinct retry and supervision choices in this OBS reconnection guide. Its software differs, but the planning lesson carries over: define retry behaviour, observe whether the stream has actually returned, and test the interruption rather than relying on a setting name.
For some channels, managing a local Docker host and its night-time recovery is more burden than the playlist warrants. StreamNeo removes the specific burden of keeping your own computer on for the broadcast: you upload a video, provide your YouTube stream key, and the cloud-run stream can be monitored and restarted if it drops. It is YouTube-only, and it does not decide whether your media, rights, ingest settings or channel plan are suitable; those remain your responsibility.
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
Is a GPU required for 4K60 FFmpeg streaming?
No. GPU encoding is optional, but CPU encoding must be tested with the actual files, filters and output settings. A GPU only helps if the host, drivers, container runtime and FFmpeg build all support the selected encoder.
Can I use one Compose file on any Docker host?
No. CPU-only services are generally simpler to move, while GPU access depends on host operating system, device support, drivers and runtime configuration. Treat examples as starting points and validate the exact Compose and FFmpeg setup where the channel will run.
Does -stream_loop -1 guarantee a seamless playlist?
No. It can repeat input, but it does not guarantee that file boundaries are visually or audibly seamless, or that every playlist format behaves as expected. Test the exact media sequence and consider normalising files before broadcast.
Will Docker automatically recover a YouTube stream after an outage?
A restart policy can help restart a stopped container, but it does not guarantee that FFmpeg reconnects correctly or that YouTube's event returns as intended. Test process exits and network interruptions separately, monitor both container and stream health, and define an operator recovery path.