A MediaMTX and FFmpeg setup has two separate legs: FFmpeg loops a file into a MediaMTX path, then MediaMTX forwards that path to YouTube Live. The local publish address is not YouTube’s ingest server, and the loop command alone does not guarantee uninterrupted operation.
This guide maps both legs, shows the documented publishing patterns, and identifies what you still need to verify and supervise. The exact forwarding configuration can depend on your MediaMTX version, so use its current documentation alongside the account-specific YouTube URL and key.
Understand the two-stage architecture
Think of the workflow as source file → FFmpeg → MediaMTX path → YouTube Live. FFmpeg reads the file and publishes its audio and video to a named path on MediaMTX. MediaMTX then reads that path and sends it onwards to the YouTube endpoint configured for forwarding.
These stages solve different problems. The FFmpeg command controls how the file is read and how it enters MediaMTX. MediaMTX’s path configuration controls where that stream goes next. If YouTube is not receiving video, a working FFmpeg-to-MediaMTX connection only proves that the first leg is working; it does not confirm that the second leg is configured or accepted.
MediaMTX describes itself as a live media server and proxy that can publish, read, proxy, record and play back real-time media. Its documentation includes FFmpeg as a publishing option. For a broader sense of how creator tools differ, see this guide to live-streaming apps for YouTube; here, the focus is the route between one local file and one MediaMTX path.
Draw the two boundaries before changing settings:
| Stage | Sender and destination | What to check |
|---|---|---|
| Local publishing | FFmpeg sends to a MediaMTX path such as mystream |
MediaMTX is reachable on the chosen protocol and path; FFmpeg can read the file and its tracks |
| YouTube forwarding | MediaMTX forwards that path to the account’s current YouTube ingest URL and key | Forwarding is configured for the same path; the endpoint and key are current; YouTube receives acceptable audio and video |
The examples below use local addresses for the first stage only. localhost is appropriate only when FFmpeg and MediaMTX run on the same machine or in an environment where that address reaches MediaMTX. If they are on separate hosts or in separate containers, use a reachable address and check the deployment’s network and port configuration. The published RTSP path is an internal hand-off, not a YouTube destination.
Get the current YouTube URL and key
In YouTube Studio, open the live-stream settings for the target broadcast and retrieve the current stream URL and stream key. YouTube’s RTMPS guidance describes how to reveal the RTMPS URL in the stream settings. Use what the account currently shows rather than assuming that an endpoint copied from an older tutorial still applies.
MediaMTX’s forwarding page includes rtmps://a.rtmp.youtube.com/live2 as an example, but warns that the URL was the one YouTube reported when that documentation was last updated. Treat it as a format illustration, not an instruction to hard-code that host. The forwarding documentation puts a # between the destination URL and the stream key. Its example is a configuration pattern, not a real key to reuse.
A stream key gives access to the broadcast destination, so do not paste a real one into a public issue, screenshot, shared configuration example or source-control repository. Take care with terminal history and logs too: shell commands and configuration files may be retained or shared in ways you did not intend. If a key is exposed, use the controls in YouTube Studio to manage it, then update the forwarding configuration that relies on it.
YouTube recommends RTMPS, a secure extension of RTMP, in its live encoder settings. That is guidance for the outbound connection to YouTube. It does not mean that the local FFmpeg-to-MediaMTX publishing leg needs to use RTMPS; the two legs have their own protocols and destinations.
Loop a source file with FFmpeg
MediaMTX’s FFmpeg publishing guide demonstrates real-time playback of a file with looping and stream copy. Its RTSP example is:
ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f rtsp rtsp://localhost:8554/mystream
-re reads the input at its normal playback rate rather than pushing the file as quickly as possible. -stream_loop -1 repeats the input indefinitely. -i file.mp4 names the source file; -c copy passes the existing encoded audio and video streams through without re-encoding; -f rtsp selects the output format; and the final address publishes to the mystream path on the local MediaMTX instance.
Those flags do not repair a source. Stream copy does not create audio when the file has no audio track, convert an unsupported codec, or establish that YouTube will accept the file’s characteristics. Before running the loop unattended, inspect the input’s audio and video streams and decide whether its codecs, frame size and frame rate suit the intended broadcast. If the source needs new audio or transcoding, the simple copy example is not sufficient; choose and validate an appropriate FFmpeg command separately.
MediaMTX also documents an RTMP/FLV alternative:
ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f flv rtmp://localhost:1935/mystream
The project calls RTSP its recommended FFmpeg publishing method, while also documenting RTMP. The guide does not give a general performance comparison between them. Use the method supported by your deployment and existing network, and prefer the one whose connection and logs you can diagnose. Do not change both protocol and path at once when troubleshooting; isolating one variable makes a failed first leg easier to identify.
For a longer source-preparation workflow, this guide to joining multiple videos into one file for a YouTube live stream covers a related question. A combined file still needs compatible tracks and must be checked as an input; joining clips does not itself verify the stream that reaches YouTube.
Publish to a MediaMTX path
The final part of the FFmpeg command selects a MediaMTX publishing address and a path name. In the RTSP example, rtsp://localhost:8554/mystream means “publish to the mystream path at the RTSP listener on this host.” The RTMP alternative targets the RTMP listener and uses the same path name. The path is the connection point that MediaMTX can use for the next stage.
Keep that path name consistent. If FFmpeg publishes to mystream, the forwarding rule needs to refer to mystream; a different path name will not automatically select the stream you intended. Likewise, a path that is reachable from FFmpeg is not necessarily reachable from outside your machine, and it is not the destination YouTube expects. Avoid putting the YouTube key into the local publishing URL: the documented design puts it in the forwarding destination instead.
Before adding forwarding, confirm that MediaMTX is running with the publishing protocol you chose and that FFmpeg reports a successful publish rather than an input-file, connection or codec error. Check the server’s current configuration reference for the version you have installed: configuration fields and defaults can change. MediaMTX’s introduction and FFmpeg publishing guide explain the project’s role and the documented example commands.
A useful diagnostic question is: “Can MediaMTX see the path that FFmpeg is publishing?” Answer that before asking whether YouTube can see the broadcast. A local viewer or MediaMTX’s own available path/status tools may help you establish the first leg, but the exact verification method depends on your installation. Do not infer successful forwarding merely because the local path exists.
Configure MediaMTX forwarding
MediaMTX’s YouTube forwarding documentation shows a path configuration with a forwarding destination. The destination combines the current YouTube URL and key, separated by #. In schematic form, the relevant value resembles rtmps://CURRENT_YOUTUBE_URL#YOUR_STREAM_KEY; use the actual endpoint and key from the account, and follow the configuration syntax for your MediaMTX version. Do not treat this schematic string as a complete configuration file.
The configuration must associate forwarding with the same path FFmpeg publishes. This is the crucial hand-off: the local stage fills the path, and the forwarding rule sends that path to YouTube. The local address rtsp://localhost:8554/mystream belongs in the FFmpeg publishing command. It must not be substituted for the YouTube ingest endpoint, nor should a YouTube endpoint be mistaken for the local MediaMTX listener.
The retrieved project documentation shows the forwarding destination format and cautions that its sample URL may be out of date. It does not, by itself, supply a full end-to-end deployment recipe for every version, nor a complete supervisor, reconnection policy, storage policy or failure recovery design. Use the project’s current forwarding reference for the precise field names and path syntax supported by your version. Confirm the configuration loads and inspect MediaMTX’s logs for the outbound connection result.
Keep the key out of examples you intend to share. If you manage configuration through source control, use a process appropriate to your environment for keeping credentials out of committed files; do not assume the documented forwarding syntax provides secret storage. Also consider who can read the configuration and logs on the host. These are operational precautions, not a claim that a particular MediaMTX version includes a key-management feature.
Verify audio and video at YouTube
YouTube requires both an audio and a video track for this forwarding use case; MediaMTX warns that a video-only stream may be silently rejected. Check the actual source tracks before relying on -c copy, then verify the broadcast preview in YouTube Studio. Seeing an active local path is not enough: check that YouTube receives both moving video and audible programme audio.
For compatible output settings, consult YouTube’s current encoder guidance for the resolution and frame rate you intend to send. It lists supported streaming protocols and codecs, recommends a two-second keyframe interval, and says not to exceed four seconds. Its bitrate recommendations vary by output resolution and frame rate, so do not copy one bitrate into every configuration. The same guidance includes audio recommendations; check the current page for the setup you are targeting rather than treating an old setting as universal.
If YouTube does not show the stream, work through the path in order. First, check that FFmpeg can open and loop the file. Next, confirm it can publish to the configured MediaMTX listener and path. Then inspect MediaMTX’s outbound forwarding status and logs, confirm the current account endpoint and key, and finally check the YouTube preview and stream-health information. This sequence helps distinguish a local publishing problem from a forwarding or platform-acceptance problem.
For an invalid-key problem, use a focused checklist rather than repeatedly changing the FFmpeg command: confirm the key belongs to the target live setup, that it has not been replaced, and that the forwarding destination uses the current account URL and key in the documented format. The invalid stream key troubleshooting guide is about direct FFmpeg-to-YouTube publishing, so apply its account-side checks carefully; this article’s outbound sender is MediaMTX, not FFmpeg.
Plan supervision and recovery separately
A loop flag controls how FFmpeg reads a file. It does not monitor whether FFmpeg stays alive, whether MediaMTX remains available, whether the network to YouTube is interrupted, or whether an outbound session reconnects in the way your deployment needs. The documented examples do not provide a complete 24/7 process-supervision and recovery design. “24/7” describes the intended operating pattern, not a guarantee supplied by these commands.
Plan what should happen if either stage stops. Decide how you will notice an FFmpeg process exit, a MediaMTX failure, a lost network route or a rejected YouTube session. Decide who will receive an alert, how logs will be reviewed, and how the stages will be restarted in the correct order. Test recovery deliberately in a controlled window before depending on the channel overnight; do not assume that a successful first connection proves later recovery behaviour.
Also decide where the source file lives and how you will know it remains readable. A path that works in an interactive shell may not work under a separate service account or after a restart. Check file permissions, available storage and the host’s power and network arrangements as part of your own deployment planning. The sources here do not establish a particular storage policy, supervisor, restart mechanism or outage-handling method, so choose and test these for the environment you actually run.
If you are comparing a self-managed chain with a workflow where you upload a video and do not keep your own computer running, StreamNeo removes the specific burden of keeping the local FFmpeg process and MediaMTX path running on your machine. That is a different operating model, not a substitute for understanding the file, YouTube destination and channel requirements.
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 localhost:8554 YouTube’s streaming address?
No. In the example it is the local RTSP listener for MediaMTX, and mystream is the path being published there. YouTube’s current ingest URL and key belong in the separate MediaMTX-to-YouTube forwarding configuration.
Should I use RTSP or RTMP to publish into MediaMTX?
MediaMTX documents both and describes RTSP as its recommended FFmpeg publishing method. The documentation does not provide a universal performance comparison, so choose based on what your installation supports and what you can troubleshoot reliably.
Will the loop command keep my channel live if a process or connection fails?
Not necessarily. -stream_loop -1 repeats the file while FFmpeg is running, but the example does not provide a complete process supervisor or recovery design for failures in FFmpeg, MediaMTX, the network or the YouTube connection. Plan and test those behaviours separately.
Can I use a video-only file with stream copy?
The cited example does not add audio, and MediaMTX warns that YouTube requires both audio and video and may silently reject video-only input. Check the source tracks and choose a suitable way to supply audio before relying on the stream.