When an Nginx RTMP stream reaches YouTube with video but no sound, trace the audio track from the source through the encoder, relay and any FFmpeg processing to YouTube playback. The first point where the track is absent is the place to investigate; there is no single fix that applies to every pipeline.
Work downstream one hop at a time. Confirm audio locally, check what the encoder sends, inspect any relay or transcode, then use YouTube’s stream-health information and a separate playback check. Change one thing at a time and test again so you know which change mattered.
Trace the audio path, not just the picture
A live picture proves that some video reached the destination. It does not prove that audio was captured, packaged with the video, forwarded by Nginx, retained by FFmpeg, accepted by YouTube or audible in the player. Treat those as separate checkpoints rather than as one “stream is working” test.
Write down the path you actually use. A simple arrangement might be: music player or microphone → OBS → local RTMP application in Nginx → FFmpeg relay → YouTube. Another arrangement may send OBS directly to Nginx and have Nginx push the stream onward without a separate transcode. Do not assume a stage exists just because a common example includes it.
At each stage ask the same question: is there an audio stream, and does its level move when the source makes sound? Record the answer before changing settings. If the encoder output has no audio, a relay cannot restore what it never received. If a local relay has sound but YouTube’s preview does not, focus on the later stages instead of repeatedly changing the microphone.
| Checkpoint | What to establish | If audio is absent |
|---|---|---|
| Source and application | The intended device or media file produces sound locally | Check source selection, mute, permissions and channel routing |
| Encoder output | The outgoing stream contains a moving audio level or track | Check capture and encoder audio settings |
| Nginx/FFmpeg relay | The relay receives and forwards or encodes audio | Check the active application, command, mapping and logs |
| YouTube ingest | Live Control Room reports audio health or a specific issue | Follow the reported issue and verify the outgoing stream |
| Viewer playback | More than one player can hear the programme | Compare player settings and devices before changing ingest |
This order prevents a common diagnostic mistake: treating YouTube as the cause simply because the symptom appears there. A track can be lost before YouTube receives it, and a healthy ingest can still be followed by a muted or misconfigured player. The overview of common live-streaming encoding workflows can help you identify which component is encoding and which is only relaying.
Check the source device and application
Start with the thing that should make the sound. Play the source on the same computer or device and listen through a known output. If the programme is a playlist or recorded video, check that its own playback has sound. If it is a microphone, make a short test recording or use the application’s input meter. This distinguishes a silent source from a streaming problem without changing the live configuration.
Then inspect the application that captures or plays the source. Confirm that its selected input is the intended device, that the input is not muted, and that the meter responds when you speak or play audio. On a computer with several outputs or inputs, the default device can change after reconnecting a USB interface, headphones or other equipment. Verify the setting in the streaming application itself; an operating-system default is not proof that the application is listening to it.
For a media-file source, check the audio track selection and application mixer. A video file may contain more than one track, or an application may route desktop audio and microphone audio to separate mixer channels. If your encoder has separate tracks or a per-source mute, confirm that the track intended for the live output is enabled. Do not add a new microphone or buy equipment until a test shows that the existing source device is the fault.
Also check permissions. A desktop application may have lost permission to use a microphone after an operating-system update or a settings change. A meter that remains still while the microphone works in another application points towards capture selection or permission, not Nginx. If the source is supposed to be a music file, microphone permissions are irrelevant; follow the source that is actually meant to be on air.
For OBS users, recording separate sources can make routing easier to inspect, although a recording-track arrangement is not automatically the same as the live mix. The guide to recording separate audio tracks in OBS Studio is useful when you need to distinguish a microphone, desktop sound or other input. For this diagnosis, the key is to verify the mix that is sent to the stream, not merely that one source appears in a recording.
Inspect the encoder output audio
Once the source is audible and its application meter moves, check what the encoder is producing. Look for the streaming application’s output status, audio meter for the live mix, or a local monitoring copy of the encoded stream. The exact controls differ between encoders, but the diagnostic question does not: does the outgoing stream include an audio track, and does that track carry the expected programme?
If you can monitor the local RTMP output independently, do so before the Nginx-to-YouTube leg. Use a player or inspection tool you already trust, and avoid changing several settings while monitoring. A moving meter in the source application is useful, but it only confirms the source reached that application. A local copy of the encoded output is stronger evidence about what the encoder handed to the next stage.
Check the encoder’s audio-output configuration. Confirm that audio is enabled for streaming, that the intended mixer or input is included, and that the output is not assigned to a different track from the one the stream uses. If your encoder offers codec and channel settings, compare them with YouTube’s published guidance rather than guessing. YouTube Help lists AAC or MP3 for RTMP/RTMPS audio and recommends 44.1 kHz sample rate and 128 Kbps for stereo. These are platform recommendations, not proof that every different setting causes silence.
For an ordinary stereo programme, that guidance is a sensible baseline to test. YouTube’s guidance for 5.1 audio specifies 48 kHz and 384 Kbps, and says RTMP/RTMPS 5.1 is supported only with AAC. Do not switch to surround settings just because a stereo stream is silent; use the settings that match the programme and your encoder’s output. You can verify current recommendations in YouTube Help’s encoder settings guidance.
If the encoded output has no audio track, stay at the encoder and source boundary. Recheck the chosen input, the live mix, track assignment and whether audio output is enabled. If the encoded output has sound, preserve that result and move to the relay. That evidence is more useful than changing codec settings blindly, because it tells you the failure occurs later.
Check Nginx and any FFmpeg relay
First determine whether Nginx is simply receiving and forwarding the stream, or whether an FFmpeg command is launched to push or transcode it. Read the configuration that is active for the application receiving this broadcast. A sample configuration copied from a guide may not be the block handling your actual stream key or application name.
If you use FFmpeg, inspect the complete command and the corresponding runtime output. Confirm the input URL points to the intended local RTMP stream, not an old application or a different stream name. Check whether the command disables audio with -an. If it uses explicit stream mapping, check that the mapping selects the audio track you intend to send. A command that maps video but omits audio can still produce a picture at YouTube.
Next check what the command does to audio. A pass-through copy can work when the incoming audio codec and container arrangement are suitable for the next hop. It is not a universal setting: if the outgoing combination is incompatible, audio may need to be encoded instead. If the command transcodes, confirm that audio output is enabled, that the requested encoder exists in the installed FFmpeg build, and that the logs do not report mapping, input or encoder errors.
The nginx-rtmp module documentation includes FFmpeg examples that explicitly encode both audio and video. Those examples are useful for recognising that the audio path must be configured, but they are not evidence about your configuration and should not be pasted in without adapting them. Inspect the nginx-rtmp documentation alongside your own active directives and command. In particular, check any exec, exec_push or related process that is meant to relay the stream.
If you can play the Nginx input locally and hear sound, but the FFmpeg output is silent, the problem is within the relay or its command. If both the local input and output are silent, return to the encoder checkpoint. If the FFmpeg output is audible and YouTube is not, retain the command and logs as evidence and continue downstream. This is where a comparison of local output and destination health is more useful than replacing the entire Nginx configuration.
If audio is only being dropped after a transport change, investigate transport errors separately. YouTube recommends RTMPS for secure transmission; its RTMPS guide specifies the ingestion endpoint requirements, including port 443 and the SNI hostname. Those details matter when RTMPS connections fail or behave incorrectly, but a silent audio track alone does not establish an RTMPS problem. Consult the YouTube RTMPS ingestion guide if your logs show connection or handshake errors.
Verify YouTube ingest and playback
Use the Live Control Room as the destination-side checkpoint. Look at the live stream preview and stream-health messages while the test is running. A video preview with a health warning about audio is different from a preview that appears healthy but is silent on one viewer’s device. Note the exact message rather than paraphrasing it as “YouTube has no audio”.
YouTube’s Live API also documents stream status and health status, with configuration-issue categories that can include audio bitrate issues. If you use the API, inspect the reported state and issue type; do not infer that a bitrate warning means the track is absent. A warning is evidence to investigate against the output settings, while an absent track at an earlier checkpoint points back to that stage. The YouTube stream-health warnings guide explains how to read health information alongside encoder output.
Separate ingest from playback. Open the test on a second device or browser if practical, check that the player is not muted, raise its volume, and confirm the intended audio track is selected where the player offers track selection. If one player is silent and another plays the same live output, the evidence points towards the local playback path rather than a missing audio track in the broadcast.
If all playback is silent and YouTube health indicates an audio issue, return to the relay or encoder output and compare the earliest checkpoint that still has sound with the first one that does not. YouTube can only process what arrives at ingest, so changing player volume will not repair a missing outgoing track. Equally, if health looks normal and a second player works, changing the FFmpeg mapping is unlikely to be the right first step.
Keep notes of the time of each test, the stage checked, and the exact warning or log line. If you need help from someone familiar with your setup, the useful details are your encoder and audio-input settings, the relevant FFmpeg command and log lines, the active Nginx application block, whether a local RTMP copy has sound, and the exact Live Control Room message. Remove stream keys and other credentials before sharing configuration.
Run a controlled test and monitor health
Make a controlled test before relying on the channel overnight or for an event. Use representative audio and video movement: a devotional track should include the sort of music or speech your channel will carry, while a news loop should include its usual clips and transitions. A silent test pattern cannot establish that the audio path works. YouTube Help specifically recommends testing with audio and movement similar to the intended stream, then reviewing stream-health messages.
If you can, run the test as an unlisted or private broadcast appropriate to your workflow and check it from the Live Control Room and a viewer device. Keep the route unchanged while you capture the baseline: source meter, encoder output, relay logs, destination health and playback. This gives you a reference before making a correction. If the channel is already live, schedule the test in a way that does not unexpectedly interrupt viewers.
Change only the setting at the earliest failed checkpoint. For example, if the source and encoder output both have sound but FFmpeg’s output does not, test the mapping or audio-output portion of that command. If FFmpeg output is audible and YouTube flags a configuration issue, compare the actual codec and bitrate with YouTube’s guidance. Do not change source device, Nginx application, codec and player settings together; if sound returns, you will not know which adjustment fixed the path.
After each change, repeat the same test and re-check the same checkpoints. A successful short test is evidence that the particular route now carries audio under those conditions, not a promise that every future source or device will behave identically. Keep an eye on Live Control Room health while the broadcast runs, especially after changing an encoder, relay command or source.
For a channel that relies on a local computer remaining available all day, the operating method is a separate decision from audio diagnosis. StreamNeo is relevant when the specific burden is keeping a file-based broadcast running without leaving your own computer switched on; it does not replace checking that your file and YouTube output contain the intended audio. For overnight reliability, retain a repeatable test and monitoring routine whichever workflow you use.
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 my video but not play audio?
Video and audio are separate parts of the stream and can fail at different points. Check the source, encoder output and each relay before deciding whether the issue is at YouTube ingest or only in playback.
Can Nginx RTMP forward a stream without its audio?
Yes. If the incoming stream has no audio, the relay cannot forward a track that is not there; an FFmpeg command can also omit, disable or fail to encode audio. Inspect the active configuration, mappings and runtime logs rather than assuming every Nginx setup behaves the same way.
Which audio settings should I try for YouTube RTMP?
YouTube Help lists AAC or MP3 and recommends 44.1 kHz and 128 Kbps for stereo. Treat those as a baseline to compare against your actual output, not as a guaranteed cure for silence; first establish where the track disappears.
What information helps diagnose my specific stream?
Share the encoder name and audio-input settings, relevant FFmpeg command and log lines, active Nginx application configuration, whether a local RTMP playback has sound, and the exact YouTube health message. Remove stream keys and credentials before sharing.