When an SRS stream reaches YouTube but has no sound, trace the audio from its source through FFmpeg and SRS to YouTube ingest before changing codecs. Silence can begin at capture, disappear through stream mapping or transcoding, or arise at a later hand-off; a codec change cannot restore audio that never entered the pipeline.
First identify your SRS version, input and output protocols, and whether SRS is running an FFmpeg transcode engine. The relevant settings differ between a direct publish, a transcode workflow and an HLS delivery path, so treat the checks below as diagnostic procedures rather than universal fixes.
Locate where audio disappears
Draw the actual path your stream takes: capture or source file, FFmpeg input, FFmpeg output, SRS, the configured YouTube ingest, then YouTube’s preview. Mark which process handles each hand-off. A file sent by an encoder to SRS over RTMP, for example, may be handled differently from a workflow in which SRS starts FFmpeg to transcode and republish it.
Check for audio at each boundary, not merely for a video picture or a successful connection. A moving picture in YouTube’s preview proves that some video reached YouTube; it does not establish that an audio track accompanied it. Likewise, a connected SRS publisher does not prove that the outgoing stream contains audio.
Keep a short record as you inspect: what is the input, what does the process at that boundary report, and what is the next output? Note whether the sound is absent everywhere or only in YouTube, and whether the issue affects a test file as well as the normal programme. This narrows the fault without changing several settings at once.
If you operate a devotional or local-language music channel, use a brief representative segment for testing. Include the kind of source and transitions used in the real broadcast, but avoid publishing a test to viewers if the channel is meant to remain uninterrupted. The approach to a continuous channel is different from repairing an account-level eligibility problem; for that separate issue, see why YouTube can say live streaming is unavailable.
Check whether the source contains audio
Start before FFmpeg or SRS. For a file-based loop, play the source locally and check that the intended audio is audible throughout the section you expect to stream. A container can contain video while its audio is missing, silent, or on a different track from the one you expect. If the source is a live capture, verify that the selected microphone, mixer, desktop output or other expected input is active and is the one the capture application is actually receiving.
Then check what enters the first encoder or server. If the source device or file provides no audio track, a downstream encoder can neither pass along that programme audio nor recreate it. Avoid compensating by buying or replacing capture equipment until you have established an upstream input fault; missing audio later in the path is not evidence that a microphone or interface is defective.
For a source with several audio tracks, identify which one carries the programme. A file may include commentary on one track and music on another, or the first track may be silent. Confirm which track the ingest process selects instead of relying on a player’s default choice, which may differ from FFmpeg’s selection.
Make one change at a time and verify the same boundary again. If audio is audible at the source but not at the first process output, investigate that process’s input selection and mapping next. If it is absent at the source itself, fix the capture or source file before changing SRS codec settings.
Inspect FFmpeg stream mapping
FFmpeg has to select an audio stream from its inputs and send it to an output. When a command has multiple inputs or tracks, do not assume it has chosen the intended one. Read the startup log or stream listing to establish which audio streams FFmpeg sees, and inspect the output mapping to see whether an audio stream is included. The exact command and log format depend on the FFmpeg build and the command line in use.
Look for an explicit mapping that selects the intended audio input and output stream, and check that the command does not suppress audio. For example, an output option that disables audio can deliberately create a video-only stream. A command that maps video from one input but fails to map audio from the relevant input can produce the same visible symptom at the destination.
Do not paste a generic mapping command over an existing workflow before identifying its inputs. A single-input file, a capture device, and a command combining separate video and audio inputs need different stream selections. The useful diagnostic question is not simply whether a command contains a mapping flag; it is whether the selected output audio comes from the source you intend.
Inspect the FFmpeg output itself before moving on. If possible, play or probe a local recording or a suitable test output and confirm that the audio stream is present and audible. If the output is already silent, SRS and YouTube are not the first places to change. For a wider overview of a continuous FFmpeg loop, including resource considerations, the VPS memory guide for an FFmpeg YouTube loop is relevant, but memory sizing does not diagnose a missing audio mapping.
Check transcode settings and audio format
Establish whether SRS is actually transcoding. In a documented SRS workflow, an encoder can publish RTMP to SRS and SRS can optionally start FFmpeg to transcode and publish onward. A different workflow may publish directly to SRS without that transcode stage. Find the deployed configuration, process logs and generated command, rather than inferring transcoding from the fact that SRS is present.
If an SRS transcode is active, inspect its audio-related settings in the context of the installed version. The SRS v3 FFmpeg configuration reference documents fields such as acodec, abitrate, asample_rate and achannels. Its examples distinguish copying audio, encoding it with AAC, and disabling it with acodec an. Copying preserves the input audio codec; it does not convert it to a format suitable for every destination. Disabling audio yields no audio output by design. The reference is version-scoped, so compare it with the documentation for your deployed release rather than treating an older example as current configuration advice.
The project’s SRS FFmpeg configuration reference and SRS FFmpeg workflow documentation help distinguish these paths, but the latter is marked as archived documentation. Check the active configuration and generated FFmpeg command or log to see what is actually running. A configuration file alone may not tell you whether a transcode task has started or whether the output is the one YouTube receives.
Once you know where encoding occurs, compare the outgoing format with the destination protocol. YouTube’s live encoder settings list AAC or MP3 audio for RTMP/RTMPS. For stereo, its recommendations include a sample rate of 44.1 kHz and bitrate of 128 kbps; for 5.1 over RTMP/RTMPS, it specifies AAC, with recommended settings of 48 kHz and 384 kbps. These are YouTube’s protocol-specific recommendations, not universal requirements for every SRS output or HLS workflow. Recheck the current official guidance before changing a live configuration.
Channel layout matters as well as codec. YouTube supports mono, stereo and 5.1 ingestion; an unusual layout may not convert to stereo as intended. Confirm the number and arrangement of channels in the input and output, especially if the source is surround audio but the audience expects stereo playback. Changing the codec without checking the mapped track, channel layout and outgoing protocol may leave the underlying problem untouched.
| Diagnostic branch | What to establish | What the finding means |
|---|---|---|
| Source or capture | The intended audio is present before encoding | If absent, investigate the file or selected input first |
| FFmpeg selection | The intended input track is mapped to the output | If omitted or suppressed, codec settings will not restore it |
| SRS processing | Whether SRS copies, transcodes or disables audio | A copied track keeps its source format; a disabled track is absent |
| Destination format | Protocol, codec and channel layout at YouTube ingest | Compare RTMP/RTMPS output with YouTube’s current guidance |
| YouTube preview | Audio is present in the ingest preview | If earlier boundaries have sound, continue tracing the final hand-off |
Trace audio through SRS and output
Follow the output that actually leaves SRS, not just the input it receives. If SRS copies audio, the output should retain the incoming audio format; if an FFmpeg task transcodes, inspect the task’s output and any reported errors. If the configuration disables audio, or the generated output is video-only, the failure is already on the SRS side of the hand-off. Record the SRS release, protocol on each side, and whether a transcode engine is active before consulting examples.
Separate YouTube’s RTMP or RTMPS ingest from SRS’s HLS delivery. HLS has its own packaging and timestamp behaviour, and an HLS-specific setting should not be applied as a general remedy for silent YouTube RTMP ingest. SRS’s HLS delivery documentation notes AAC for audio-only HLS delivery and H.264 with AAC or MP3 for its HLS path. It also discusses possible audio corruption during timestamp conversion between FLV and MPEG-TS. Those details matter when the symptom is in an SRS HLS output, not as a blanket explanation for silence in a YouTube ingest.
If your setup has both an HLS player and a YouTube destination, test them independently. Sound in one output and not the other suggests the fault lies after the paths diverge, although it does not by itself identify the setting responsible. Check each output’s track and protocol rather than changing a shared source codec based on one player’s behaviour.
A 24/7 broadcast also needs recovery planning, but automatic restarting is a separate concern from audio continuity. If your channel uses a looped source, the guidance on restarting an Indian music YouTube live stream automatically covers a different failure mode. Restarting a process can restore a dropped connection; it cannot correct an absent source track or an audio stream disabled in the output configuration.
Verify the YouTube ingest signal
Check the configured ingest destination and stream key separately from audio. YouTube recommends RTMPS for transport security, but using RTMPS does not itself repair missing sound. A correct-looking video connection only establishes part of the path; inspect YouTube Live Control Room’s preview and stream health messages for evidence that audio is reaching ingest.
YouTube recommends testing with audio and video representative of the intended broadcast, then monitoring stream health and messages during the event. Use that preview before starting a public event where possible. If it has no sound, work back through the boundaries you recorded: confirm FFmpeg output first, then SRS output, then the source. This avoids changing the source or destination based only on a silent preview.
Keep tests representative. A short segment with the same audio layout and processing path is more useful than a different file that happens to play locally. If a test succeeds but the regular stream is silent, compare the actual source, selected track and active command or SRS configuration between the two. Changes made for a test may not be present in the scheduled or restarted production process.
For a channel intended to run continuously, a planned test window and a written record of the working source, mapping and output settings make later troubleshooting less disruptive. The guide to streaming recorded church services as a YouTube live stream in India addresses a recorded-content workflow; the same principle applies here: confirm the actual scheduled output, not only a manual preview.
After the signal is verified, keep the configuration that corresponds to the known-good test and monitor the next live session. If the issue returns, note the last boundary with audio and any version, input, protocol or configuration change since the test. That evidence is more useful than cycling codecs without knowing which stage changed.
If maintaining a computer-powered encoder through the night is itself part of the operational problem, StreamNeo can remove the need to keep that computer running by taking an uploaded video and broadcasting it to YouTube continuously; it does not repair an audio fault in an SRS-to-YouTube path, so verify the file and intended channel before using it.
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 SRS video but no sound?
Video and audio are separate streams, so video reaching YouTube does not prove that audio was captured, selected, or forwarded. Check the source first, then the FFmpeg output, SRS output and YouTube preview to identify the first boundary where sound is missing.
Should I change the audio codec to AAC?
Not before confirming that the source contains the intended audio and that FFmpeg maps it into the output. YouTube lists AAC or MP3 for RTMP/RTMPS audio, but codec choice alone cannot restore an omitted or disabled track. Check the protocol, channel layout and current YouTube guidance as well.
Which SRS audio setting should I inspect?
If SRS is running an FFmpeg transcode, inspect the active configuration and generated command for the audio codec, bitrate, sample rate and channels. Also establish whether audio is copied, encoded or disabled, and check documentation for your deployed SRS version. Direct publishing without an SRS transcode has a different diagnostic path.
Can an HLS timestamp option fix silent YouTube RTMP audio?
Do not assume so. SRS HLS timestamp notes concern its HLS delivery path and should not be applied as a general fix for YouTube RTMP or RTMPS ingest. Trace the actual protocol and locate the missing audio at a specific boundary first.