If your FFmpeg stream reaches YouTube with audio but no video, first establish whether FFmpeg sees video in the intended input. If it does, follow that stream through the mapping and encoder stages, then check what YouTube actually receives; audio alone does not show that the video path is working.
There is no reliable one-line fix without your command, FFmpeg build, input type and logs. Use the checks below in order, changing one relevant part at a time so you can identify where video disappears rather than masking the cause.
First locate where video disappears
Think of the broadcast as a chain: source, FFmpeg input, stream selection or filters, encoding and output, then YouTube ingest. The useful first question is not “Which YouTube setting should I change?” but “At which point can I last prove that a video stream exists?” Audio can survive a fault in any of the video stages.
Separate three observations. The input listing says what FFmpeg opened. The stream mapping and later log lines indicate what it intends to send and whether processing starts. YouTube’s live preview tells you what reaches ingest. Those are different checkpoints: a video entry in the input log does not prove that it was mapped, and a successful audio signal does not prove that the preview has moving pictures.
Before changing the command, note what you are using as the source: a video file, a capture device, or another input. Keep the current command and log intact as a baseline. If you change the input, mapping and encoder flags together, a successful result will not tell you which change mattered.
For a file-based loop, the source and playback approach matter as much as the output flags. The discussion of always-on streaming from a Windows mini PC is useful context for distinguishing a local playback setup from a direct FFmpeg input. If your source is a camera or capture device, do not assume that selecting a device name means it is exposing the format you expect.
Read the FFmpeg input listings
Run the command with the same inputs and input options you normally use, then inspect the Input #... sections near the start of FFmpeg’s log. Find the entry for the intended source and check whether it lists a Video: stream as well as any expected Audio: stream. The codec and format details can help later, but this first pass is about whether video is present at all.
If the intended input lists audio but no video, output settings cannot manufacture the missing source stream. Check that the command points to the right file or device, that the input options belong before the relevant -i, and that the source itself contains video. With a capture device, supported formats and available modes vary by device and operating system. Consult that device’s documentation and FFmpeg’s device options rather than copying flags for an unrelated camera.
If there are several inputs, match each Input # number to the source you intend to use. A command may open a music file and a video file separately; finding video on one input is not enough if later mapping selects another. Similarly, a file can contain audio and video while a capture input exposes only audio. Record the stream numbers shown under each input before editing any -map value.
FFmpeg’s documentation describes input handling and stream selection. For device inputs, available formats and options depend on the particular device; the relevant device documentation is the place to confirm how to list or request them. If no video appears in the input listing, stay on the source branch of the diagnosis until it does. Do not start by changing YouTube’s ingest protocol.
Check which streams the output receives
When input video is present, find the Stream mapping: section. It should show a video stream from the intended input being carried to a video output. Also check the lines after mapping: if FFmpeg reports an error while opening or processing the video encoder, the problem is further along than input discovery.
Without explicit mapping, FFmpeg selects streams automatically. Adding -map changes that behaviour for the output and places selection under your control. A command can therefore continue sending audio while excluding video, selecting the wrong input, or naming a stream that does not exist. Read the mapping in context rather than assuming that a syntactically valid command includes every stream you intended.
For example, if the probe shows video as the first video stream on input 0 and audio as the first audio stream on input 1, a deliberate mapping could be -map 0:v:0 -map 1:a:0. This is an illustration, not a universal fix: those input and stream indices must match your own log. If audio and video are both on input 0, or if their stream order differs, copying this example can omit the wrong stream or fail.
A filter graph needs the same care. When -filter_complex creates a labelled video output, that output must be directed to the final output, for example with -map "[outv]", using the label actually defined in the graph. Inspect the graph from its input selectors through to its output labels. An unlabelled filter output can have special mapping behaviour, so do not treat an absent label as proof that FFmpeg will select the stream you meant.
If you are moving an existing desktop or capture workflow into FFmpeg, compare how each tool identifies its source and output. The practical differences in OBS and Streamlabs recording workflows can help clarify what was selected in the earlier workflow, but they do not establish what your FFmpeg command maps. Use FFmpeg’s own log as the evidence for this command.
Verify encoder and pixel-format compatibility
If the mapping shows video going to the output, inspect the video encoder stage. Look for the selected encoder, whether FFmpeg can initialise it, and any error referring to dimensions, frame rate, pixel format or an unsupported option. Audio may encode successfully even when the video encoder cannot start, so read the video-related lines rather than treating overall audio output as a pass.
Encoder availability depends on the FFmpeg build and the encoder selected in the command. The FFmpeg codec documentation describes encoders and their options. Confirm that the encoder exists in your build and check its accepted formats and requirements. Then compare those with the pixel format and frame properties in the input log. If the error points to an incompatible pixel format, conversion may be needed, but the appropriate conversion depends on the source and encoder.
Do not assume that -c:v copy is a general substitute for encoding. Stream copy passes the compressed video through without decoding and re-encoding it; it cannot apply a video filter or convert pixel format. It can be appropriate when the existing stream is suitable for the output, but it will not repair a format that needs conversion. Conversely, adding a conversion filter does not help if the input has no video or the filter output is not mapped.
Change only the parameter supported by the error. For example, an encoder-initialisation message directs you to check encoder availability and accepted input properties; a missing stream in the input listing directs you back to the source. Keep the previous command so you can compare logs after each edit. Avoid replacing a working audio configuration just because the video path has failed.
Test with moving video at YouTube ingest
Once FFmpeg’s log shows video entering the intended output path, check the live preview before relying on the stream for a public broadcast. Use a representative test: the same kind of moving picture and audio you intend to send. A still image can establish that a picture is present, but it may not reveal a problem that appears only when frames change.
YouTube’s live encoder guidance says: “Tests should include audio and movement in the video similar to what you'll be doing in the stream.” Follow the current official guidance for the ingest settings relevant to your stream. Observe the preview rather than inferring video health from the fact that the stream has connected or audio is audible.
If FFmpeg reports a mapped video output but YouTube’s preview remains blank, compare the output log and the ingest result. Check whether video frames are being processed and whether the output continues without a video-specific error. Then verify that the output settings suit the ingest route you have configured. Do not call ingest healthy merely because the audio meter moves.
HLS is not a catch-all fix for a missing picture. YouTube documents HLS as an ingest route for HDR or codecs not supported by RTMP, with higher latency and its own format requirements. Consider it only if your content or codec calls for it, and check YouTube’s current HLS guidance. Switching protocol cannot restore video that was absent from the input or left out by mapping.
Compare FFmpeg output with channel health
Use the FFmpeg log and the YouTube dashboard as separate evidence. FFmpeg tells you whether it found input video, which streams it mapped, and whether the encoder processed them. The live dashboard preview shows whether YouTube is receiving a visible result. Neither observation replaces the other: an output that looks plausible locally does not prove the ingest preview is moving, and a dashboard connection does not show which command setting caused a blank picture.
A simple record of checkpoints makes the comparison easier:
| Checkpoint | What to look for | If video is absent |
|---|---|---|
| FFmpeg input listing | Video: under the intended input |
Check the source, selected device or input options |
| Stream mapping | Intended input video leads to output video | Review -map, input indices and filter labels |
| Encoder log | Video encoder initialises and processes frames | Check build availability and accepted format or dimensions |
| YouTube live preview | Moving picture appears with the planned audio | Recheck output and ingest settings; do not infer from audio alone |
Write down what you observe at each checkpoint and avoid changing several categories at once. If the input listing has no video, dashboard adjustments are unlikely to address the source. If input video is present but mapping omits it, an encoder-format change is premature. If mapping and encoding proceed yet the preview remains blank, concentrate on the output and ingest path and verify against current YouTube documentation.
For a channel intended to run continuously, a repeatable test is more useful than a quick glance. Test with a short representative source before switching to a long-running schedule, and confirm both movement and audio in the preview. If you are deciding whether to keep operating a local computer or use a hosted arrangement, the guide to setting up an always-on stream with a hosted streaming service covers that separate operating decision. It does not replace resolving an FFmpeg video-path fault.
Gather the details needed for a precise fix
Without the actual command and log, the correction remains conditional. If you ask someone to diagnose it, share the FFmpeg command with the YouTube stream key removed, the FFmpeg version and build information, and the relevant log lines. Include every Input #... listing, the Stream mapping: section, and any video encoder or output errors. Keep input names if they help identify the source, but remove credentials and private URLs.
Also say whether the source is a file, capture device or another input; whether you use -map or -filter_complex; and whether the output copies video or encodes it. Describe exactly what the YouTube live preview shows during a test with movement. These details distinguish an absent source stream from a mapping omission, an encoder failure or an ingest mismatch.
Do not post a stream key in a public forum or screenshot. If it has already been exposed, follow YouTube’s current guidance for managing the key. Preserve the unedited log before trimming it for sharing, since a line that looks incidental can identify the input index or the point where the video path stops. A diagnosis based only on “audio works” cannot safely choose among these branches.
If keeping the computer running and recovering a dropped broadcast is itself becoming the operational problem, StreamNeo can take the uploaded video and keep the YouTube broadcast running while your own computer is off; that addresses the burden of operating the stream, not a claim that YouTube ingest is healthy or that an FFmpeg command is repaired. It is YouTube-only, so first make sure the file and channel are ready for that workflow.
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 can I hear audio if FFmpeg is not sending video?
Audio and video are separate streams and can take different paths through the command. FFmpeg may have opened an audio-only input, mapped audio but not video, or encountered an error at the video encoder. Check the input listing first, then mapping and encoder messages.
Should I add -map 0:v:0?
Only if the log confirms that the intended video is stream 0:v:0 on input 0 and that this is the output you want. Explicit mapping overrides automatic selection for that output, so an unverified stream index can make the problem worse. Check all input listings and the current mapping before changing it.
Does hearing audio in YouTube Studio prove ingest is working?
It proves that an audio path is reaching the preview, not that moving video is arriving. Check the live preview with representative movement and compare it with FFmpeg’s output log. Follow YouTube’s current encoder guidance for the configured ingest route.
What should I share to get help?
Share the command with the stream key removed, FFmpeg version/build details, input stream listings, stream mapping, and any video encoder errors. Include the source type and what the YouTube preview shows during a moving-video test. Without those details, an exact command-line correction would be guesswork.