A MediaMTX-to-YouTube stream can show video while carrying no usable audio. Trace the sound from its source through FFmpeg and MediaMTX to YouTube, checking each boundary before changing settings.
The missing track may never reach FFmpeg, may be omitted by stream selection, may not suit the output, or may disappear on the path to YouTube. Without your logs and configuration, no single cause can be assumed; the aim is to find the earliest point where audio is absent or rejected.
Start with the source, not the output command
First establish that the intended source actually contains audio. Listen to the camera, file, player, or other input locally, and confirm that the sound you expect is present at the point where the encoder receives it. A video preview alone does not establish that an audio track exists.
For a file, inspect its streams with a media probe or FFmpeg’s diagnostic output. Check whether an audio stream is listed, and note its codec and channel layout. A file might contain several tracks, such as commentary and programme audio, or none at all. For a live input, confirm that the correct microphone, mixer output, desktop audio, or other source is routed into the capture or encoding process. Do not assume a device is active because it is selected in a menu.
YouTube’s live-stream troubleshooting guidance recommends checking how the stream sounds in the encoder, the audio and video sources routed to it, encoder errors, CPU load and a local archive when quality is wrong. These checks help distinguish capture failure from a problem farther downstream. If the encoder’s own monitor or recording is silent, troubleshoot that source and routing before editing MediaMTX settings.
A useful boundary test is to save a short local recording from the same input and inspect or play it. If the recording has no sound, the fault is upstream of YouTube. If it has sound but the outgoing preview is silent, investigate what the encoder selects and emits. This is a diagnostic comparison, not proof that the two paths use identical settings: a local recording can use a different output profile from the live stream.
For a scheduled programme that alternates recordings, verify the actual file used at the time of the silence, not only a sample from the playlist. A loop can advance to a file with no audio, a different audio track, or a channel layout your later process handles differently. The same practical distinction matters when you loop a playlist of language lessons on YouTube Live: test the specific media and transition that is silent.
Check what FFmpeg discovers and selects
Once audio is confirmed at the input, check FFmpeg’s input and output stream selection. FFmpeg can read a file or stream that contains audio and still produce an output with no audio if the command maps only video, selects the wrong input, or omits the desired track. A visible picture is not evidence that an audio stream was selected.
Read the diagnostic output from the actual process. Identify each input and the streams FFmpeg reports for it, then compare those with the output stream list. Look for an audio stream in the selected output, and confirm that it originates from the intended input. If you use multiple inputs, indices belong to the command’s input order; the number that identifies a camera or audio source in one command may refer to something else in another.
Mapping and stream copy are separate decisions. Mapping tells FFmpeg which streams to include; copy tells it whether to pass an existing stream through without re-encoding. A command that copies streams cannot create an audio track absent from the selected input, and copying an unsuitable codec does not make it suitable for a destination. Conversely, a re-encode can change the codec but will not repair a silent capture or a mapping that excludes audio.
MediaMTX documents FFmpeg as a publishing client and shows a general RTMP-to-local-path example: ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f flv rtmp://localhost:1935/mystream. This is a command shape for publishing a file to a local MediaMTX server, not a universal camera relay or a ready-to-use YouTube command. Your inputs, stream mapping, path, output format and destination must match your setup. Do not paste a guessed mapping or destination into a live configuration.
If FFmpeg reports audio at the input but not the output, focus on selection and output options. If both show audio, move to codec and transport checks. Keep a copy of the full command and relevant startup diagnostics, redacting stream keys and credentials before sharing them. The MediaMTX FFmpeg publishing documentation describes its publishing patterns; it does not establish which streams your individual command selects.
Match the output audio to YouTube
An audio stream can be present and still be unsuitable for the destination. For YouTube over RTMP or RTMPS, YouTube’s encoder settings list AAC or MP3 audio. For stereo, YouTube recommends a 44.1 kHz sample rate and 128 Kbps audio bitrate. Its guidance supports 5.1 audio only with AAC over RTMP/RTMPS, with different recommended settings. Check the current official page when configuring a new encoder, because published requirements can change.
These are destination settings, not a diagnosis by themselves. First verify that FFmpeg’s outgoing stream is actually audio, then inspect the codec, sample rate, channel layout and bitrate it reports. If it is already AAC or MP3 in a supported arrangement, changing the codec may not address a missing track caused by source routing or mapping. If the output is a different codec, or the channel arrangement is not accepted, configure an appropriate audio encode rather than assuming stream copy will work.
YouTube also expects one audio stream for this ingest path. Multiple audio tracks can be as problematic as none, even if one track is audible in a local player. The Live Control Room error guidance distinguishes a missing audio stream from multiple audio streams and points to supported audio settings. Check the output track count, not just whether any audio codec appears in the log.
A practical comparison is to ask what each proposed change affects. Re-mapping addresses selection; transcoding addresses format; choosing a different input addresses capture. Do not change all three at once. If the result becomes audible, simultaneous changes leave you without a clear explanation of what fixed it and can create a new failure elsewhere.
Check the MediaMTX path and transport
Treat MediaMTX as a separate boundary in the chain. Confirm that FFmpeg publishes to the listener and path you intend, that the process remains connected, and that the path’s reported tracks include audio. A configured path name or a successful video view does not prove that an audio track arrived on that path.
MediaMTX’s RTMP documentation lists support for audio codecs including AAC and MP3. That describes protocol capability; it does not confirm that a particular publisher sent those tracks or that your live path carried them correctly. Compare runtime logs and stream inspection with the FFmpeg output rather than treating a supported-codec list as evidence of a healthy stream.
Check both legs if your design has an input publisher and a separate process reading from MediaMTX to publish to YouTube. Verify that the first process publishes to the expected path, then that the second process reads that same path and selects its audio. A path mismatch can leave the reader consuming a different stream than the one you tested. Keep the origin and output legs distinct in your notes so a failure on one is not mistaken for the other.
Transport errors, reconnects or an unexpected protocol conversion may complicate the picture. Inspect the process logs around the time audio disappears, alongside MediaMTX’s runtime messages. Look for connection changes and track announcements, but do not infer a definite cause from one line without the surrounding configuration. If a continuous stream drops and later returns, the recovery sequence in how to recover a pre-recorded YouTube Live stream after a power cut is relevant to the broader restart problem, while this diagnosis still needs to establish where the audio track went.
A 2023 MediaMTX maintainer discussion describes an RTSP source read by FFmpeg and published onward to YouTube over RTMP, with the outgoing leg treated as FFmpeg’s responsibility. That is useful topology context, not a current recipe for your endpoints. Use the current project documentation and your own logs to verify each leg rather than copying historical settings.
Read YouTube’s ingest status
After confirming that audio is present in the outgoing encoder stream, check YouTube Live Control Room. Its health or error messages can indicate that the ingestion stream contains no audio or contains multiple audio streams. These messages tell you what YouTube sees at ingest; they do not necessarily identify whether the track was absent at source, dropped before MediaMTX, or omitted by the final FFmpeg output.
If YouTube reports no audio, compare that message with a local monitor or recording of the encoder output at the same time. If your local output is also silent or has no audio stream, return to source selection, mapping and encoding. If the outgoing stream demonstrably contains one supported audio stream while YouTube reports none, check the connection and the exact destination ingest session, then inspect the outbound network health as YouTube recommends.
If YouTube reports multiple audio streams, inspect the output mapping and ensure the ingest output contains only the intended track. A file with more than one audio stream can be passed through with all tracks unless the command selects deliberately. A local player may choose one track automatically, masking the fact that the ingest output contains several.
Do not treat an ingest preview as a substitute for examining the encoder output. The preview and dashboard health messages are valuable evidence of what reaches YouTube, but they describe the receiving end. Combine them with FFmpeg and MediaMTX observations to locate the earliest broken boundary. For related video-side checks, fixing a YouTube stream that buffers after switching OBS output from CBR to VBR covers a different symptom; buffering and silence should not be collapsed into one diagnosis.
Compare audio across the pipeline
Make a short evidence table before changing the setup. Record what you can observe at the source, FFmpeg input, FFmpeg output, MediaMTX path and YouTube ingest. The first point that changes from “present” to “absent” narrows the work. If a boundary is unknown, mark it unknown rather than filling the gap with an assumption.
| Checkpoint | Evidence to collect | What a missing or unexpected result points towards |
|---|---|---|
| Source | Local listen or recording; input’s listed tracks | Capture, routing, or the selected media file |
| FFmpeg input | Discovered streams and input order | Wrong input, unavailable source, or no source audio |
| FFmpeg output | Selected tracks, codec and audio properties | Mapping, output configuration, or format suitability |
| MediaMTX path | Runtime track presence and connection messages | Path mismatch, publishing leg, or transport |
| YouTube ingest | Live Control Room health and audio errors | Destination-facing output, ingest session, or connectivity |
The table is not a substitute for the underlying logs. For example, a source recording with sound does not prove the live FFmpeg output includes that sound, and MediaMTX supporting AAC does not prove your path carries AAC. Use evidence from the same session and time window where possible; comparing yesterday’s local sample with tonight’s silent ingest can conceal a changing input or configuration.
When audio is present at a checkpoint, note more than “yes”. Record which track it is, whether it is one track or several, and its relevant format. That avoids a false pass where the stream has audio, but it is the wrong programme track or an output YouTube cannot use. Keep credentials out of any shared log excerpts, particularly RTMP destinations containing stream keys.
For a file-based channel where the recurring burden is keeping a prepared programme online while your own computer is off, StreamNeo can remove the need to keep a local playback machine running; it does not diagnose an existing MediaMTX chain or change YouTube’s audio requirements. Resolve and validate the actual audio in the uploaded file before relying on any different playback route.
Retest with logs and a known source
Once you have located the earliest uncertain or failing stage, change one thing and retest. Use a known source file that you have confirmed plays audio, and use the same source throughout the test. If a simple test file succeeds while the usual programme does not, compare their tracks and formats instead of changing the entire MediaMTX configuration.
Capture the relevant FFmpeg startup and output diagnostics, MediaMTX runtime messages, and YouTube’s ingest status for the same test window. Note the time of any reconnect or silence, and whether audio disappeared immediately or after a path transition. A clean log excerpt should preserve stream indices and codec details while removing keys, passwords and private addresses.
Do not declare a fix merely because the preview produced sound once. Let the intended source run through the full path, then confirm the output still has the intended single audio track and YouTube continues to report a healthy ingest. For an always-on channel, observe a normal loop transition or source change as well; a track that survives startup may still be lost when the input changes.
If the evidence does not identify a boundary, avoid stacking speculative changes. Preserve the current configuration, document the command shape and path names, and compare each stage again during a controlled test. This gives you a useful question to take to support: not simply “there is no audio”, but “audio is present in this output and absent at this next checkpoint”.
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 YouTube show video but no audio?
Video can reach the ingest while audio is absent, unselected, or unsuitable. Check the source and FFmpeg’s output stream list first, then compare the MediaMTX path and YouTube’s health message to find where the track stops appearing.
Should I use -c copy for audio?
Only if the selected source track is suitable for the destination and the output keeps the intended track. Copying preserves the existing codec; it does not add missing audio or convert an unsupported format. Verify the output properties before choosing between copy and an audio encode.
MediaMTX supports AAC, so why is the stream still silent?
Protocol support means MediaMTX can handle that codec, not that your publisher sent an audio track or that your path contains it. Check runtime track presence and the FFmpeg output rather than relying on the supported-codec list alone.
What should I share when asking for help?
Share the relevant, redacted FFmpeg command and logs, MediaMTX path configuration and runtime messages, plus YouTube’s ingest status from the same test. Remove stream keys and credentials, and say at which checkpoint audio was last confirmed present.