If your FFmpeg gaming VOD loop reaches YouTube but has no sound, first check that the source file contains an audio stream and that FFmpeg selects it for the output. Then confirm the output audio settings against the ingest protocol you are actually using; HLS requirements are not automatically RTMP requirements.
The order matters. A codec option cannot recover sound that is absent from the file or omitted from the output, and a looping option only repeats the input. Work from the source towards YouTube so you can tell whether the problem is missing audio, an unmapped track, a silent signal, or an incompatible output.
Confirm the source file contains audio
Start with the VOD itself, before changing the command that publishes it. A file can show the expected gameplay perfectly while containing no audio track: perhaps it was captured with desktop audio disabled, exported with the wrong track, or deliberately made silent. Playback in a media player is a useful first check, but inspect the file’s stream inventory as well, because a player can conceal which tracks it is using.
Use ffprobe, which is distributed with FFmpeg, to list the streams. For example:
ffprobe -v error -show_entries stream=index,codec_type,codec_name,channels,sample_rate -of default=noprint_wrappers=1 input.mp4
Look for a stream whose codec_type is audio. The index, codec, channel count and sample rate help distinguish it from the video stream and from any additional tracks. The command is an inspection example, not a guarantee that every container or FFmpeg build will print identical details.
If no audio stream appears, stop adjusting -map or audio encoding flags. There is nothing in that file for those options to select or encode. Return to the recording or export and create a version with sound, or intentionally provide a separate audio input if that is part of your design. A microphone or music file can provide new audio, but it does not restore the missing original game sound.
If an audio stream exists, listen to a section of the file as well. An audio track can be present yet contain silence, the wrong capture source, or a level so low that it sounds absent. This distinction will matter later: FFmpeg can route an audio stream without making an inaudible signal audible. For a broader explanation of keeping a live mix intact, see how to add background music without losing the audio mix.
Inspect which input streams FFmpeg selects
When FFmpeg starts, it reports information about each input, including the stream indices and types it sees. Read that inventory rather than relying on the fact that the command names the right filename. Check that the intended audio stream is listed under the input you think it is, and note whether there are multiple audio tracks.
A gaming recording may contain commentary, game sound, or separate tracks for each. The first audio stream is not necessarily the one you want. If commentary and game sound are separate, choosing only one can produce a technically valid broadcast that seems silent to a viewer expecting the other. Match the stream index to a short local listen or to the recording settings where possible.
The -stream_loop -1 option tells FFmpeg to loop an input indefinitely. It does not create an audio stream, choose an audio track, or test whether the track contains audible sound. If both video and audio are in the same input, looping repeats that input; whether the output includes its audio still depends on selection and mapping. Treat looping and audio routing as separate checks.
This is also why changing loop settings is a poor first response to silence. If the first pass has no mapped audio, repeating the input will repeat that same output condition. If the source has a genuine audio track but a later loop boundary produces a brief gap, that is a different fault from a stream that is silent from the start. The guide to removing audio gaps when looping videos on YouTube Live addresses that separate problem.
Check the output stream mapping
FFmpeg’s -map option determines which input streams are sent to each output. Automatic selection can be convenient, but an explicit mapping makes the intended video and audio easier to verify, especially when there are multiple inputs or tracks. The FFmpeg documentation describes stream selection and mapping; compare its examples with the input inventory printed by your own run.
For a single input where you want its first video stream and first audio stream, an illustrative starting point is:
-map 0:v:0 -map 0:a:0
Here 0 identifies the first input, while v:0 and a:0 identify the first video and audio streams within it. If the audio you want is on another input or has a different index, adjust the mapping accordingly. These selectors are examples, not a tested command for an unspecified recording or publishing setup.
After you start FFmpeg, inspect its Stream mapping lines. They should show the intended input audio stream being routed to the output, alongside the video mapping. If the input inventory lists audio but the mapping section does not route it, the output will not contain that audio track. Correct the selection before investigating YouTube’s encoder compatibility.
Watch for an optional mapping such as -map 0:a?. The trailing question mark makes the mapping optional: FFmpeg can proceed when the input has no matching audio stream. That may be useful when a batch contains files with and without audio, but it can also hide the fact that one particular VOD produced an output with no audio. The command completing successfully is not proof that sound was mapped.
If the output is assembled from a video input and a separate music or commentary input, map each deliberately and verify that the selected streams are the ones intended. Avoid changing several maps at once: make one clear correction, inspect the new mapping report, and then test the resulting output. For other playlist arrangements, setting up FFmpeg to play recorded lessons in alphabetical order on YouTube is a relevant example of planning the input sequence; the audio mapping still needs to be checked for your own files.
Verify audio codec for the ingestion protocol
Only after confirming that a real, intended audio stream is mapped should you consider its output encoding. First identify whether your YouTube broadcast uses RTMP or HLS. Do not copy an HLS setting into an RTMP command just because both send a live stream to YouTube; consult the current YouTube guidance for the protocol and encoder you use.
YouTube’s HLS setup guidance describes audio options including AAC, AC3 and EAC3, and gives recommended sample rates and bitrates for particular channel layouts. Google’s YouTube HLS ingestion guide specifies HLS packaging requirements, including muxed audio and video in M2TS and AAC audio with one audio track. Those are HLS-specific statements. They do not establish that the same container or codec rules apply to RTMP.
For HLS, check the official documentation directly for the currently applicable packaging and audio requirements, then compare them with the output you are producing. For RTMP, use the matching current YouTube guidance rather than inferring requirements from the HLS pages. A codec conversion can help when a mapped track is encoded in a way the confirmed protocol does not accept. It cannot make an absent track appear, fix an incorrect -map, or turn a silent input signal into audible content.
Also distinguish a codec problem from a signal problem. If your local output contains an audio stream encoded in the expected format but listening reveals silence, changing codec alone is unlikely to resolve the cause. Check whether the VOD’s audio is audible, whether the intended channels were selected, and whether any filters or separate input choices in your command alter the signal. The documentation cited here sets out mapping and HLS compatibility, but it does not identify one universal cause for a mapped track that is silent.
Test the output locally before sending it
Before committing a long gaming VOD loop to a live broadcast, make a short output file using the same relevant input selection, mapping and encoding options. Inspect that file with ffprobe to confirm it has an audio stream, then listen to it in a media player. Check a portion near the beginning and, if practical, a point where the video loops; the goal is to confirm both that sound exists and that the chosen track is the one viewers should hear.
Keep the test narrow. If the local output lacks an audio stream, return to the mapping and input report. If the stream exists but is silent, return to the source and signal path. If it is audible locally but YouTube receives no audio, then check the confirmed ingest protocol and the live diagnostics. Separating those outcomes avoids changing a working part of the command without evidence.
A controlled live test can help when local playback is correct but the receiving path remains uncertain. Use a short test rather than relying on a full overnight loop, and check the actual broadcast from a viewer’s perspective as well as the encoder log. A local player confirms what the output file contains; it does not by itself prove that YouTube has received or presented the audio correctly.
If you are switching from a computer-based setup to a file-based continuous broadcast, keep the diagnostic layers separate even when the workflow changes. An uploaded file can remove the need to keep a local playback machine running, but the file still needs sound and a correctly selected audio stream. StreamNeo removes the specific burden of leaving your computer on to keep an uploaded video broadcasting, while source audio and YouTube ingest compatibility still need to be right.
Use YouTube Live diagnostics to narrow the issue
Once the output is locally audible and its audio stream is mapped, look at YouTube Live’s current stream health and diagnostics. They can help establish whether YouTube is receiving the broadcast and whether the ingest session reports a problem. Compare what YouTube reports with the FFmpeg output, rather than assuming that a live preview alone proves the entire path is healthy.
Keep protocol-specific errors in scope. The Google HLS ingestion guide documents responses such as malformed URL or playlist, invalid or expired identifier, wrong method, and server processing failure for HLS requests. Those response codes can help diagnose an HLS delivery or destination problem; they are not a universal list of RTMP audio errors. If you use HLS and receive an error, check the response and the current official guide. If you use RTMP, consult the corresponding YouTube and encoder diagnostics.
A useful hand-off is to record the exact command, FFmpeg version, input inventory, Stream mapping lines, and the protocol in use. If you need help from someone who can inspect the setup, those details are more useful than saying only that YouTube is silent. They let another person determine whether the audio was missing at the source, excluded at mapping, present but silent, or sent through a protocol path that needs separate investigation.
You can use the decision points below to avoid repeating tests that have already passed:
| What you find | What it suggests | Next check |
|---|---|---|
| No audio stream in the source inventory | The VOD has no selectable audio track | Re-export with sound or deliberately add an audio input |
| Audio listed in the input, absent from output mapping | FFmpeg is not routing the intended track | Correct -map and inspect the new mapping lines |
| Audio mapped, but local output sounds silent | The track may carry silence or the wrong signal | Listen to the source and check track and channel selection |
| Output audible locally, YouTube silent | The source and local output have passed basic checks | Confirm ingest protocol, output compatibility and live diagnostics |
The table narrows the next investigation; it does not prove a single cause. In particular, an output file that contains an audio stream can still contain silence, and a correct local file does not establish that YouTube has accepted every part of a live ingest session.
For a channel that depends on long-running playback, validate the exact file and command you plan to use before leaving it unattended. If the cause remains unclear, preserve the logs and make one change at a time. That gives you a useful comparison between runs instead of a new command whose behaviour is harder to explain.
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
Does -stream_loop -1 loop the audio too?
It loops the input indefinitely; it does not create, select, or verify an audio track. When the input contains audio and the output maps it, the repeated input can carry that track through the loop. Check the output mapping and listen rather than treating the loop option as an audio setting.
Will -c:a aac fix a silent YouTube stream?
Not if the source has no audio or FFmpeg has not mapped an audio stream. First confirm the input stream and output mapping, then check whether the mapped signal is audible. Consider codec changes only when a real, intended audio stream is present and you have confirmed the relevant ingest protocol’s requirements.
Should I use HLS audio settings for an RTMP stream?
No: the cited AAC, M2TS and other requirements are specifically for HLS. Confirm whether your setup sends HLS or RTMP and follow current official guidance for that protocol. Do not infer RTMP requirements from an HLS encoder page.
What information should I share if I still cannot find the cause?
Share the FFmpeg command with any private stream key removed, the FFmpeg version, the source stream inventory, the output Stream mapping lines, and the ingest protocol. Also say whether the VOD and a locally produced test output are audible. Those facts help separate a missing track from a mapping, signal, or ingest issue.