Yes. You can send YouTube a 4K, 60 fps live feed built from a playlist with FFmpeg’s concat demuxer, provided the files are compatible or have first been converted to a common format.
That describes the feed you send, not a promise that every viewer will watch 4K60. YouTube processes live video into formats suited to playback, and what is available or selected can vary; there is no fixed lower-resolution ladder to assume for every stream.
YouTube processes the feed you send
A useful way to plan the workflow is to separate three stages: prepare the files, assemble them into a continuous input, then encode and send that input to YouTube. The concat demuxer handles the middle stage. It does not turn unrelated clips into 4K60 media or make a poorly matched live encoder configuration correct.
Once YouTube receives a live stream, it transcodes it into multiple formats so viewers with different devices and network conditions can watch. This is why a channel owner can send a high-quality 4K60 signal without expecting each viewer to receive those same dimensions and frame rate. YouTube chooses playback options; your job is to provide a valid, stable incoming feed and check how the stream is being received.
For a recorded study channel, for example, you might assemble several prepared lessons into one long live feed. The same basic file-playlist idea appears in a guide to building a 24/7 coding study stream from recorded videos, but a 4K60 target adds stricter demands on source consistency, encoding and upload capacity.
YouTube’s live encoder settings describe supported ingestion protocols and encoder guidance. Treat that as the current source of truth rather than relying on a command copied from a different YouTube interface, codec or FFmpeg build.
What 4K60 means for the incoming feed
In this workflow, 4K60 means your outgoing live signal is encoded at 2160p resolution and 60 frames per second. It does not mean that the original files must already be 4K60 if you plan to re-encode them, but converting lower-resolution or lower-frame-rate material cannot create genuine captured detail or motion that was never present. Upscaling is a format conversion, not restoration.
The distinction matters when choosing between stream-copy and re-encoding. With stream-copy, FFmpeg moves encoded packets without decoding and encoding them again. That is efficient and avoids an extra generation of lossy video, but it cannot resize, filter or normalise mismatched clips. A command-line output option that names a frame rate does not make copied packets conform to that frame rate.
Re-encoding gives you control over the dimensions and frame rate of the output, along with codec, bitrate and keyframe behaviour. The cost is processing load and another lossy encode if your sources are already compressed. If clips differ in resolution, frame rate, codec or stream layout, make a normalised set first, or use a filter-based concat workflow that decodes and encodes the sequence. The FFmpeg FAQ discusses concat approaches, including the filter for inputs that need re-encoding.
YouTube’s encoder guidance lists RTMP/RTMPS, H.264, H.265/HEVC and AV1, with live frame rates up to 60 fps. Its current guidance gives codec-specific bitrate recommendations for 2160p60: the retrieved English UK table lists 10–40 Mbps for AV1 or HEVC and 35 Mbps recommended for H.264. These are guidance figures, not a guarantee of a particular viewer rendition. The table can change or appear differently by locale, so check the official settings page and the relevant codec column before choosing an encoder target.
The same page recommends a two-second keyframe interval and says not to exceed four seconds. YouTube also advises leaving upload headroom: its streaming tips recommend 20% room beyond the combined primary and backup bitrate. If your connection cannot sustain the configured output with room to spare, a lower, stable feed is a better starting point than an intermittent 4K60 one.
Check every source before joining files
Do not begin by assuming files with the same extension are compatible. MP4 is a container, not a promise that two files have the same video codec, audio layout, time base or frame timing. Inspect every file with ffprobe and record at least its streams, codec names, dimensions, frame rate, time base, audio properties and duration.
For example, inspect a file with ffprobe -hide_banner -i clip1.mp4. For a more concise inventory, you can use ffprobe’s output options to select stream and format fields, but the exact command may differ across builds. The ffprobe documentation explains the available output formats and fields. Keep the results together in a simple table before deciding whether stream-copy is appropriate.
| Property to compare | Why it matters for concat | What to do if it differs |
|---|---|---|
| Video and audio streams | The demuxer expects matching stream layouts and codecs | Remove, add or convert streams in a preparation encode |
| Codec and time base | Packet streams must be compatible for seamless sequencing | Normalise to matching codecs and timing, or use a filter workflow |
| Width, height and frame rate | Stream-copy will not resize or convert frame rate | Re-encode to the chosen output dimensions and actual frame rate |
| Audio codec, channels and sample rate | Inconsistent audio can fail or behave unevenly at transitions | Standardise audio layout and levels during preparation |
| Duration metadata | Incorrect duration can cause timestamp artefacts or gaps | Check source timing and correct the preparation workflow |
FFmpeg’s concat demuxer documentation is explicit that the files need the same streams, codecs and time bases. Even when the listed properties match, test transitions: a timestamp discontinuity, bad duration metadata or an audio stream that ends early can still produce an audible gap or a visual jump.
If the material has mixed formats, prepare standardised intermediate files before constructing the playlist. The guide to converting mixed frame rates for a 4K60 YouTube playlist is a relevant next step when the frame-rate differences, rather than the playlist syntax, are the main obstacle. Use a representative sample to assess the result before converting a large library.
Build the concat list for compatible inputs
The concat demuxer reads a text file that describes the sequence. A basic playlist can look like this:
ffconcat version 1.0
file 'clip1.mp4'
file 'clip2.mp4'
file 'clip3.mp4'
Save it as playlist.txt in the working directory. Paths are interpreted according to the list and FFmpeg’s safe-path rules. Keep the list under your control and use paths you recognise. If you use -safe 0 to allow paths that the default safety rules reject, do so only with a trusted playlist: the option relaxes a safety check; it does not improve file compatibility.
For a compatible playlist, a basic test command is:
ffmpeg -f concat -safe 0 -i playlist.txt -c copy output.mp4
This creates a joined file for inspection; it is not yet a live-stream command. If the files already meet the requirements for the destination and the output is valid, -c copy avoids re-encoding. If they do not, the command will not fix them. Review the joined file’s transitions, audio continuity and metadata before using it as a live input.
Looping changes the operational details. FFmpeg has a -stream_loop input option that can repeat an input indefinitely, but option placement and behaviour depend on what is being looped and on the FFmpeg version. A playlist file is itself an input, so test the exact command on a short run rather than assuming a loop flag placed for an individual clip will apply to the concat input as intended.
If you need a pause or black interval between clips, concat will not add one by itself. That requires deliberate media preparation or a filter-based timeline. The FFmpeg loop guide for adding a pause between videos covers that separate requirement.
Choose stream-copy or a normalising encode
The right method follows from the inspection, not from the word “4K” in the title. If all inputs have compatible streams and already meet the target format, test stream-copy first. It uses fewer compute resources and preserves the encoded video packets, although cuts may still be visible or audible if the content itself has abrupt transitions.
If any input needs resizing, frame-rate conversion, codec conversion or audio standardisation, re-encode. That increases processing demand and can reduce quality, but gives you a controlled output format. Set actual encoder dimensions and frame rate, rather than relying on a nominal output rate attached to copied packets. Use an audio codec and stream layout supported by the current YouTube ingestion path.
The live encode then needs to match YouTube’s current recommendations for the selected codec and resolution. Configure bitrate and keyframes deliberately, and check that the upload connection can sustain the primary feed plus any backup feed with headroom. If you are encoding on the same computer that reads and loops the files, watch its load and run a long enough test to expose heat, storage or network problems that a brief preview will not reveal.
Use -re when real-time pacing of file input is appropriate for your chosen command. It controls input read speed; it does not change the resolution, frame rate or codec. A general live-output command cannot be given responsibly without knowing the operating system, FFmpeg build, input characteristics, audio requirements, destination protocol and whether you want a loop. Make those assumptions explicit when adapting an example, and consult the FFmpeg manual for the options supported by your build.
What viewers may receive after transcoding
YouTube’s automatic multi-format transcoding is intended to make live playback usable across a range of devices and network conditions. A viewer on a fast connection and a suitable screen may have a high-resolution playback choice; someone watching on a phone with a constrained connection may use a lower-resolution option. The player and service adapt to the viewing situation.
That does not let you infer a fixed set of output resolutions from the incoming feed. The platform’s processing and delivery choices can depend on the stream and current YouTube behaviour. Do not advertise that every viewer will see 4K60, and do not promise that a particular set of lower renditions will be created for every stream. The reliable claim is narrower: you are sending a particular feed, and YouTube processes live streams for playback in multiple formats.
This distinction is useful when deciding whether to spend effort and bandwidth on 4K60. If your intended audience watches mostly on mobile networks, a stable, well-composed stream may matter more to their experience than the highest possible incoming resolution. If detailed visuals are central, sending a properly prepared higher-resolution feed can be worthwhile, while the viewer still chooses from what YouTube makes available to them.
How YouTube detects resolution and frame rate
YouTube’s encoder guidance describes default resolution and frame-rate detection. In practice, the incoming signal’s actual encoded dimensions and frame rate matter: choosing a label in your workflow or naming a file “4K60” does not make its packets 2160p at 60 fps. The encoder must produce those properties, and the signal must reach YouTube consistently enough to be identified and processed.
For a re-encoded feed, set dimensions and frame rate at the encoding stage and verify the resulting output with a probe or preview. For stream-copy, inspect the source packets and do not expect an output flag to alter them. Then check the incoming preview and stream health in YouTube Live Control Room. A short validation stream is more useful than relying on a local file alone, because it also tests the encoder, connection and YouTube ingestion together.
YouTube advises testing before going live and checking stream health. Its streaming tips also recommend testing representative audio and motion. Use a section with changes in both picture and sound, not only a static title card. Look for dropped frames or connection warnings, audio level changes at clip boundaries, and whether the incoming resolution and frame rate are what you intended.
For an always-on channel, file preparation is only one part of continuity. A local FFmpeg process depends on the machine, power, network and process remaining healthy. If your actual requirement is to keep a prepared video broadcasting while your own computer is switched off, StreamNeo removes that specific dependency: you upload the video and connect your YouTube channel without keeping a local FFmpeg session running. It is YouTube-only, so it does not replace a general-purpose workflow for other platforms or a need to control FFmpeg filters yourself.
When manual resolution settings are relevant
YouTube’s guidance allows a custom stream key to be configured for manual resolution in applicable workflows. That is different from assuming the setting is needed to make every feed 4K60. If you use a custom key, check its current options and match them to the signal your encoder actually sends; do not configure an expectation that conflicts with the encoded output.
Manual settings can be useful when your workflow needs an explicit resolution choice rather than relying on automatic detection. They do not convert media, make incompatible concat inputs compatible or improve a weak connection. Start by proving the outgoing signal and connection are sound, then use the current Live Control Room settings relevant to your stream key.
YouTube’s interface and available settings can change. Confirm the steps in current official help rather than copying screenshots or instructions from an older setup. Regardless of manual or automatic selection, verify what YouTube reports during a test stream and correct the source or encoder if the incoming feed is wrong.
What the guidance does not promise
The documentation does not define one universal command for every playlist. The operating system, FFmpeg version, file codecs, audio layout, loop behaviour and ingest protocol all affect the exact command. A command that works for matching H.264 files on one build may not be suitable for HEVC inputs, different stream layouts or a filter-based conversion on another system.
Nor does a 4K60 incoming feed imply that all viewers receive 4K60, or that YouTube always exposes the same named resolutions below it. The platform handles transcoding and delivery; its guidance should not be turned into a guaranteed rendition ladder. Bitrate recommendations and interface behaviour can also be revised, so verify the official pages close to the time you configure the channel.
Finally, a successful local file does not prove a successful overnight stream. Test a representative playlist in Live Control Room, observe the stream health, confirm audio and transitions, and leave enough network capacity for the outgoing bitrate. If you change the codec, bitrate, playlist or network path, test again before depending on it for a long broadcast.
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 the concat demuxer with clips in different formats?
Not reliably as a direct stream-copy playlist. The demuxer expects compatible streams, codecs and time bases; first normalise mismatched files or use a filter-based concat workflow that re-encodes them.
Does -c copy make my playlist 4K60?
No. It copies encoded packets and does not resize video or convert its frame rate. Use it only when the inputs already meet the target requirements and are compatible with one another.
Will every viewer see the stream in 4K60?
No. You send an incoming feed, and YouTube transcodes live streams into multiple formats for playback. Available choices and playback quality can vary, so do not promise that every viewer receives the original feed.
Should I use automatic detection or a custom stream key?
Use the current YouTube settings that match your encoder and workflow; a custom key can be configured for manual resolution where applicable. Neither setting fixes incompatible source files, so verify the actual outgoing signal and test it in Live Control Room.