For a conventional FFmpeg playlist sent continuously to YouTube Live, a sensible baseline is H.264 video with AAC audio, delivered over RTMPS. The playlist files you start with do not have to be in that same format, but FFmpeg must either be able to pass them through compatibly or convert them into a consistent output stream.
That distinction is the key to choosing a format that works overnight. Decide separately how to prepare the source files, what encoded stream YouTube will receive, and how the stream will reach YouTube; then test the actual playlist, including its transitions, before relying on it.
What “video format” can mean
“Format” is often used to describe several different things. A file container, such as MP4, packages streams together. A codec, such as H.264 for video or AAC for audio, describes how a stream is encoded. RTMPS is an ingest protocol: it carries your live encoded stream to YouTube. Selecting one does not automatically settle the others.
For example, an MP4 file could contain video and audio encoded in ways that do not suit your intended workflow. Conversely, your playlist sources can use different containers from the stream you encode and send to YouTube. The filename extension alone is not proof that a file is compatible with stream copy, nor does it determine the codec YouTube will receive.
It helps to think in two stages. First, FFmpeg reads the playlist inputs. It may pass their streams through without re-encoding if the inputs meet the concat demuxer’s compatibility requirements. Alternatively, it can decode and re-encode them into a common output. Second, FFmpeg sends the resulting encoded video and audio over the selected ingest protocol.
These choices have different trade-offs. Passing streams through can avoid the processing involved in a re-encode, but it depends on compatible inputs. Re-encoding gives you a way to produce a consistent output from varied files, but it takes additional processing and needs testing on the machine that will run the stream. Neither method makes an untested playlist reliable by itself.
Choose YouTube-compatible output video and audio
For an ordinary RTMPS YouTube Live workflow, H.264 video and AAC audio are a conservative documented baseline. YouTube’s encoder guidance lists other codec options too, but support depends on the ingest protocol and use case. Follow the guidance for the route you are actually using rather than assuming that every codec listed works in every setup.
For SDR content, YouTube’s guidance also covers progressive video, square pixels, and Rec. 709 colour at 8-bit. For stereo AAC or MP3 audio, it recommends a 44.1 kHz sample rate and 128 Kbps audio bitrate. These are YouTube’s stated recommendations, not a guarantee that a particular source file or FFmpeg build will behave as expected. If the playlist mixes audio layouts or sample rates, inspect those inputs and test the output rather than assuming that every transition will be transparent.
HDR has separate considerations. YouTube’s encoder page recommends H.265 over RTMP(S) for HDR and describes HLS as another route when an encoder lacks the necessary RTMP capabilities. If you are building an SDR devotional loop, study channel, or local information stream, do not select an HDR workflow by accident: check the content and output settings together.
YouTube’s HLS guidance describes a distinct segmented delivery path. It has its own requirements, including TS segments, segment durations in the stated range, a rolling playlist limit, and HTTPS requests. HLS can fit particular encoder or codec needs, but it is not simply another label for RTMPS and brings more implementation detail. For a straightforward continuous FFmpeg stream, use RTMPS if it fits your encoder and requirements.
Keep credentials separate from format decisions. Use the ingestion URL and stream key or name provided by YouTube Live Control Room, and check how your encoder expects them to be entered. The YouTube Live API documentation notes that ingestion address and stream name may be represented separately or together depending on the workflow. Treat the key as a secret: do not place it in a public script, screenshot, or shared command example.
Set RTMPS, bitrate, and keyframe interval
YouTube recommends RTMPS, which it describes as a secure extension to RTMP. In FFmpeg, the protocol and the exact ingest address belong in the output configuration, but use the current values from your Live Control Room rather than copying a key or URL from an old tutorial. YouTube may present an address and key separately; enter them in the arrangement your FFmpeg command or wrapper expects.
For the video encoder, YouTube’s guidance calls for constant bitrate (CBR) and recommends a keyframe frequency of two seconds, with four seconds as the maximum interval. A two-second interval is therefore a useful starting point. If you adjust it, keep it within YouTube’s stated ceiling and verify the actual encoded stream; a command-line setting is an instruction to the encoder, not evidence that the stream conforms.
Do not copy a video bitrate from a post without checking the current YouTube table for your selected resolution and frame rate. The appropriate rate depends on those output choices, and the available upload capacity matters as well. A fixed bitrate does not suit every connection. If the upload path cannot sustain the selected rate reliably, the stream may suffer even when the codec and container choices are otherwise sound.
Allow room for the whole outgoing stream rather than judging a connection by a brief speed-test result. Leave practical headroom for variation on the connection, and consider what else shares it: a household upload, another broadcast, or background backups can change what remains available. If your connection is variable, choose a YouTube-supported resolution, frame rate, and bitrate combination that it can sustain, then test under the conditions in which the channel will run.
RTMPS is not the same as a promise of uninterrupted delivery. A dropped connection, overloaded encoder, invalid key, or incompatible output can still interrupt a broadcast. If you need a process to remain unattended, decide how you will see a failure and what recovery looks like; protocol selection alone does not provide that operational plan.
Check resolution and frame rate against settings and upload
Choose the output resolution and frame rate deliberately. Start with the dimensions and motion characteristics of the material you plan to show: a still devotional image with audio does not have the same motion demands as a sequence of camera footage or animation. Then compare your intended output with YouTube’s current resolution, frame-rate, and bitrate guidance and with the capacity of the real upload connection.
The playlist’s source properties still matter even if you intend to re-encode. Inspect each file’s dimensions, frame rate, time base, pixel format, audio codec, sample rate, and channel layout. A mix of landscape and portrait videos may produce unwanted framing or black bars if you do not define a consistent canvas. For practical framing choices, see this guide to fixing black bars on YouTube.
If you stream-copy, differences in these parameters can prevent the files from meeting concat requirements. If you re-encode, plan how varied frame rates and dimensions will map to the output you want. For example, a playlist of 1080p recordings and lower-resolution clips needs an explicit decision about scaling and presentation. Do not infer from the final file extension that FFmpeg has made these choices correctly.
YouTube’s settings are the receiving side of the decision; they do not make mismatched source files identical. Pick a stable output target, review the whole playlist against it, and inspect the resulting stream in YouTube’s live tools. If you change the target resolution or frame rate, revisit the bitrate and upload headroom as well rather than changing one setting in isolation.
Build a playlist with the concat demuxer
FFmpeg’s concat demuxer can read a list of files as one input and can be useful for concatenation without re-encoding. Its important limitation is compatibility: the files need to have matching streams and suitable parameters for the intended stream-copy workflow. The FFmpeg FAQ explains the concat approach and its constraints. It does not establish that any collection of files will join seamlessly just because they appear in a list.
A simple list file is plain text, with one file entry per line, for example:
file 'part-01.mp4'
file 'part-02.mp4'
file 'part-03.mp4'
The list is only an index, not a conversion step. Before using it with stream copy, inspect every item and compare the video and audio streams. Check codec, dimensions, frame rate and time base, pixel format, audio codec, sample rate, and channel layout. A mismatch in a property that matters to the chosen workflow can make direct concatenation unsuitable or cause trouble at a boundary.
A concat-demuxer input often appears in a command with the concat format and a safe-mode setting, followed by the list filename. The output can then use stream copy when the inputs are suitable, or an encoder when they are not. Treat any command found online as a template: paths, stream maps, codec options, protocol address, and key must fit your files and account. Consult the FFmpeg documentation for the options supported by the FFmpeg version you actually run.
A playlist can loop in a process, but an indefinitely running command has more to prove than a short file conversion. Check what happens at the end of the list, whether the next pass begins as intended, and whether FFmpeg exits or waits when an input is unavailable. Test with the actual files and the exact command before you schedule it to run unattended.
Handle mixed inputs with normalisation or re-encoding
When files differ, there are two broad choices: make them conform to a common set of stream properties, or use a workflow that decodes and encodes them into a common output. Normalisation may involve preparing source files ahead of time; re-encoding at stream time may be more convenient when the playlist changes often. Both require care, and neither is a magic switch that fixes every media issue.
Stream copy avoids re-encoding only when the streams meet the concat workflow’s requirements. It does not reconcile different codecs, sizes, time bases, or audio layouts. If a playlist contains a 25 fps clip, a 30 fps clip, and an audio track with a different sample rate, do not assume that putting the files in the same list will make them agree. Prepare compatible files first or build a filter-based concatenation and encoding workflow that deliberately handles the differences.
Normalising ahead of time can make the live job simpler: each prepared item can share chosen dimensions, frame rate, pixel format, and audio properties. The cost is an additional preparation step and new output files to check. Re-encoding during the live process avoids that separate batch step, but uses processing capacity while the stream is running. Test with the machine and settings you plan to use; do not assume that it can encode a particular workload continuously because it completed a short sample.
Audio deserves its own check. A file with no audio stream, a different channel layout, or a change in loudness can behave differently at a join. Decide whether silent sections should remain silent, whether audio needs to be mapped or mixed, and whether the transition sounds acceptable. Listen to the boundary rather than checking only that the video picture continues.
The same applies to picture transitions. A technically valid concatenation can still show a pause, a repeated frame, a jump in brightness, or an abrupt cut because of the content and encoding at the file edges. If the programme is a sequence of bhajans, lectures, news cards, or ambience clips, review enough of each boundary to decide whether the change is acceptable for viewers. The FFmpeg concat documentation is useful for implementation details, but your files determine what needs normalising.
Test the playlist and monitor stream health
Test the exact playlist, command, and ingest settings you intend to use. YouTube recommends testing with audio and movement similar to the planned stream, then monitoring stream health and messages in Live Control Room. A short test can expose a wrong key, unsupported output, or a connection problem; a boundary test can expose a different class of issue that a single-file test misses.
Include the end of one file and the start of the next in your test. Check that video appears, audio stays continuous or changes as intended, and the transition does not leave a gap or an unexpected frozen image. Test the point where the list loops too. Do not describe a playlist as gapless until you have checked the actual material and observed the transition you care about.
During the test, watch YouTube’s stream-health indicators and messages, and pay attention to the FFmpeg process output. A process still running does not prove YouTube is receiving a healthy stream. Conversely, a healthy-looking local process does not show whether viewers see the intended framing, audio, or transitions. Check the receiving side and the programme itself.
For a 24/7 channel, plan the operating routine as well as the encoding settings. Keep the playlist and command available to the person who will maintain them, protect stream credentials, and decide how you will notice a process or connection failure. If an always-on computer is part of your setup, the article on streaming to YouTube from a Windows VPS using OBS gives context for an alternative operating workflow; the right approach depends on what you need to run and maintain.
A cloud-based workflow can remove the need to leave your own computer switched on. For a playlist that is already prepared, StreamNeo removes the specific chore of keeping a local machine running to send the uploaded video to YouTube; it does not change the need to check that the content, stream settings, and channel are ready. If you are weighing an always-on local setup against a cloud service, this break-even comparison lays out the decision in operating terms.
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
Should every playlist file be MP4?
No. The extension does not establish which codecs or stream properties are inside a file, or whether it can be concatenated with another input without re-encoding. Inspect the streams and choose a workflow that produces the output YouTube is meant to receive.
Can I use stream copy with a playlist?
Yes, when the input streams satisfy the concat demuxer’s compatibility requirements and suit the output you need. If properties differ, prepare common inputs or use a workflow that normalises or re-encodes them; test the file boundaries either way.
What is a sensible output baseline for YouTube Live?
For an ordinary RTMPS stream, H.264 video and AAC audio are a documented baseline. Use CBR and a two-second keyframe interval as a starting point, staying within YouTube’s four-second maximum, and check current guidance for your resolution, frame rate, and bitrate.
Does a successful short test prove the stream will run continuously?
No. Test the actual playlist, including transitions and the loop, and monitor both FFmpeg and YouTube stream health. Connection changes, process failures, and input-specific issues can still affect a longer broadcast.