To run MediaMTX and FFmpeg in Docker for an always-on YouTube channel, send your source or looping media to FFmpeg, publish that output to a MediaMTX path, then configure MediaMTX to forward the path to YouTube Live. Docker packages the processes, but it does not by itself keep every handoff, network connection or YouTube broadcast running.
The configuration below is an editorial synthesis of documented FFmpeg publishing examples and MediaMTX forwarding instructions, not a tested deployment. Treat the commands as a framework to adapt and verify in your environment, especially the listener address, YouTube ingest URL, stream key and certificate behaviour.
Understand the FFmpeg-to-MediaMTX-to-YouTube topology
Think of the setup as three separate transfers: source media enters FFmpeg, FFmpeg publishes to a named MediaMTX path, and MediaMTX forwards that path to YouTube Live ingest. Each transfer has its own address and its own failure modes. Keeping them separate makes it easier to tell whether a problem comes from the file, the Docker network, the relay configuration or YouTube.
FFmpeg reads and packages the source. For a prerecorded file, it can read at real-time pace and loop the input; for another source, it may capture or receive a feed instead. MediaMTX acts as the relay: it accepts the publication on a path such as channel, and its path configuration can send that stream onwards. YouTube is the final destination, where you check whether the broadcast is being received and whether its preview and status look right.
MediaMTX describes itself as a media server and proxy that can accept, serve, proxy and record real-time audio and video over several protocols. It can also serve an always-available stream when a publisher is offline. That is a capability of the relay, not a promise that YouTube will remain live during a failed source, stopped container, network interruption or account issue. See the MediaMTX overview for its documented role and supported workflows.
This arrangement is useful when you want the media publisher and the outbound forwarding rule to be distinct. It also adds a handoff compared with sending FFmpeg directly to YouTube: FFmpeg must reach MediaMTX, and MediaMTX must reach YouTube. If you do not need a relay path or another MediaMTX feature, a simpler direct FFmpeg-to-YouTube workflow may be easier to maintain. For a broader look at the source side, the guide to organising content for a 24/7 channel can help you plan what FFmpeg should play.
Prepare Docker services and configuration
Decide first whether FFmpeg and MediaMTX will run in separate containers or whether FFmpeg will run elsewhere. With separate containers on the same Docker network, localhost inside the FFmpeg container means that container itself, not MediaMTX. Use the MediaMTX service name and the listener port instead. If FFmpeg runs on the host, use an address and published port that the host can reach.
MediaMTX's Docker configuration guide shows using a host-side configuration file mounted into the container. This keeps the YAML editable and persistent if you replace the container. The official sample exposes several protocol listeners, including RTSP on port 8554 and RTMP on 1935; publish only the listener ports your chosen design needs, and do not expose administrative interfaces casually.
A small Compose outline might look like this. It deliberately leaves image selection and the exact configuration values for you to set and verify against the current documentation:
services:
mediamtx:
image: bluenviron/mediamtx:1
volumes:
- ./mediamtx.yml:/mediamtx.yml:ro
ports:
- "8554:8554"
Choose and record an intentional image tag before relying on the service. A moving or broad tag is not a record of the exact build that is running. Review release notes before upgrades, and keep a copy of the working configuration so you can compare changes. MediaMTX's configuration reference identifies the parameters available for a particular release; check the reference that matches your chosen image rather than assuming an example will remain unchanged.
You can maintain configuration in a mounted YAML file, use environment overrides, or use the Control API. The MediaMTX guide documents MTX_-prefixed environment variables for overrides, including underscores for nested values and numeric positions for list items. A file is usually easier to review as a complete path configuration; overrides can suit deployment-specific values, while the API may fit workflows that need programmatic changes. None removes the need to protect credentials.
Before starting, use MediaMTX's configuration validation option, --validate-conf, as documented in its configuration guide. It can catch syntax and configuration errors before the service begins accepting connections. It cannot confirm that FFmpeg can reach the listener or that YouTube accepts the forwarded stream, so regard it as one check in a longer sequence.
Publish source media from FFmpeg
MediaMTX documents FFmpeg publishing over several protocols and recommends RTSP for FFmpeg publication. Its looped-file example follows this pattern:
ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f rtsp rtsp://localhost:8554/mystream
Replace file.mp4 with the actual path available to FFmpeg, and replace localhost with the reachable MediaMTX address when the processes are in separate containers. In a shared Docker network, that is commonly the service name. The path at the end, here mystream, must match the path that MediaMTX is configured to forward.
The options have distinct jobs. -re asks FFmpeg to read the file at its natural playback pace rather than sending it as quickly as it can be processed. -stream_loop -1 repeats the input indefinitely. -c copy copies the existing audio and video streams rather than decoding and re-encoding them. Copying avoids a transcode step, but it is only suitable if the source streams are acceptable for the target workflow. Do not assume that because a file plays locally its codecs, tracks or container handling will be appropriate for a live ingest.
If your source needs different codecs or a valid audio track, configure FFmpeg accordingly and test the result before leaving it unattended. MediaMTX's example is a publishing pattern, not a universal encoding recipe. The separate FFmpeg live error troubleshooting guide is useful when YouTube reports a problem after the stream reaches its ingest stage.
RTMP is another documented publication choice, with a pattern using -f flv and an RTMP listener such as rtmp://mediamtx:1935/mystream. RTSP is MediaMTX's stated recommendation for FFmpeg publishing, but your choice still depends on the listeners enabled, the FFmpeg build and how Docker exposes the port. Neither protocol is a guaranteed latency or quality winner for every setup.
| Choice | What to check | Practical trade-off |
|---|---|---|
| RTSP publication | FFmpeg output support, MediaMTX listener, reachable path and port | The documented recommended FFmpeg publishing method in MediaMTX guidance; requires matching network addressing. |
| RTMP publication | FFmpeg FLV output, RTMP listener and path | Also documented, and may suit an existing RTMP workflow; verify the listener is enabled and reachable. |
| Stream copy | Source codecs and tracks | Avoids a transcode step, but does not adapt the source if it is unsuitable for the destination. |
| Transcoding | Encoder settings, machine capacity and output tracks | Can change the media format, but adds processing and configuration to operate and diagnose. |
Configure the MediaMTX path and forwarding
The name in the FFmpeg publishing URL is the path key MediaMTX uses to identify the incoming stream. Configure that same path to forward to YouTube. MediaMTX's forwarding guide shows configuring a destination for an incoming path, with the stream key separated from the URL by #.
Keep the shape of the configuration conceptually simple: define the mystream path, then set its forwarding destination to the currently displayed YouTube URL plus the private key. The precise YAML fields and indentation should come from the current MediaMTX reference and forwarding guide for your version. Do not paste a real key into an article, public repository, support screenshot or shared Compose file.
A YouTube stream key authorises publishing to the channel. Store it as a secret or in a private configuration mechanism appropriate to your host, restrict access to that file, and rotate the key in YouTube if you believe it has been exposed. Environment overrides can avoid committing a secret-bearing YAML file, but make sure they are not printed into logs or exposed through a broadly accessible process environment.
MediaMTX's forwarding example uses a YouTube RTMPS destination and notes that its endpoint was the one YouTube reported when that documentation was last updated. It also records a certificate issue and shows a fingerprint workaround that was valid at the time checked. Do not copy a remembered endpoint or fingerprint as though it were permanent. Use the current URL shown in YouTube Live and verify certificate behaviour before using any fingerprint setting; a fingerprint is not an interchangeable security decoration.
Connect to YouTube Live ingest
In YouTube Studio, open the Live control room for the broadcast and retrieve the current Stream URL and stream key. Enter those values into the MediaMTX forwarding configuration in the format required by its guide. Prefer RTMPS where YouTube provides it, because the encrypted transport protects the stream in transit. YouTube's live streaming help explains how to set up a live stream; follow the current interface because labels and ingest details can change.
Treat the YouTube destination as a separate configuration item from the incoming MediaMTX path. The RTSP or RTMP address FFmpeg uses points to MediaMTX, not YouTube. MediaMTX's forwarding destination points out to YouTube. Mixing these up can produce a healthy-looking publisher connection to the relay while YouTube receives nothing.
YouTube's ingest preview is an important verification point, but it does not establish that the whole system will run indefinitely. Confirm that the correct broadcast is selected, inspect its preview and status, and look for the expected audio and video. If there is no preview, work backwards: first confirm that YouTube has the right stream key and destination, then that MediaMTX has an active incoming path, and then that FFmpeg is publishing to the correct address.
MediaMTX's forwarding guidance states that YouTube requires both audio and video tracks; a video-only stream may be silently rejected. Confirm the source has both tracks, or configure FFmpeg to produce an appropriate audio track when that suits the programme. This is a track-presence requirement, not a requirement that you have audible music or speech at every moment. For a channel using quiet or silent visuals, the separate considerations in YouTube's silent-stream claims guide are relevant to content and rights, not a substitute for checking the ingest tracks.
Check audio, video, and each handoff
Verify the chain in order instead of changing several settings at once. First, open the media source locally or inspect it with your usual media tools. Confirm that the intended video and audio tracks exist, the file is readable and the loop has no unintended gap or abrupt ending. A file that fails locally will not be fixed by Docker or MediaMTX.
Next, start MediaMTX with the validated configuration and inspect its logs for startup errors. Then launch FFmpeg and confirm its output reports a successful connection to the intended listener and path. If it cannot connect, check the service name, port mapping, Docker network membership, listener setting and path spelling. If MediaMTX starts but the path remains empty, the break is between FFmpeg and the relay.
Once the path is active, look for forwarding activity in MediaMTX's logs, then check YouTube's Live control room preview and status. A successful FFmpeg connection only proves the first handoff. It does not prove MediaMTX can reach YouTube or that YouTube accepts the media. If the relay has an incoming publisher but there is no YouTube preview, revisit the destination URL, key, RTMPS and certificate behaviour, then confirm the stream includes both tracks.
Listen to the preview as well as looking at it. Check that audio is present at an appropriate level and that it is not distorted, missing or unexpectedly out of sync. Check that video is moving and that the intended frame is visible. If the video appears but audio does not, inspect the source track and FFmpeg stream mapping rather than treating the relay connection as proof of a complete programme.
For overnight operation, define what you will do when each process stops. A container restart policy can restart a stopped container, but it cannot repair a bad key, an unreadable file, a full disk, a broken network route or a YouTube-side interruption. FFmpeg itself can exit while MediaMTX remains up; the relay may still be healthy as a process while there is no programme source. Decide who will notice alerts, how logs will be checked and how recovery will be confirmed in YouTube, not just in Docker.
If the repeated work is keeping a host computer available and recovering the broadcast when it drops, StreamNeo removes that specific burden by letting you upload the video and run the YouTube broadcast with your computer switched off. That is a different operating approach from maintaining your own FFmpeg and MediaMTX containers, and it remains YouTube-only.
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 run FFmpeg and MediaMTX in separate Docker containers?
Yes, provided they can reach each other on a Docker network and MediaMTX listens on the selected protocol and port. Use the MediaMTX service name rather than localhost from the FFmpeg container, then confirm the incoming path appears in MediaMTX.
Does -stream_loop -1 guarantee the YouTube channel stays live?
No. It repeats FFmpeg's input while that FFmpeg process is running and the file remains available. It does not handle every container, network, account, forwarding or YouTube failure, so you still need checks and a recovery plan.
Should I use RTSP or RTMP to publish to MediaMTX?
MediaMTX recommends RTSP for FFmpeg publishing and also documents an RTMP example. Choose based on the listener you enable, your FFmpeg build and the network configuration, then test that specific handoff; do not assume one is universally better for latency or quality.
Where do I find the YouTube URL and stream key?
Retrieve the current Stream URL and key from YouTube Studio's Live control room for the broadcast. Treat the key as a credential, keep it private, and verify current RTMPS and certificate behaviour rather than relying on an old copied endpoint.