For a YouTube gaming VOD rerun, use FFmpeg’s concat demuxer with stream copy only when the files have compatible streams and trustworthy timing metadata. If the files need filters or technical normalisation, use the concat filter and re-encode; neither approach guarantees an artifact-free boundary without testing the actual clips.
The -re option can pace file input at its native rate for a live output, but it does not fix transitions. Treat concatenation, live pacing and YouTube’s separate Live Redirect feature as three different jobs.
Inspect the VODs before choosing a method
Start by checking what is in each file, rather than relying on names or extensions. Two .mp4 files may still differ in video or audio codecs, stream count, time base, frame cadence or audio layout. The extension describes a container, not a promise that the streams inside are suitable for packet-level joining.
Use a media inspection tool such as ffprobe to list each file’s streams, codec details, time bases, duration and start-time information. Compare the results side by side. Look at whether a clip has one audio stream while another has two, whether a segment has subtitles or data streams that the others do not, and whether durations appear precise or estimated. A file that starts at a non-zero timestamp or has a truncated ending deserves particular scrutiny.
The concat demuxer presents packets from a sequence of files as though they were part of one input. FFmpeg’s documentation says the files must have the same streams, codecs and time base. That is a stricter test than “they are all MP4s”. See the official concat demuxer documentation for its requirements and playlist syntax.
Make a small inventory before building a long rerun: file name, video and audio streams, relevant codec and timing details, duration confidence, and any known edit at the head or tail. This helps you decide whether a mismatch is harmless for your output or requires a decode-and-encode workflow. If you are building a long sequence, the practical organisation advice in how to organise a continuous recorded lesson stream also applies: keep an intentional playback order and know which source file follows each one.
Use the concat demuxer when stream copy fits
If your VOD segments have matching streams and sound timing metadata, try the concat demuxer with -c copy. Stream copy passes selected packets through without decoding or encoding, so it avoids a generation step and can reduce processing demand. It also means FFmpeg cannot apply filters or transform the copied streams to make them match.
Create a plain-text playlist with one file directive per input, in the order you want them played. For automatic recognition of the format, the exact first line should be ffconcat version 1.0, with no leading blank line, extra space or byte-order mark. A short example is:
ffconcat version 1.0
file 'vod-part-01.mp4'
file 'vod-part-02.mp4'
Then, for a joined file you can inspect before using it as a live source, an illustrative command is:
ffmpeg -f concat -safe 0 -i playlist.ffconcat -c copy joined.mp4
This is a pattern, not a universal command for every input or streaming destination. Use -safe 0 only when needed for a playlist you control, such as one containing paths outside the demuxer’s safe-path rules. Be careful with quoting and escaping paths containing spaces or special characters; follow the playlist rules in FFmpeg’s documentation rather than assuming shell quoting will work inside the file.
The demuxer adjusts timestamps so the first file starts at zero and later files are positioned after earlier ones using their durations. That makes duration metadata important. If a stored duration is wrong, timestamps for subsequent material may be misplaced and an artifact can appear at a join. The playlist supports a duration directive to override a stored value, but use it only when you have a reliable corrected duration. Guessing a value to suppress a warning can move the problem rather than solve it.
Streams within a file that have different lengths can also produce gaps when the next file is positioned. A video stream ending before its audio, or the reverse, is worth checking at the boundary. Stream copy is most useful when it is genuinely appropriate; it is not a repair mode for mismatched clips. For another FFmpeg-based continuous playback example, the guide to a recorded church worship set shows why the transition itself deserves attention, not just the command line.
Re-encode with the concat filter when normalisation is needed
Choose the concat filter when the files need decoding, filtering or normalisation before they can form one consistent output. This is the path to consider when streams differ in ways you need to reconcile, or when you want to apply transformations such as scaling, padding, audio adjustment or frame-rate handling. FFmpeg’s FAQ recommends the concat filter for cases requiring re-encoding and the demuxer when you want to avoid a re-encode.
The trade-off is additional processing and an encoding step. You must decode the inputs, bring them into a deliberate common format, then encode the result for your chosen output. The particular filter graph and encoder settings depend on the actual files and delivery target; there is no universal set of values that can be responsibly prescribed for every gaming VOD. Consult the FFmpeg concat FAQ and test a short output before committing to a full schedule.
Normalisation can address technical differences, but it does not rewrite the edit. If one VOD ends with a menu screen and the next begins mid-match, the visual cut may still feel abrupt even if both have matching output settings. A quiet tail in one recording followed by a loud opening in another remains a content and audio-level transition to assess. Likewise, different frame cadence or stream duration can still make the result feel uneven if your filter choices do not handle them intentionally.
Do not switch to re-encoding simply because a join has not yet been inspected. First determine whether the issue comes from incompatible streams, duration metadata, unequal audio and video lengths, or the original edit. If you are weighing a local FFmpeg workflow against another playback workflow, the comparison of OBS and FFmpeg for continuous archive streaming can help frame the operational trade-offs without changing the technical requirements of your source files.
| Decision | Concat demuxer with stream copy | Concat filter with re-encoding |
|---|---|---|
| Best fit | Compatible streams and a desire to avoid re-encoding | Inputs need filters or normalisation |
| Processing | Copies selected packets without decoding or encoding | Decodes and encodes as part of the workflow |
| Can apply filters | No, not to copied streams | Yes, as part of a filter graph |
| Main boundary concern | Duration accuracy, stream lengths and source edits | Normalisation cannot make an awkward source edit seamless |
| First check | Compare streams, codecs and time bases | Decide how each input should be made consistent |
Pace file playback at its native rate
For a file used as a live source, FFmpeg’s -re option reads input at its native frame rate, equivalent to -readrate 1. This is useful when output packet speed matters, such as sending a file to a live streaming destination. It controls how quickly input is read; it does not affect whether the last frames of one file meet the first frames of the next cleanly.
Keep the distinction clear while testing. If a file is fed to a live endpoint as quickly as the machine can read it, the output may not behave like real-time playback. Native-rate pacing addresses that rate mismatch. It will not correct a false duration, unify a video codec, equalise audio layouts or hide an edit that cuts in the middle of an action.
A practical workflow is to validate a short concatenated sample first, then test the same source with the pacing behaviour intended for the live run. Observe the output for the whole sample, including the transition. Do not infer boundary quality from a command finishing successfully or from a locally joined file that has not been watched and heard.
Set the YouTube Live output separately
Concatenation describes how FFmpeg presents or combines media inputs. YouTube Live output is a separate part of the setup. Before broadcasting, confirm the destination stream configuration and the output format expected by your current YouTube workflow. Do not borrow a universal bitrate, resolution, keyframe interval or audio setting from a different channel’s example: the available research here does not establish one setting for every source and destination.
Keep the output decision distinct from the input decision. A stream-copy join can still require an output setup that matches the live destination, while a filter-based pipeline can still be configured incorrectly for that destination. Check the current YouTube Live encoder settings documentation for YouTube’s requirements, and use settings that your source material and connection can sustain. A locally successful file is not proof that the live endpoint will accept or display the output as intended.
For a 24/7 rerun, also plan what should happen when the source sequence ends or a broadcast drops. If your current workflow depends on a computer staying on and someone noticing failures, that is an operational risk separate from codec compatibility. StreamNeo can remove that particular overnight burden by taking an uploaded video and stream key for a YouTube-only broadcast that continues with your computer switched off and is monitored and restarted if it drops. That does not validate the source files or make their joins seamless; inspect the media and live output first.
Test the actual boundaries
A successful concat command proves only that FFmpeg processed the inputs in the chosen mode. It does not prove that every boundary is free of a pause, repeated frame, audio gap, click, sudden level change or timestamp jump. Watch and listen across the joins you intend to use, rather than sampling only the beginning of the output.
Test boundaries that differ in character: a quiet-to-loud scene, a clip with a long fade, a segment that ends near a menu or loading screen, and any pair with uncertain duration metadata. Check the last moments before a join as well as the first moments after it. Listen for abrupt changes in game audio and voice chat, and look for black frames, frozen images, unexpected jumps or a delay between sound and picture.
When a problem occurs, narrow down which layer is responsible. Compare the joined output with the original tail and head. Recheck per-stream durations and timestamps; if the demuxer placed the next file using a bad duration, a trustworthy override may be relevant. If streams do not match, use an approach that can decode and normalise them. If the cut is already abrupt in the source recordings, editing or replacing the source boundary may be the right fix. Changing -re is not a boundary repair.
Finally, test the exact output path you plan to broadcast, including the live destination where practical. A joined local file and a live encode can behave differently because the latter adds pacing and an output stage. Keep a record of which file pair caused an issue and what changed, so a later edit or replacement does not quietly bring it back into the overnight sequence.
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
Can I use -c copy when my gaming VODs have different settings?
Only if the relevant streams are compatible for the concat demuxer; a shared container extension does not establish that. Stream copy cannot decode, filter or reconcile mismatched codecs, time bases or stream layouts, so use a re-encoding workflow when those differences need normalisation.
Why does FFmpeg concat leave a gap between files?
The demuxer positions each file using duration information, and inaccurate durations can affect later timestamps. Streams within an input that have unequal lengths can also leave gaps; inspect the actual boundary and use a corrected duration only when you know it reliably.
Does -re make an FFmpeg stream play in real time?
It reads file input at its native frame rate, which is useful for live output pacing. It does not improve transition quality, fix timestamp metadata or make a source edit smoother.
Can YouTube Live Redirect make a concat seamless?
No. Live Redirect is a separate YouTube Studio feature for sending viewers from an ending live stream to a Premiere or another live stream, subject to YouTube’s current eligibility and permission requirements. It does not join files inside an FFmpeg stream or remove a gap at a VOD boundary.