A running FFmpeg process only shows that the process has not exited; it does not prove that MediaMTX has an active publisher on the expected path, that MediaMTX is forwarding to YouTube, or that YouTube has accepted the stream. Check each link in that order before changing settings.
The most easily missed media requirement is that YouTube needs both an audio track and a video track. MediaMTX documents that video-only streams are silently rejected, so a command can keep running while the destination still reports offline.
Why a running FFmpeg process is not enough
Think of the route as a chain of separate hand-offs: FFmpeg publishes to a destination, MediaMTX receives that publication on a path, MediaMTX may forward that path to YouTube, and YouTube processes the incoming stream. A process listing, terminal window, or service status describes only the first item: whether FFmpeg is still running. It cannot establish what happened at the later boundaries.
There are two common arrangements. FFmpeg may publish to MediaMTX, which then forwards the path to YouTube. Or FFmpeg may publish directly to YouTube, without MediaMTX acting as an intermediate receiver. The right checks depend on which arrangement the command actually uses. If FFmpeg is publishing directly to YouTube, inspecting MediaMTX for a publisher will not explain that route. If it is publishing to MediaMTX, the direct YouTube destination and key belong in MediaMTX’s forwarding configuration, not necessarily in FFmpeg’s command.
Start by writing down the intended route in one line, for example: FFmpeg → MediaMTX path mystream → YouTube. Then match each arrow to evidence: FFmpeg’s final output URL, MediaMTX’s path and publisher logs, the forwarding destination and key, and YouTube’s Live Control Room status. Do not treat a successful earlier hand-off as proof of the next one.
This distinction is useful when a VPS, a local computer, or an always-on channel has been running unchanged for hours. The process can remain alive while publishing to the wrong path, receiving an upstream input that lacks a track, or failing to connect onward. For background on the other parts of a hosted FFmpeg setup, see this guide to moving a 24/7 FFmpeg stream to a VPS.
Check FFmpeg’s destination and path
Read the whole FFmpeg command, especially the final output URL and the output format option immediately before it. MediaMTX’s FFmpeg publishing guide shows an RTMP example that ends with -f flv rtmp://localhost:1935/mystream. In that example, localhost is the MediaMTX host as seen by the publishing process, and mystream is the path. Your host, protocol, port, and path may differ, but the same question applies: where is this output actually being sent?
If FFmpeg and MediaMTX run on different machines or in separate container environments, localhost can point to the wrong place. Confirm the address from the point of view of the FFmpeg process. Also compare the path in the output URL with the path you expect MediaMTX to receive. A difference as small as publishing to /live while checking /mystream can make the intended path appear idle even though FFmpeg continues to run.
Check whether the command targets MediaMTX or YouTube directly. An output URL containing a YouTube ingest address and stream key is not evidence that MediaMTX is in the route. Conversely, if the output URL points to a MediaMTX address, the command itself does not show that MediaMTX has been configured to forward the received stream to YouTube.
Avoid changing several command options at once. First record the current destination and path; then compare those with the MediaMTX configuration and logs. If the command’s input file or loop is also in doubt, diagnose that separately from the destination. The article on video files OBS cannot open covers a different application, but the underlying discipline is useful: establish that the source media is readable before attributing a downstream symptom to it.
Confirm MediaMTX has an active publisher
If FFmpeg is meant to publish into MediaMTX, look for evidence that MediaMTX received that publication on the expected path. The process running on the sender is not such evidence. Use the MediaMTX logs and whatever path status is available in your deployment to find publisher connection, path activity, disconnect, and error events around the time you attempted to start the stream.
MediaMTX supports several log levels and destinations. If the existing output does not show enough detail, consult the configuration reference for the version you have installed and temporarily increase logLevel to debug. Check where logs are sent as well: stdout, a file, and syslog will not necessarily appear in the same place. Restore a less verbose setting after diagnosis if debug output is no longer needed.
A useful log review follows the timeline rather than searching only for the word “error”. Find the time FFmpeg started, then check whether MediaMTX loaded the expected configuration, saw a client publish to the intended path, and later recorded any disconnect or forwarding attempt. If there is no publisher event on that path, the problem is earlier than YouTube forwarding: revisit FFmpeg’s destination, protocol, path, and reachability to the MediaMTX host.
If MediaMTX reports a publisher on the path, that narrows the boundary but does not prove YouTube received anything. It establishes that MediaMTX saw an input; forwarding and YouTube acceptance still need separate checks. Do not infer successful forwarding from an active path alone.
After editing the configuration, use MediaMTX’s documented --validate-conf option to check whether the file is valid before restarting or applying the change. Validation can catch configuration problems, but it cannot confirm that an account-specific key is current or that YouTube accepts the media. Keep a copy of the prior working configuration so you can reverse a change that makes the route less clear.
Verify the forwarding URL and stream key
When MediaMTX is responsible for sending the path onward, inspect the forwarding destination attached to that path. The MediaMTX forwarding guide demonstrates a destination that combines the ingest URL and stream key with #. Treat its example as a format illustration, not as an account-specific destination. The guide notes that its sample YouTube hostname reflects what YouTube reported when the guide was last updated.
Use the ingest address and key currently shown for your channel in YouTube Live Control Room. YouTube’s streaming settings help explains how to copy the stream key into an encoder. A generic example cannot tell you which key belongs to your channel, whether you selected the intended stream, or whether the address presented in your account has changed.
Check the pieces carefully: the scheme, host, path, separator, and key. A stale hostname, an omitted or misplaced separator, a typo in the key, or a key for another stream can prevent the forwarding connection from reaching the intended ingest. Do not paste a secret key into a public support request or screenshot. If you share a configuration for help, redact the key while leaving enough of the URL structure visible to discuss it.
The MediaMTX guide recommends using the rtmps:// scheme to encrypt the connection in transit. Whether you adopt that setting, make sure the complete URL is one that YouTube currently provides and that the forwarding configuration is attached to the same MediaMTX path receiving FFmpeg’s publication. A correctly copied key under the wrong path still does not make the expected path forward.
Keep the two configuration roles separate in your notes: the FFmpeg URL tells you where the source publishes; the MediaMTX destination tells you where the received path is forwarded. If FFmpeg publishes directly to YouTube, use its output destination and key as the relevant credentials check instead, and do not assume an unused MediaMTX forwarding rule is involved.
Check for both audio and video tracks
Once the route and forwarding destination appear consistent, confirm the outgoing stream contains both media tracks. MediaMTX’s forwarding documentation states: “YouTube requires streams to have both a video and an audio track. Video-only streams are silently rejected.” This requirement makes a stream with a moving picture but no audio a plausible reason for YouTube to remain offline, even when an upstream process has not stopped.
Inspect the media that reaches the forwarding stage, not only the source file’s properties or the FFmpeg command’s appearance. The source may contain audio while the output selection omits it; a filter or mapping may also leave one track out. Check FFmpeg’s mapping and output information and, where possible, examine the stream at the point MediaMTX receives it. The goal is to establish that audio and video both survive the path into the outgoing publication.
For a silent devotional visual, a lofi loop, a study animation, or an ambience scene, silence in the room does not mean the encoded stream should lack an audio track. If the content is intentionally silent, the technical question remains whether the outgoing stream carries an audio track. Do not assume YouTube will accept a video-only stream simply because the picture is valid.
If the input is a video file, check for an audio stream and confirm the output command maps it as intended. If it has no audio, you will need to produce an output with both required tracks rather than repeatedly changing the stream key. If audio is present at the source and output mapping, but YouTube still shows offline, continue to inspect MediaMTX’s forwarding logs and Live Control Room rather than treating track presence as proof of acceptance.
Inspect connection errors and Live Control Room state
Read the logs at the point where MediaMTX attempts to forward, and correlate them with the publisher events. A connection failure, rejection, or timeout tells you which boundary to investigate, but it does not by itself identify the cause. The supplied configuration, network, and account details matter; without them, it would be guesswork to name a particular DNS, firewall, TLS, routing, or account fault.
For a timeout, first recheck the destination and key against the current values in Live Control Room. Then investigate whether the MediaMTX host can reach that destination. YouTube Help advises checking the encoder documentation when a connection times out. That is a reason to check the sender’s documentation and network path, not evidence of one specific blocked port or network defect.
Compare the MediaMTX timeline with the stream state in Live Control Room. Look for whether YouTube reports an incoming signal, any current stream-health message, and whether the intended stream is selected. A difference between MediaMTX’s forwarding attempt and the Control Room’s view can help locate the failing hand-off, but neither a local process status nor a configuration file proves that YouTube has accepted the stream.
Change one thing at a time and note the result: destination and path, publisher activity, forwarding credentials, tracks, then connectivity. This makes it possible to tell whether a new result followed a specific correction. If the logs remain unclear, preserve the relevant time window and redact credentials before asking for help. Include the FFmpeg output URL with secrets removed, the path name, the forwarding error text, and the Control Room status; those details are more useful than saying only that FFmpeg is running.
A separate issue can arise when YouTube’s stream itself is scheduled or selected incorrectly. The guide to scheduling a 24/7 stream in YouTube Studio can help you check the channel-side setup, but scheduling does not replace verifying the ingest route and both media tracks.
Choose the next check by the failing boundary
Use the evidence you have to decide what to inspect next, rather than changing all settings at once. The table is a routing aid: it does not diagnose the exact failure without your command, configuration, logs, and Control Room state.
| Evidence you can see | Boundary to check next | Useful detail to collect |
|---|---|---|
| FFmpeg runs, but no publisher appears on the expected MediaMTX path | FFmpeg to MediaMTX | Final output URL, protocol, host as seen by FFmpeg, and path |
| MediaMTX reports a publisher, but no forwarding attempt is visible | Path configuration to forwarding | The active path’s forward destination and relevant configuration load events |
| Forwarding is attempted, but YouTube remains offline | MediaMTX to YouTube | Current ingest address and key, redacted log message, and track presence |
| Logs show a timeout | Connection from the MediaMTX host | Destination as configured, timing, and reachability evidence from that host |
| The outgoing stream has video but no audio | Media tracks | Source tracks, output mapping, and what reaches the forwarding stage |
| Control Room reports a signal or health message, but the channel view differs | YouTube-side stream selection or state | Selected stream and the exact current message shown in Live Control Room |
If the host is distant from your audience, that may matter for the overall streaming setup, but it is not a substitute for finding the broken link in this route. See how much internet speed a live stream needs for planning bandwidth. For this offline symptom, start with the logs and path state: they distinguish a missing input from a failed forwarding connection more directly than changing network plans or encoder quality.
If you do not want a computer you control to remain responsible for keeping a file-based broadcast running, StreamNeo removes that specific operational burden by taking an uploaded video and running it as a YouTube live stream with your computer switched off. That is a separate operating choice, not a fix for a MediaMTX configuration or YouTube account problem; this diagnosis still applies if you are troubleshooting the MediaMTX route.
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
Why does FFmpeg say it is running while YouTube says offline?
The process can remain alive without publishing to the expected MediaMTX path, and an active MediaMTX publisher does not prove that forwarding succeeded. Check the final FFmpeg URL first, then path activity, forwarding logs, credentials, tracks, and the state shown in Live Control Room.
Does MediaMTX forward to YouTube automatically when it receives a stream?
Do not assume so. In a setup where MediaMTX forwards to YouTube, confirm that the intended path has the forwarding destination configured and that the logs show an attempt. If FFmpeg publishes directly to YouTube, MediaMTX may not be part of that route at all.
Can YouTube accept a video-only stream from MediaMTX?
MediaMTX’s forwarding documentation says YouTube requires both an audio and a video track and silently rejects video-only streams. Check what reaches the outgoing stream, not just whether the source file contains audio.
What should I share when asking for troubleshooting help?
Share the redacted FFmpeg output URL, the MediaMTX path name, relevant publisher and forwarding log lines with their times, and the exact Live Control Room message. Remove the stream key and any other credentials before posting.