When an FFmpeg-driven SRS stream fails as one video changes to the next, first check whether the failure begins at that file boundary. If it does, compare the adjacent files and the exact input method before changing SRS or YouTube settings.
A playlist transition can expose differences that are hidden while either file plays on its own. The FFmpeg concat demuxer has specific stream-compatibility requirements; alternatively, SRS documents a script-based approach that publishes files one by one. Neither approach guarantees a seamless transition, so test against your actual files and logs.
Locate the failure at the file change
Write down the time the stream stops advancing or begins showing a spinner, then compare it with the point where FFmpeg should move from one file to the next. A problem that recurs at the same boundary is a useful clue: it directs attention to the next input, stream compatibility, and duration metadata. It does not prove which of those is responsible.
The phrase “spinning wheel of death” appears in one FFmpeg-user discussion about playlist streaming. That report is a useful description of a symptom, not evidence that this failure is common or that every spinning player has the same cause. Your own timeline and logs matter more than a description from another setup.
Check whether the outgoing file plays normally up to its end, whether FFmpeg reports trouble while opening or reading the next file, and whether the stream recovers if you restart it on a single file. Note the file names and local times for a successful and a failing transition. For a channel that plays multiple music videos, this guide to continuous video playlists can help distinguish the broader playout design from this particular boundary fault.
Also confirm how the playlist is being read. A text file supplied to FFmpeg’s concat demuxer is not interchangeable with an HLS .m3u8 playlist; the file extension alone does not identify the input method. Look at the command’s input options and the format FFmpeg identifies in its output. This matters because the relevant compatibility checks depend on the method actually in use.
If the stream does not fail at a repeatable boundary, widen the investigation. Network interruptions, publishing configuration, or an issue further along the path may need checking. Do not assume that a visible player spinner identifies FFmpeg as the failing component.
Capture the FFmpeg error and timing
Keep the full FFmpeg command, version information and output around the failure. A short fragment copied after restarting may omit the earlier line that says which file was being opened, or whether FFmpeg encountered a stream, timestamp or demuxing error. Preserve the output from just before the transition through the point where publishing resumes or stops.
Record a simple timeline: the current file, expected next file, time of transition, first unusual FFmpeg message, and what the viewer saw. Include whether the output stream continued to be published, rather than treating the viewer’s screen as the only evidence. If you use SRS between FFmpeg and YouTube, check the SRS logs for the same interval to see whether it continued receiving the RTMP input. This separates a read failure in FFmpeg from a publishing problem or a symptom visible only at YouTube playback.
Do not edit several parts of the chain at once. First reproduce with the original files and note the behaviour. Then, if practical, try the outgoing and incoming files separately using the same publishing path. If each works alone but a transition fails, that narrows the search without proving the concat demuxer is at fault. A repeatable boundary-specific error is stronger evidence than a single interrupted viewing session.
The FFmpeg project’s concat demuxer and options documentation describes the demuxer’s rules and how durations affect timestamp placement. Read the part relevant to the input method and version you run; the rolling documentation may differ from the build on your machine. For the RTMP side, SRS’s v4 ingest documentation describes an archived version’s file-ingest workflow. Treat it as documentation of that version, not confirmation of settings for every current deployment.
If you need another reference for collecting operational details, the FFmpeg bitrate and dropped-frame checks cover useful observations during a live output. Bitrate and dropped-frame symptoms do not by themselves diagnose a file transition, but they can help you tell whether the output changes when the input changes.
Check concat demuxer compatibility
The concat demuxer reads files in sequence and adjusts timestamps, but FFmpeg’s documentation sets a key constraint: all files must have the same streams, including the same codecs and time base. A playlist that mixes files with different stream counts, codec choices or time bases may therefore fail or behave unexpectedly at the transition, even if each item is playable on its own.
Compare the files on both sides of the first failing change. Check which audio and video streams are present, their codecs, and their time bases. A file with video and audio followed by one with an extra stream or a different arrangement may not meet the demuxer’s requirements. Differences in picture size or aspect ratio can also be a reason to investigate the sources and their processing, but do not infer a precise failure cause from those differences alone.
Confirm that you are using the concat demuxer rather than a different concatenation method. FFmpeg’s documented file-list form uses a list of inputs, while other input formats have different rules. The method and options in your command determine which requirements apply. Avoid copying a command from a forum without checking that it matches your FFmpeg version and input type.
Duration metadata is another boundary-specific check. FFmpeg uses each file’s duration to position the next one, and the documentation warns that an incorrect duration can cause artefacts. Inspect whether the listed duration matches the media’s actual duration. The concat format supports a duration directive to override stored duration information, but use that only after verifying the value; an inaccurate override can move the problem rather than resolve it.
A discussion on the FFmpeg-user mailing list describes one transition problem involving files with differing formats, sizes and aspect ratios. The reply points to the concat demuxer’s matching-stream requirement and suggests transcoding to common properties. It is a relevant example, not a controlled test or a universal diagnosis.
Validate media parameters across files
Build a small comparison for the files immediately before and after the fault. You do not need to start by cataloguing an entire archive. Compare the adjacent items first, then check a longer run if you find inconsistent media or if failures recur at several different transitions.
| What to compare | Why it matters at a boundary | What to do with a mismatch |
|---|---|---|
| Number and type of streams | The concat demuxer expects matching streams | Check the actual input method and decide whether to normalise the files |
| Audio and video codecs | Different codecs do not meet the documented same-stream constraint | Prepare compatible copies or test a different publishing design |
| Time base | FFmpeg includes time base among the required stream properties | Compare the values in the metadata and test the transition after correction |
| Duration | FFmpeg uses duration to place the next file | Verify the reported duration; consider an override only when you know the correct value |
| Frame size and aspect ratio | Differences can signal varied source material and may require a consistent output | Choose a target format suited to the channel, then verify the resulting files |
Use a metadata-inspection method that works with your installed FFmpeg build, and retain its output for both files. The research behind this troubleshooting path does not establish one universal probe command or encoding command for every system, so it would be unwise to treat a single command line as safe for all sources. If you ask for help, provide the command, FFmpeg version, relevant playlist entries, the metadata for both adjacent files, and the logs from FFmpeg and SRS around the transition.
Keep a copy of the original files. Make one change at a time and test the same boundary again. If you alter codec, frame size, audio layout and duration handling together, a successful run will not tell you which difference mattered. It may also introduce a new issue that is harder to trace.
Test normalised inputs
When the adjacent files do not satisfy the concat demuxer’s compatibility requirements, create test copies with common properties before concatenation. The aim is not to force every channel into a universal preset. It is to make the inputs consistent with each other and with the publishing workflow you have chosen. The appropriate video dimensions, audio settings and encoding choices depend on the source material and the platform requirements you have checked for your stream.
Start with a small sample: the outgoing item, the incoming item and, if relevant, another file that is known to work in the same playlist. Normalise those copies to the same stream layout and timing properties, then try the transition under the same conditions as the original. Check the output and logs at the boundary, not only whether FFmpeg starts. If the transition behaves differently, repeat the test before converting the full library.
Transcoding takes time and creates another set of files to store and manage. It can also reduce quality, depending on the source and encoding choices. Keep an organised mapping between originals and prepared copies so that future playlist changes do not accidentally mix the two sets. For a devotional channel that adds a newly recorded bhajan video each week, for example, the publishing process should include preparing that new file to match the existing set before it is added to the live playlist.
Normalisation is worth testing when file differences align with the failure and you want FFmpeg to read a compatible sequence. It is not a guaranteed fix for every boundary error: duration metadata, the input method, an SRS ingest issue, or a separate YouTube playback issue may still be involved. If a consistent test set fails at the same point, return to the logs and isolate the stage instead of encoding the archive repeatedly.
Consider sequential publishing through a script and SRS
If your operating model is to publish one file, then start the next as a separate publishing action, SRS documents using a script as the ingest tool to copy files to an RTMP stream one by one. Its documentation says SRS does not directly ingest a file list. This is a documented workflow choice, not evidence that every script will switch files without a gap or that SRS resolves incompatible media.
A script-based approach changes where sequencing happens. Instead of asking the concat demuxer to read a compatible sequence as one input, the script launches or manages publishing for each item through SRS. You need to decide what happens when a file ends, how the next one is selected, what the script does after a publishing error, and how you observe a stalled process. Test those behaviours on the deployment you use; the SRS documentation does not promise gapless switching.
SRS’s ingest documentation describes FFmpeg-based file ingest, including its use of -re for file ingest, and gives examples of publishing to an RTMP endpoint. Those details support the general ingest workflow, but do not establish current YouTube-specific encoder settings or guarantee that an endpoint remains stable. Check the official documentation for the SRS version you deploy and current official YouTube guidance for your account and stream configuration.
| Choice | Fits when | Work to plan for | What it does not guarantee |
|---|---|---|---|
| Concat with compatible, prepared files | You have a stable library and can make inputs match | Check stream layout, codec, time base and duration; prepare new items consistently | A successful transition or uninterrupted viewer playback |
| Script publishing files one by one through SRS | You want sequencing managed as individual file publications | Handle process starts, file selection, errors, monitoring and transitions | Gapless switching or a fix for media incompatibility |
For a fixed loop, normalised inputs may be easier to validate and repeat. For a schedule that changes during the day, sequential publishing may suit the way you update items, provided you are prepared to operate and monitor the script. Neither option is inherently better for every channel. A continuous Marathi bhajan stream workflow is useful background if you are still deciding how a repeating playlist should be organised, while the transition itself still needs testing with your media.
For a non-technical operator whose main difficulty is keeping a computer available and restarting a dropped broadcast, StreamNeo can remove that specific burden by running an uploaded file as a 24/7 YouTube live stream while your own computer is off; it does not make mismatched FFmpeg playlist inputs compatible or replace the checks above.
Choose a test that answers one question
A useful test plan avoids changing the whole channel while viewers are relying on it. If possible, reproduce with a short, private or otherwise appropriate test stream and the two files at the failing boundary. Keep the same publishing route and observe FFmpeg, SRS and playback separately. Follow your normal channel and account settings, and check current official guidance before making changes to a live setup.
Test the original pair first, then test one controlled adjustment: corrected duration, compatible prepared copies, or sequential publishing. Save the command and log output for each run. A successful test tells you that this particular arrangement behaved better under those conditions; it does not prove that all files, future playlist edits or longer sessions will behave the same way.
If the files are compatible and FFmpeg shows no boundary error, look further along the path. Confirm whether SRS continues receiving and publishing after the transition, then determine whether the symptom is confined to YouTube playback. The collected evidence here does not cover current YouTube ingest requirements, account configuration or the health of a specific connection, so consult the current YouTube Live Help for platform-side checks rather than inferring an approval or connection outcome from a local log.
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 spinning player mean the concat demuxer failed?
No. A spinner is a viewing symptom and does not identify the failing stage. Check whether FFmpeg logs an error as it reaches the next file, whether SRS continues receiving the RTMP input, and whether the symptom occurs only at playback.
Can I fix every playlist transition by normalising the files?
No single fix applies to every boundary failure. Normalising is worth testing when adjacent inputs differ in streams, codecs or timing properties relevant to the concat demuxer; duration accuracy and other stages still need checking.
Will SRS make incompatible files work together?
SRS does not remove the concat demuxer’s compatibility requirements. Its v4 ingest documentation describes a script-based workaround for publishing files one by one, but does not promise seamless transitions or repair incompatible media.
What information should I include when asking for help?
Include the FFmpeg command and version, the playlist entries around the failure, metadata for the outgoing and incoming files, and the FFmpeg and SRS logs from just before and after the transition. Add a timeline of what the viewer saw and whether the RTMP publishing process continued.