First check whether FFmpeg is still producing video after the first file ends. A black screen in the YouTube player does not by itself prove that looping failed: the process may have stopped, lost its video stream, or be sending video that YouTube is not displaying.
Work through the evidence in order: inspect FFmpeg locally, verify the inputs and transition, check stream mapping, then compare the local result with YouTube’s stream status and health messages. Do not change ingest protocols or replace equipment until you know where the picture disappears.
Confirm where the picture disappears
Start by observing the stream at the moment the first video ends. Note whether FFmpeg exits, stays open but stops producing frames, or keeps producing output while the YouTube preview turns black. Also note whether audio continues. These observations narrow the possibilities without committing you to a cause too early.
If the FFmpeg process exits at the transition, investigate input exhaustion, playlist handling and any error immediately before exit. If it stays alive but the output has no video, inspect the next input and the selected streams. If you can verify that local output still contains moving video, shift attention to YouTube ingest and stream health rather than changing the loop setting at random.
Audio is a useful clue, though not a diagnosis on its own. Audio continuing while the image disappears can point towards a missing or unselected video stream; both audio and video stopping can indicate that the input ended or the output stalled. A player can also appear black while its preview catches up, so compare more than one observation before deciding.
Before editing anything, save the exact FFmpeg command, the playlist or input list, the FFmpeg version and a log that covers the transition. Redact the YouTube stream key before sharing a command or log. Record whether FFmpeg exits and whether audio continues; those details often matter more than the viewer-facing symptom.
Check FFmpeg output locally
The first test is whether FFmpeg itself continues to emit video after file one. Check process status and the log around the transition for frame or packet progress, warnings, errors and an orderly end-of-file message. A process that remains open is not proof that it is producing a usable video stream.
Where practical, make a local recording or preview of the output during a controlled test. Confirm that it has a picture after the transition, not just that the command is still running. If the local output is black or has no video frames, YouTube cannot display picture that FFmpeg did not send. Resolve that source or output issue before investigating ingest.
Keep separate notes for the process, audio and video. For example, “process alive, audio continues, no video frames after the transition” is more actionable than “stream went black”. Likewise, “process exits at end of file one” points to a different branch than “local output has video, but YouTube preview is black”.
If you cannot capture a local preview, use the available logs and a short local run to establish what FFmpeg is emitting. Avoid publishing a live test with a private stream key embedded in a screenshot or command. A useful baseline is a command with the key replaced by a placeholder, the input names visible, and timestamps around the transition included.
The broader live stream setup guide can help you identify the role of the encoder, source and output settings, but for this symptom keep the question narrow: does the outgoing video continue past the first file?
Verify the input sequence and loop behaviour
Next inspect how FFmpeg receives the files. Check that the second filename exists at the path the command expects, that spaces and special characters are quoted correctly, and that the input order is the one you intend. A playlist can end early or fail to advance even when the first file plays cleanly.
Looping is an input setting, not a general guarantee that every item in a multi-file sequence will repeat as intended. FFmpeg documents -stream_loop as taking a number of input repetitions: 0 means no looping and -1 means infinite looping. Confirm that the option is attached to the particular input you want repeated. The FFmpeg documentation describes this option and its placement as an input option.
For a single source intended to repeat indefinitely, -stream_loop -1 may be relevant. It is not a universal prescription for a playlist of several different videos. A loop on the wrong input, a playlist that ends before it reaches the intended repeat, or a transition method that cannot accept the next file can all produce different symptoms. Inspect the actual command and input structure before changing it.
Also distinguish repetition from pacing. FFmpeg’s -re reads an input at its native frame rate, equivalent to -readrate 1; it does not repeat a file that has ended. For prerecorded files sent as a live feed, check whether real-time pacing is needed as well as a valid repeat or playlist strategy. Do not add flags simply because the word “live” appears in the task: first establish what the current command is doing.
For multiple inputs, verify each source independently and then test the sequence. Confirm that the following file opens and has a video stream. If the transition fails only between particular files, note their formats and stream layout for diagnosis; do not assume that copying streams or choosing a particular concat method is valid without inspecting those files.
A playlist-focused example may help clarify the difference between rotating a sequence and looping one file: see how to rotate YouTube livestream playlists without repeating the opening video. The point is not to transplant another command unchanged, but to compare its sequence logic with yours.
Check video and audio stream mapping
A sequence can open successfully and still produce the wrong output if stream selection changes at a transition. Inspect the source files for the presence of video and audio, then inspect the output mapping to make sure the intended video stream is selected. Do this for the first file and the file that follows it, not just for the opening segment.
Mapping matters especially when sources have different layouts: one may contain a video track and multiple audio tracks, while another may have a different order or no audio at all. A mapping that works with the first input does not necessarily establish that later inputs are compatible with the same output. Check FFmpeg’s log for the selected streams and for any warning or error when the second input is opened.
Keep the evidence simple. Does the source file have a picture when played on its own? Does FFmpeg report a video stream for it? Does the output continue to include video after the transition? Does audio continue independently? Answering those questions can distinguish a source problem from an output selection problem without assuming that a particular -map expression is right for every command.
Do not switch to stream copy, re-encode, or a different concat approach as a guess. Those choices depend on the inputs, their stream properties and the command. First determine which source and output streams exist, then make one controlled adjustment and test the same transition again.
Compare output with YouTube stream health
If FFmpeg continues to produce valid local video, check the YouTube side. Confirm that the command uses the intended ingest address and stream name, and review the live control room’s status and health messages at the time of the black screen. YouTube’s LiveStreams API distinguishes states such as active, error and inactive; an active state is evidence to consider, not a promise that every viewer is receiving a picture.
YouTube’s encoder guidance recommends monitoring stream health and testing the conditions you plan to use. It says, “Tests should include audio and movement in the video similar to what you'll be doing in the stream.” See YouTube’s encoder settings and stream-health guidance. A static title card alone may not reveal whether motion behaves correctly through the transition.
Compare timestamps: when did FFmpeg last show video output, when did the preview turn black, and what did YouTube report at that point? If local video stopped first, keep working on the FFmpeg side. If local video continued but YouTube reported an ingest or health error, investigate the reported issue and the configured destination. If the status appears active but viewers see black, capture the local evidence and status messages rather than inferring that the ingest is healthy in every respect.
YouTube recommends RTMPS for YouTube Live, but that recommendation is not evidence that a black screen after one video is a protocol fault. Do not change protocol simply because the symptom is alarming. First establish the protocol in use and check the local output and YouTube messages. HLS has its own documented rules, including a media playlist, muxed audio and video, HTTPS and a single encoded stream; apply those only if you are actually using HLS. The YouTube HLS ingestion guide is specific to that workflow.
Test with a short repeatable sample
Once you have a working hypothesis, test it with a small sequence that reproduces the same transition. Use representative gaming footage with movement and audio, and include the first-to-second-file hand-off that previously failed. A short test is easier to inspect than waiting through a long rerun, but it should still exercise the condition that caused trouble.
Keep the output destination controlled. You can first test locally to see whether FFmpeg retains video; then use an appropriate private or unlisted YouTube test if you need to observe ingest behaviour. Check the current YouTube settings and audience implications before publishing a test. Do not expose your stream key, and do not treat a successful opening segment as evidence that the later transition works.
Change one thing at a time. If you alter the playlist, mapping and ingest protocol together, a successful test will not tell you which change mattered, while a failure will leave you with more variables. Write down the command before and after each change, along with the transition timestamp and what happened to process state, audio, local video and YouTube health.
If you run reruns on a computer that also needs to remain available for other work, consider the operating burden separately from this diagnosis. For example, how to run a 24/7 lofi radio stream on YouTube with OBS discusses a different tool and use case, but the practical lesson is to test the complete unattended hand-off rather than only the first few minutes.
Apply the fix and verify the next transition
Apply only the change supported by what you observed. If FFmpeg exits when a single intended-repeat input reaches its end, verify the input loop option and placement. If a playlist points to a missing or wrongly quoted file, correct the path or sequence. If video is absent from the selected output after a transition, inspect the source streams and mapping. If local video continues while YouTube reports an ingest problem, use the relevant YouTube status and health message to guide the next check.
Then test the same transition again. Verify that the FFmpeg process remains in the expected state, video continues in the local output, and audio behaves as intended. Compare the YouTube preview and health messages as well. Keep the test running far enough to establish that the next transition, not merely the initial playback, behaves correctly.
For an always-on channel, a laptop that sleeps, a command window that is closed, or a local machine that loses power can create a separate interruption even after the first-video problem is fixed. If the particular pain is leaving a computer running all night, StreamNeo can remove that operational burden: you upload the file once and provide your YouTube stream key, and the broadcast runs with your computer switched off. That does not diagnose or guarantee a repair for this FFmpeg issue; test the source and channel first, and choose a workflow that fits your need for a changing playlist versus a single uploaded video.
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 a black screen after the first video mean -stream_loop is missing?
Not necessarily. A missing or misplaced loop option is one possibility, but the process could have exited, the next playlist entry could be unavailable, stream mapping could have changed, or YouTube could be reporting an ingest problem. Check local video output and the transition log before deciding.
What should I check first if audio continues but the picture is black?
Check whether FFmpeg is still emitting video frames and whether the local output contains a picture. Then verify that the next source has a video stream and that the output mapping selects it. Continuing audio narrows the investigation, but does not prove the cause.
Should I change RTMP or HLS settings to fix it?
Only investigate protocol-specific settings after identifying the ingest method and reviewing local output and YouTube health. YouTube recommends RTMPS for Live, while its HLS requirements apply to HLS workflows specifically. A black screen alone is not a reason to change protocol.
What information should I include when asking for help?
Share the FFmpeg version, a redacted command, the input or playlist sequence, and a log covering the first transition. State whether FFmpeg exits, whether audio continues, whether local output still has video and what YouTube’s stream status or health message showed; never include the stream key.