If YouTube Live is not accepting your audio-only podcast stream from FFmpeg, first check whether the outgoing feed contains a video track as well as audio. YouTube’s encoder guidance and preview workflow are built around video streams, so a missing video track is the best-supported place to begin, though the official guidance reviewed does not say that every audio-only feed is rejected.
The practical fix is usually to send your podcast audio together with a simple visual, such as cover art or a title card. Then check the encoder settings, connection details and Live Control Room preview before you start the broadcast.
Check whether the output contains video
Start with the stream FFmpeg is actually sending, rather than the media file you intended to send. A podcast file may contain only audio, and a command that maps that source directly to an RTMP output will normally provide no picture for YouTube to preview. Check the output mapping and FFmpeg’s stream description to see whether the final output includes both video and audio.
The distinction matters because a local audio file can play correctly while the live feed still lacks a video stream. If FFmpeg reports only an audio stream, or the command maps only the podcast input, you have found a concrete configuration problem to investigate. That is not proof that YouTube rejects all audio-only feeds; it is a reason to test with a valid video track, since YouTube’s published encoder settings describe video formats and its live workflow asks you to wait for a preview.
You do not need camera footage to add video. A still cover image, an episode title card, or a generated visual can provide a picture while the podcast remains the programme audio. The image can stay still; a visualizer is optional. If the podcast has several episodes or clips, the principles in looping video files in FFmpeg for YouTube Live may help you think through the video side of the output, although a single cover image is enough for this diagnostic.
For a quick review, note the inputs and mappings separately: which input supplies the podcast audio, which supplies or generates video, and which streams are mapped to the output. This makes it easier to spot a missing mapping or a mistaken stream selection. If your command is long, temporarily reduce it to those two inputs and their output mappings before investigating filters or other processing.
Review YouTube’s encoder requirements
Use YouTube’s current encoder settings guidance as the reference for the ingest format. YouTube lists H.264, H.265/HEVC and AV1 for video over RTMP or RTMPS, and AAC or MP3 for audio. It also gives guidance on frame rate, resolution, bitrate and keyframe intervals. These are settings to compare against your encoder output, not a promise that matching them by itself will make every stream connect.
For stereo audio, the advanced recommendations specify 44.1 kHz and 128 kbps. YouTube recommends a two-second keyframe interval and says not to exceed four seconds. Treat these as YouTube’s published recommendations, and check the page again when you configure a stream because platform guidance can change. Avoid choosing a video bitrate in isolation: YouTube’s recommendations vary with resolution and frame rate, so select those first and consult the corresponding current range.
For a podcast, the audio settings can be sensible while the stream still has a video problem. Check both sides. Confirm that the audio codec and sample rate are suitable, then verify that the output has a supported video codec, a deliberate resolution and frame rate, and a regular keyframe interval. An audio-only source does not acquire a video stream simply because you set video options; FFmpeg needs a video input or a filter-generated source and must map it to the output.
YouTube’s setup instructions also tell you to connect using the stream URL and stream key shown for the chosen stream in Live Control Room. Do not reuse a key or address from an unrelated broadcast without checking that it is the intended stream. YouTube recommends RTMPS. If the connection fails, check that the URL uses the secure protocol, the server address is correct and your FFmpeg build supports RTMPS; YouTube’s RTMPS instructions describe the connection options.
Inspect the FFmpeg output stream
Look at the command’s inputs, mappings and codecs in that order. If you have one audio input and one generated or image-based video input, explicitly map the video from one and the podcast audio from the other. Then encode the selected streams to compatible formats for the chosen output. This is a useful mental model even if you build the command through a script or a wrapper rather than typing it by hand.
FFmpeg’s device documentation describes lavfi, a virtual input device that can provide generated media. It can be used to create a simple video source without a camera. A still image is another straightforward option. The exact command depends on your FFmpeg version, input format, desired picture size and frame rate, and whether the image or generated source should continue for the duration of the podcast. Check the documentation for your installed build rather than copying a command whose assumptions may not match your files.
When reviewing a command, ask four specific questions. Does it open the intended podcast file? Does it provide a video source that lasts for the needed duration? Does the output mapping include one video stream and the podcast audio? Does the output select compatible codecs and a suitable container/protocol for YouTube’s ingest? If any answer is unclear, inspect FFmpeg’s output messages or simplify the command until the mapping is obvious.
A common mistake is to map every stream from an input and assume that this creates a video track. It does not: mapping controls which existing streams are sent, and an audio file has no picture stream to select. Another is to generate a visual but leave it out of the final mapping. The output can then remain audio-only even though the command mentions a video source.
If you need an example of a more complete FFmpeg workflow, building a continuous music stream with FFmpeg concat covers a related continuous-stream use case. Its details may differ from a podcast feed, so adapt the source and mapping logic rather than treating a command from another workflow as a drop-in fix.
Wait for the Live Control Room preview
After connecting, allow Live Control Room time to receive and process the incoming feed. YouTube’s encoder setup workflow includes waiting for a preview before going live. If you do not see one, check the feed itself and the connection details before changing several encoding settings at once.
Use the preview to distinguish a missing picture from a broader connection problem. If audio is present but no picture appears, revisit the video source and mapping. If neither appears, verify the stream key, server address, protocol support and FFmpeg connection messages. If a picture appears but audio does not, inspect the audio mapping and encoder settings instead. Changing one area at a time gives you a clearer indication of what fixed or worsened the issue.
Review any stream-health messages shown in Live Control Room. They can point to a problem with the incoming feed, but a healthy-looking preview is not a guarantee that the broadcast will remain uninterrupted. Keep the encoder output visible during your test and check that the image and audio continue, rather than relying on the first frame alone.
For a 24/7 channel, this is a useful point to validate more than initial connection. Let the planned inputs and settings run long enough to reveal whether the generated image ends early, the podcast file reaches its end, or FFmpeg exits when an input finishes. A successful short preview confirms that a feed arrived; it does not establish that a looping schedule or long-running process will behave as intended.
Choose a visual that fits an audio-first show
The video track can be functional without distracting from the podcast. Choose a visual that tells viewers what is playing and remains legible on a phone. A cover image is simple to prepare; a title card can include the show or episode name; a waveform or visualizer adds movement but requires more setup and should be checked for readability.
| Visual approach | Setup effort | Useful when | Trade-off |
|---|---|---|---|
| Static cover image | Low | You want a stable show identity with minimal processing | It does not change as the episode plays |
| Title card | Low to moderate | Episode name or schedule matters to viewers | Text may need changing between episodes |
| Waveform or visualizer | Moderate | You want visible movement alongside audio | More filtering or a separate visual source must be maintained |
A still image is often enough to test whether the missing video track was the issue. For a public channel, consider whether the image gives viewers enough context and whether it is yours to use. The visual need not be elaborate, and there is no need to buy a camera merely to put a picture in the stream.
If you already use OBS for scenes and episode changes, the guide to switching podcast episodes with OBS scenes offers a related way to organise changing programme visuals. That is a different workflow from FFmpeg alone; use it only if scene switching is useful to your production, not as a requirement for getting a basic feed accepted.
Consider silent audio only when the source has no audio
The problem here is a podcast: it already has the audio you want to broadcast. Keep that audio as the programme sound and add video alongside it. Do not replace the podcast audio with silence as a generic fix for an audio-only feed.
You may encounter advice to add silent AAC audio when sending video-only material. An FFmpeg-user mailing-list post describes a particular attempt involving YouTube Live and missing audio, but that is an anecdote, not an official YouTube rule or a guaranteed workaround. It addresses the reverse case: video without meaningful audio. YouTube’s official guidance reviewed here does not say that silent AAC is required to make every stream work.
If you are streaming a visual with no sound at all, a silent audio track could be one diagnostic option to test, but only after checking current YouTube guidance and the behaviour of your encoder. It does not substitute for a video track when your outgoing stream has only podcast audio. Keep the distinction clear: a podcast feed needs its intended audio plus a video source if the missing picture is the likely cause.
Test before going live
Test with the same kind of audio and movement you plan to use in the broadcast. YouTube’s encoder guidance says tests should include audio and movement in the video similar to what you will do in the stream. For a podcast with a static card, that means checking that the card appears and the podcast is audible; if you choose a visualizer, check that it moves as expected. Do not add movement merely to satisfy an assumption about YouTube.
Before a public start, run through a short checklist:
- Confirm the intended stream URL and key in Live Control Room.
- Check that FFmpeg reports both audio and video in the outgoing feed.
- Verify that audio is mapped from the podcast and video from the image or generated source.
- Compare codecs, audio settings, frame rate and keyframe interval with YouTube’s current encoder guidance.
- Wait for the preview and review stream-health messages.
- Confirm that the audio and picture continue for the duration you expect.
If RTMPS does not connect, first verify the address and protocol, and check that your FFmpeg build supports it. The official RTMPS guidance notes the secure endpoint and connection details; where appropriate, it describes trying port 443. Do not switch protocol settings blindly: confirm the endpoint in Live Control Room and use the current official instructions for your account and encoder.
When a test works, save the exact command, input paths and settings that produced the preview. This makes it easier to restore a known-good configuration if you later change artwork, audio processing or resolution. If it fails, record the observed symptom—no preview, audio without picture, picture without audio, or a connection error—and change the relevant part rather than rebuilding the whole command at once.
For people who would rather not keep a personal computer running to hold a continuous broadcast together, StreamNeo removes that particular burden by turning an uploaded video into a YouTube live stream that can continue with the computer switched off. It does not remove the need to prepare the file, use your own stream key or check that the channel and content are ready.
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 YouTube Live reject every audio-only FFmpeg stream?
The official YouTube pages reviewed do not state that every audio-only feed is rejected. They document video encoder settings and a preview-based workflow, so a missing video track is a reasonable first diagnosis when a feed is not accepted. Check the outgoing stream and test with a simple video source rather than treating the diagnosis as a universal platform rule.
What is the simplest video to add to a podcast stream?
A static cover image or title card is usually the simplest option. FFmpeg can also provide generated media through lavfi, but the exact command depends on your build and inputs. Make sure the video source is mapped into the output and lasts as long as the audio you intend to send.
Should I add silent AAC to make YouTube accept the stream?
Not as a general fix for a podcast feed, which already has audio. The anecdotal mailing-list example concerns a video-only case and does not establish an official requirement or a guaranteed workaround. First add and map a video track while retaining the podcast audio.
What should I check if Live Control Room has no preview?
Check whether FFmpeg is sending both video and audio, then verify the stream URL, key and RTMPS support. Review the health messages and change one relevant setting at a time. Recheck YouTube’s current encoder and connection guidance, since interface labels and recommendations can change.