To publish an FFmpeg stream to YouTube through MediaMTX, treat it as two separate connections: FFmpeg sends audio and video to a MediaMTX path, then MediaMTX forwards that path to YouTube. Check each handoff on its own so you can tell whether a fault is at the source, the relay, or YouTube ingest.
The forwarded feed must contain both an audio track and a video track. MediaMTX warns that YouTube silently rejects video-only streams, so a moving picture without an audio stream is not a sound setup, even if the programme is meant to be silent.
Open the active YouTube stream settings
In YouTube Studio, open Create → Go Live and select the Stream tab for the live stream you intend to use. YouTube shows the ingest URL and stream key for that stream. Use the values shown there rather than copying a hostname or key from an old command or tutorial. The YouTube encoder setup guide describes entering the server URL and stream key in an encoder.
A stream key is a credential: it directs the encoder feed to the right live stream and allows YouTube to accept it. Keep it out of public configuration files, screenshots, chat messages, and examples you share. If you think it has been exposed, use YouTube Studio’s reset option and update the destination in MediaMTX. YouTube’s stream key help page explains the current controls.
Record the URL and key somewhere private while setting up, but do not treat them as permanent constants. A key may be changed or reset, and the ingest address in a documentation example may no longer be the right one for your stream. If you manage several channels or live events, label each private entry so you do not accidentally forward a test feed into the wrong active stream.
Before touching MediaMTX, confirm that the intended stream is open in Studio and that you are looking at its own stream settings. This is the first checkpoint: you should have the current destination URL and corresponding key, not merely a live stream title or a previously used key. Do not publish the actual key in a command copied into public notes.
Create or choose a MediaMTX path
A MediaMTX path is the named route at which a stream becomes available. Choose a clear name such as mystream or devotional; use the same path name in FFmpeg’s publish URL and in the matching MediaMTX configuration. The MediaMTX FFmpeg publishing guide shows the RTMP publishing pattern. Its forwarding guide explains how a path can then be sent on to another destination.
The path name is not your YouTube stream key. It is a local name on the MediaMTX side, so it can be simple and meaningful without revealing the YouTube credential. For example, if you configure a path called mystream, the FFmpeg output can target rtmp://localhost:1935/mystream when MediaMTX is listening on the same computer and the default RTMP port is in use. If MediaMTX is on another machine, replace localhost with the reachable host name or address and check that the RTMP listener is enabled and reachable from FFmpeg’s machine.
This is where deployment choices matter. A local relay is easier to inspect when you are learning because both processes can be checked on one machine, but it depends on that machine and network connection staying available. A remote relay may suit an always-on deployment, but then name resolution, routing, firewall rules, and remote configuration become additional places to check. MediaMTX’s introduction describes the application’s role; it does not make the network path between your FFmpeg process and the relay automatic.
Choose one path for the test and write it down. Avoid changing the path name, host, and YouTube destination all at once: a single deliberate change makes it easier to identify which handoff is failing. If your broader workflow starts from a pre-recorded video, the background in how to livestream pre-recorded videos on YouTube 24/7 can help distinguish the programme source from the relay steps here.
Publish FFmpeg media into the path
Once MediaMTX is listening and the path is available, point FFmpeg at that path using RTMP. A documented pattern is:
ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f flv rtmp://localhost:1935/mystream
This is an example, not a command guaranteed to work unchanged. Replace file.mp4 with your actual input and substitute the MediaMTX host and path you configured. Use -re when the input is a file that should be read at its native playback rate. The loop option repeats a file; omit or change it if you are testing a finite programme rather than a continuous loop.
The -c copy option passes through the input codecs instead of encoding them again. That can avoid unnecessary processing, but it only works when the source codecs and stream layout are suitable for the destination workflow. If the input is missing audio, copying cannot create an audio track. If the formats are unsuitable, FFmpeg may start but MediaMTX or YouTube may not accept the resulting stream as intended. For a more detailed discussion of encoder choices, see FFmpeg settings for a 24/7 YouTube stream at 1080p.
Do not infer success solely from FFmpeg reporting that it has started. The first handoff checkpoint is whether MediaMTX sees the named path become active and whether it reports incoming media tracks. If FFmpeg exits immediately, inspect its input path, permissions, codec errors, and output URL. If FFmpeg continues but MediaMTX has no publisher on the expected path, check the host, listener port, and exact path spelling before changing the YouTube configuration.
Configure forwarding to YouTube
After the FFmpeg leg reaches MediaMTX, configure the matching MediaMTX path to forward to YouTube. The destination is built from the current YouTube ingest URL and the stream key, following the pattern shown in MediaMTX documentation: rtmps://<current-youtube-ingest-host>/<path>#<stream-key>. In the MediaMTX paths entry for your chosen path, set its forward destination to that value.
Use the complete current URL shown in Studio, not a guessed host. MediaMTX’s example hostname is an example recorded when that documentation was updated; it should not be treated as a permanent YouTube endpoint. Preserve the RTMPS scheme when the current ingest destination supports it. RTMPS encrypts data in transit, which is important when the URL contains a credential. YouTube also recommends RTMPS in its current live encoder settings guidance.
Keep the key private in the MediaMTX configuration and restrict access to that file and to any logs that might contain its destination. Configuration syntax and reload behaviour can vary by MediaMTX version, so follow the documentation for the version you are running. If you edit the wrong path entry, FFmpeg can publish successfully while MediaMTX forwards a different path or nothing at all.
Avoid copying a historical certificate workaround from an example without checking the current endpoint and software version. The MediaMTX forwarding page includes a certificate note tied to its own check at the time it was written; that observation does not establish the current certificate behaviour of YouTube’s ingest endpoint. Investigate the present TLS error and verify the current documentation before changing certificate validation. Disabling verification blindly can remove a protection rather than fix the actual destination or trust problem.
Preserve audio and video tracks
Check the source file and the forwarded output for both tracks. MediaMTX’s forwarding guidance is explicit: YouTube requires both video and audio, and video-only streams are silently rejected. A silent visual loop still needs an audio stream in the feed. If the source has no audio, add a deliberate audio track appropriate to the programme before relying on the relay; do not assume a black or silent image is enough.
With stream copy, inspect the input first and verify it contains an audio stream as well as video. If the programme has audio but FFmpeg is not mapping it, adjust the stream selection or encoding workflow so that it reaches the output. Conversely, adding an audio stream to an FFmpeg command is not proof it survives the MediaMTX handoff: check that the relay sees it and that YouTube’s preview or health feedback recognises it.
The choice between copying and encoding is a trade-off. Copying avoids a re-encode, but preserves the source’s format and stream characteristics. Encoding gives you more control over codec, bitrate, frame rate, and keyframes, but requires suitable settings and enough processing capacity. YouTube’s encoder guidance lists RTMP/RTMPS transport, H.264, H.265, or AV1 video, AAC or MP3 audio, constant bitrate encoding, and a recommended two-second keyframe interval that should not exceed four seconds. Check that page for current guidance rather than assuming every input file is ready for ingest.
Resolution and frame rate also affect the upload demand. A higher-resolution or higher-frame-rate stream generally needs more bandwidth than a simpler one. Choose a mode supported by your source and sustainable on your actual upload connection, then run a representative test and watch YouTube’s stream health messages. If a phone recording is part of the source, removing variable frame rate from phone video before using OBS may be relevant to the source preparation, though it does not replace checking the MediaMTX legs.
Check the MediaMTX path and logs
Troubleshoot from left to right rather than changing the whole setup at once. First, confirm FFmpeg is reading the intended input and publishing to the intended host and path. Next, check MediaMTX’s logs or path status to see whether a publisher has connected and whether the path contains audio and video. Finally, inspect the forwarding destination and the connection from MediaMTX to YouTube.
If MediaMTX shows an incoming publisher but YouTube has no preview, the first leg is at least reaching the relay; that does not prove the second leg is configured correctly. Check that the forward setting belongs to the active path, that its RTMPS URL is the current one from Studio, and that its key belongs to the same active stream. A stale key, typo after the #, or mismatched path can break forwarding without requiring you to change the FFmpeg input command.
If there is no publisher on the path, focus on the FFmpeg output URL, MediaMTX listener, and network reachability. If MediaMTX reports a publisher and tracks but logs show forwarding or connection errors, focus on the destination URL, credentials, and current TLS behaviour. Treat logs as potentially sensitive: redact the key before sharing a log excerpt, and check whether the logging level or error message has included a credential-bearing URL.
If a key may have been exposed, reset it in YouTube Studio and update the forward destination rather than trying repeatedly with the old value. If the stream is reaching YouTube but quality is poor or unstable, do not assume the relay is the cause. Check the encoder settings and upload capacity, then use YouTube’s stream health feedback to separate bandwidth or encoding concerns from routing errors. The checklist in YouTube stream health warnings after changing resolution offers a related way to reason about quality feedback.
Verify the YouTube preview
When MediaMTX reports that it is forwarding the path, return to the active stream in YouTube Studio and check the preview and stream health status. YouTube recommends testing with representative picture and sound, not merely opening a connection. Use content like the actual programme: motion similar to the intended video and audio at the intended level. This helps reveal missing tracks, unstable upload, or encoding settings that a short static test may not expose.
There are three useful outcomes to distinguish. No preview or an ingest rejection suggests checking both tracks and the forwarding URL or key. A preview that appears but has warnings points towards a stream health or encoder issue that needs inspection. A clean preview for a brief test is evidence that the current route works at that moment, not a guarantee that a long-running channel will remain uninterrupted.
For an always-on channel, test the restart and recovery behaviour you actually need. A local FFmpeg process still depends on its host being on, the source being available, and the network connection remaining usable. If you are comparing a self-managed relay with a workflow that removes the need to keep your own computer running, StreamNeo can take away the recurring task of keeping an FFmpeg process open on a personal machine; it is a YouTube-only route for an uploaded video, not a MediaMTX relay or a substitute for checking the live preview and content rights.
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 FFmpeg send directly to YouTube instead of through MediaMTX?
Yes, direct publishing is a different workflow: FFmpeg sends to YouTube’s current ingest URL and key, with no MediaMTX forwarding leg. This guide is for the two-leg arrangement, where MediaMTX receives a path first and forwards it onward. Use the workflow that matches what you need to monitor and maintain.
Why is there no YouTube preview when FFmpeg is running?
An active FFmpeg process only indicates that it has started trying to publish. Confirm that MediaMTX sees the expected path and both media tracks, then check that the same path forwards to the current YouTube URL and active key. YouTube may silently reject video-only input.
Can I use RTMP for the FFmpeg-to-MediaMTX leg and RTMPS for forwarding?
The two legs have separate destinations, so the local publish leg can use MediaMTX’s RTMP listener while the onward destination uses the current YouTube RTMPS URL. The latter encrypts the connection carrying the stream key. Check listener and forwarding settings for your MediaMTX version.
What should I do if the YouTube stream key appears in a log or screenshot?
Treat it as exposed: reset it through YouTube Studio and replace it in the MediaMTX forward destination. Also remove or restrict access to copies of the credential where practical. Verify the updated destination against the active stream before testing again.