To stream a pre-encoded H.264 playlist to YouTube without re-encoding, use FFmpeg’s concat demuxer to read compatible files in order, pace the input in real time, and send the resulting stream with -c copy. This preserves the compressed video and audio streams; it does not make mismatched files compatible or change their settings.
The important work happens before you start FFmpeg: check every file’s streams and timing, prepare the playlist manifest, and compare the existing encoding with YouTube’s current ingest guidance. If the source files are not a suitable match, prepare compatible media first rather than expecting copy mode to repair them.
Check playlist compatibility before choosing copy mode
The concat demuxer presents a sequence of files as one input to FFmpeg. It is useful when those files were prepared to fit together, not as a general-purpose way to join arbitrary videos. FFmpeg’s concat-demuxer documentation requires the files to have the same streams, codecs and time bases. Its timestamp adjustment also relies on each file’s duration, so inaccurate duration metadata can cause gaps, overlaps or other boundary artefacts. See the concat demuxer requirements before building the list.
Inspect every segment, not just the first and last. Check that the video and audio stream layouts match, and compare codec, time base, resolution, frame rate and audio properties. A pair of files can both contain H.264 video while still differing in ways that matter to the sequence. Matching names or extensions are not evidence that their encoded streams are compatible.
The distinction is especially important for copy mode. A command using -c copy copies compressed streams without decoding and re-encoding them. That saves the encoding step, but leaves the existing stream properties intact. It cannot change frame rate, bitrate, resolution, keyframe spacing, or audio codec. FFmpeg describes stream copy as copying streams without re-encoding in its codec documentation.
A practical example is a devotional channel with several H.264 segments intended to run one after another. If their stream layout and timing properties match, a concat manifest and copy mode may suit the job. If one segment has a different frame rate or audio format, copy mode will not harmonise it with the rest. Prepare a compatible set of files, or choose a workflow that re-encodes as needed.
For a broader operating context, see this guide to starting a continuous YouTube news stream with recorded clips in India. Its use case differs, but the same practical question applies: are the recorded files ready to behave as one continuous programme?
Build a concat-demuxer file list
Create a plain-text manifest in playback order. For automatic format recognition, its first line must be exactly ffconcat version 1.0. Follow it with one file directive for each segment, for example:
ffconcat version 1.0
file 'part-001.ts'
file 'part-002.ts'
file 'part-003.ts'
Save the file as UTF-8 or plain text, and check that the paths actually point to the media. Relative paths are easier to review and keep portable when the playlist and its media are together. Quote or escape characters in file names according to the concat file syntax; do not assume a shell’s quoting rules apply inside the manifest.
FFmpeg’s safe mode is on by default. It accepts only safe paths, which are deliberately restrictive: among other conditions, paths should be relative, use portable characters, avoid protocol specifications and not begin with a dot component. If your trusted local file paths require broader forms, -safe 0 disables that check. Use it only when the manifest and paths are under your control; do not use it to load an untrusted list. The safe-path rules explain what FFmpeg accepts.
Here is the essential shape of the input options when using a manifest that needs safe mode disabled:
-f concat -safe 0 -i playlist.ffconcat
The example is only the input portion of a command. Keep the manifest beside the files where practical, and test that FFmpeg can open the complete sequence before connecting to YouTube. A manifest that opens successfully still does not prove every transition has accurate timing or compatible media properties.
The concat demuxer is not the same as joining unrelated MP4 or MKV files and hoping their containers make them one clean playlist. It reads each listed input and constructs a sequential timeline. If duration values are unreliable, the demuxer’s timestamp adjustments can lead to problems at transitions. Inspect the source metadata and playback around each boundary when a sequence behaves unexpectedly.
Pace file input in real time
A file can be read much faster than its normal playback rate. When sending a file to a live destination, that can mean FFmpeg attempts to deliver the programme faster than the intended duration. Place -re before the input options to read the file at its native rate:
-re -f concat -safe 0 -i playlist.ffconcat
FFmpeg documents -re as equivalent to setting the input read rate to one, and notes its use where packet flow speed matters, such as live streaming. It is a pacing option; it does not alter the encoded frame rate. A 30 fps source remains encoded at 30 fps, while FFmpeg reads its packets at the expected playback pace. See FFmpeg’s input options.
Option order matters. In this pattern, -re applies to the file input, so put it before -i. Do not apply a low read rate indiscriminately to a camera or another genuine live capture input: FFmpeg cautions that slowing such an input can result in packet loss. For a stored playlist, real-time pacing is the relevant case.
Before relying on a long sequence, run a short representative test. Include a transition between two segments, moving picture, and the audio you expect viewers to hear. Observe whether playback proceeds at normal pace and whether a boundary produces a pause or abrupt change. A file-reading command can be syntactically valid while a bad source duration or an unintended gap remains audible.
If your goal is to keep an always-on playlist running, consider what happens at its final segment as well. The concat list describes a sequence; it does not, by itself, promise that FFmpeg will repeat it indefinitely. For a gap-free loop, see the separate guide on looping a video on YouTube Live without a gap or black frame, and test the actual transitions in your chosen workflow.
Use stream copy for compatible encoded streams
Once the files match and the list is ready, the core command pattern is:
ffmpeg -re -f concat -safe 0 -i playlist.ffconcat \
-map 0:v:0 -map 0:a? -c copy -f flv \
"$YOUTUBE_RTMPS_URL/$YOUTUBE_STREAM_KEY"
This pattern selects the first video stream and maps audio if present, copies the selected streams, and uses FLV as the output muxer. The optional audio mapping (-map 0:a?) allows the command to proceed if the input has no audio stream. If you know the playlist is silent, you can omit the audio map. Confirm that the output muxer and RTMPS URL syntax fit the URL supplied by YouTube and the FFmpeg build you are using; treat this as a pattern, not a guaranteed invocation for every environment.
Do not add -c:v libx264, scaling, frame-rate conversion, filters or audio re-encoding if you intend strict stream copy. Those operations process or replace the stream rather than copying it unchanged. Conversely, leaving them out means the input’s settings stay as they are. If the source does not meet YouTube’s requirements or recommendations, copy mode does not provide a way to fix that mismatch.
Keep the stream key private. It is a credential, not a descriptive channel label. Avoid putting it in a public script, shared screenshot, visible terminal recording or logs that other people can read. Use a suitably protected way to supply it in your environment, and check the command history and logs you plan to retain. The pattern above uses environment variables as placeholders so the key itself does not need to appear in a shared example.
For more on keeping a pre-recorded YouTube broadcast running, this article on restreaming old videos to keep your channel live addresses the wider operating choice. The FFmpeg method is most suitable when you are comfortable maintaining the local files, command and sending computer; a process that depends on your computer also depends on that machine and its network staying available.
Get YouTube’s current ingest details
Create or schedule an encoder stream in YouTube Studio’s Live Control Room, then obtain the ingest URL and stream key from the stream settings. Prefer RTMPS where your FFmpeg build supports it. YouTube describes RTMPS as RTMP carried over TLS/SSL; use the exact URL YouTube supplies rather than copying a remembered endpoint from another setup. Its RTMPS guidance explains the protocol and connection checks.
YouTube’s current live encoder settings give recommended H.264 bitrates by resolution and frame rate. Match the recommendation to the file you already encoded, not to a different setting you wish it had. The table below reproduces the published recommendations; these are ingest targets, not a promise that a given connection can sustain them.
| Video format | Recommended H.264 bitrate |
|---|---|
| 720p at 30 fps | 8 Mbps |
| 720p at 60 fps | 8 Mbps |
| 1080p at 30 fps | 14 Mbps |
| 1080p at 60 fps | 17 Mbps |
| 1440p at 30 fps | 21 Mbps |
| 1440p at 60 fps | 34 Mbps |
| 2160p at 30 fps | 42 Mbps |
| 2160p at 60 fps | 50 Mbps |
The same YouTube guidance recommends constant bitrate, keyframes every two seconds and no more than four seconds apart, video up to 60 fps, and AAC or MP3 audio. For stereo audio it recommends a 44.1 kHz sample rate and 128 kbps audio bitrate. Confirm the current official page before a broadcast, because encoder guidance can change.
In copy mode, those recommendations are checks against the files, not knobs the command can adjust. If the existing H.264 stream uses an unsuitable bitrate or keyframe interval, -c copy will preserve it. If audio is not AAC or MP3, copying will not turn it into either format. When a source misses a target, the honest choices are to make a compliant source file or to use an encoding workflow that changes the relevant property.
Start the stream and verify output
Run the command only after checking the manifest, the source streams and the URL/key. Watch the Live Control Room preview rather than assuming that an FFmpeg process with no immediate error is enough. Confirm that the picture is visible, audio is present when expected, and YouTube’s stream health messages do not indicate a problem. YouTube recommends testing with representative movement and sound before an event.
For a scheduled stream, the preview and the public event are separate steps. Wait for YouTube to receive and display the preview, review the stream status, and use the Live Control Room’s Go live control where the workflow requires it. When you finish, end the event in the control room as appropriate and stop FFmpeg. YouTube says streams under 12 hours are automatically archived, but check the current workflow and archive status for the event you are running.
A useful test is not merely a few seconds of the first file. Include enough time to observe a segment boundary, check that the audio does not disappear, and verify that the source’s timing is plausible. If your channel mixes programme types, test the sort of transitions viewers will actually encounter. A clean preview at the start says little about an untested join later in the playlist.
Keep an eye on the sending computer and network for the duration of a local FFmpeg broadcast. Copy mode removes the encoding workload, but it does not remove the need to deliver packets continuously or keep the process running. For an account of the different operational model when moving a loop away from a local OBS setup, see how to move a YouTube loop stream from OBS to a cloud service. The right choice depends on whether you want to manage the sending process yourself.
When the recurring burden is keeping a computer on and restarting a dropped broadcast, StreamNeo can take that specific task off your desk: it turns an uploaded video into a YouTube live stream that keeps running with your own computer switched off, monitored and restarted automatically if it drops. It is YouTube-only, so it is not a fit if you need to send the same programme to other platforms.
Troubleshoot incompatible media or settings
If the playlist will not open, check the manifest’s first line, file order, path quoting and safe-mode setting. The header must be exact for automatic recognition. If you used -safe 0, confirm that the manifest and all referenced paths are trusted local files. Check that each path resolves from the directory where you launched FFmpeg, rather than the directory where you happen to keep the script.
If only the first file plays or the transition has a timing artefact, compare all stream layouts, codecs and time bases again. Check the stored durations as well: the concat demuxer uses the preceding file’s duration when adjusting timestamps for the next one. Incorrect duration metadata can move a boundary. Do not try to conceal a mismatch with copy mode; identify the file that differs and prepare compatible media.
If playback races ahead, check that -re is before the input declaration. If the video appears but the audio does not, check whether the files contain audio, whether the optional audio map selects it, and whether the audio format is suitable for the destination. An absent audio stream and a wrongly mapped or unsupported stream are different problems.
If YouTube reports an ingest or quality warning, compare the existing video and audio properties with the official settings: bitrate recommendation for the actual resolution and frame rate, keyframe spacing, constant bitrate guidance, frame-rate limit, and audio format. Copy mode preserves these properties; it cannot change frame rate, bitrate, resolution, keyframe interval, or codec. Re-encode or prepare another source when a setting needs to change.
For a connection or certificate error, verify the exact RTMPS URL from Live Control Room, that the installed FFmpeg supports RTMPS, and that the network permits the connection. YouTube’s RTMPS troubleshooting guidance includes checking the protocol and URL, port, and RTMPS support. Do not substitute a URL from an old command without checking the current stream settings.
If there is no preview, confirm that FFmpeg is sending to the matching URL and key and inspect the status in Live Control Room. Check that the stream key belongs to the active scheduled stream, not a different event. Avoid pasting the key into public support posts while seeking help; share redacted command output instead.
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 FFmpeg stream an H.264 playlist without re-encoding?
Yes, when the files meet the concat demuxer’s matching-stream requirements and the output path accepts the copied streams. Use the concat demuxer, real-time pacing for file input, and -c copy. It preserves the encoded streams rather than correcting their properties.
Can stream copy fix a frame-rate or bitrate mismatch?
No. Stream copy cannot change frame rate, bitrate, resolution, keyframe spacing or audio codec. If the source does not meet the requirement you need, prepare a suitable encoded file or use a workflow that re-encodes it.
Why use -re with a file but not a live capture input?
A stored file can be read faster than playback, so -re paces its input at the native rate for a live destination. FFmpeg cautions against using low read rates on actual live inputs because they may cause packet loss. Apply the option to the file input in this playlist pattern.
Does the concat demuxer loop the playlist forever?
No. A concat manifest lists files in sequence; it does not by itself ensure that the sequence repeats. If you need a continuous loop, choose a workflow designed for repeat playback and test the transition between the last and first items.