A 24-hour YouTube playlist, in this guide, means one long video file made from the items you intend to play. FFmpeg’s two-pass mode can help you target an average video bitrate, or estimate an output size, when that assembled file is ready to encode.
Two-pass encoding does not create a playlist on YouTube, schedule a broadcast or resolve rights to the source media. It analyses the video in a first pass, then uses that analysis to distribute a chosen bitrate in the final pass. It is useful when size or average bitrate matters; it is not a requirement for uploading to YouTube.
What “24-hour playlist” means here
YouTube uses “playlist” for a collection of videos on the site. Encoding one file does not create that collection. Here, the phrase means that several items have already been assembled into one intended 24-hour video, which you will encode as a single input. If you need guidance on making a continuous stream from separate files, the 24/7 Indian music stream workflow covers a different part of the job.
That distinction matters because the encoding steps below do not choose which items play, arrange them, add transitions or check whether you may use them. They take an existing input file and convert its video and, where specified, audio streams into an output file. Playlist assembly, rights, account-specific upload constraints and publication timing are separate questions.
A long file also needs a clear technical target. If the source clips have mixed resolutions, frame rates, colour characteristics or audio formats, those differences need deliberate handling before or during assembly. Two-pass encoding can plan bitrate allocation for the video it receives, but it cannot make inconsistent source material consistent by itself.
Confirm that the input is one assembled file
Before encoding, check that the file you intend to use is the finished, continuous input. Confirm its duration, video and audio streams, frame rate, dimensions, scan type and colour characteristics. Tools such as ffprobe, which is distributed with FFmpeg, can report stream and container information; check the output rather than assuming the extension tells you what is inside.
Play sections near the beginning, middle and end. Look for missing sections, unexpected black frames, audio gaps, changes in aspect ratio and abrupt changes in level. A duration that looks right does not prove that every source item was included or that the audio remains in sync throughout. Resolve assembly problems before a lengthy encode, rather than treating encoding as a repair stage.
Decide which video stream to encode and what to do with audio. The example later selects the first video stream and optionally maps audio streams. That is a convenient template for a simple input, not a universal mapping policy. A file with commentary, multiple language tracks or several video streams needs explicit stream selection. Check what is present and select the track you actually want.
If your material still consists of separate files, do not mistake an FFmpeg concat workflow for the two-pass encoding step. Joining files may require matching stream properties or converting them to a common format first. The playlist manifest guide discusses a file-list approach in the context of a live stream; a manifest for playback is not, by itself, an encoded 24-hour video.
When two-pass encoding is useful
Two-pass encoding is a form of bitrate-targeted rate control. In the first pass, the encoder analyses the video and records statistics. In the second, it uses those statistics to make decisions about how to distribute the target bitrate across the programme. Scenes with more motion or detail can need more bits than a static title card, so analysis can help allocate a constrained average more deliberately.
This is most useful when you need to work towards a chosen average video bitrate or a rough file-size budget. For example, if you are preparing a 1080p SDR video at a standard frame rate and choose YouTube’s 8 Mbps reference for that class, you can use that as a starting video target. YouTube lists 12 Mbps for 1080p SDR at its high frame-rate group. These are upload recommendations, not mandatory limits or guarantees of a particular result; confirm the current guidance and match the resolution, frame-rate group and SDR/HDR type. See YouTube’s recommended upload encoding settings.
Two-pass is not a quality setting in itself. The target bitrate, source quality, encoder, preset, filters and playback conditions all affect the result. If you want quality-oriented control and are willing to accept a variable output size, constant-rate-factor mode (CRF) is a different approach. Do not combine -crf casually with this bitrate-targeted template: choose which rate-control goal matters first.
There is also a time trade-off. A two-pass job reads the video for analysis and then processes it again for the final encode, so it takes additional work compared with a single pass. How long either pass takes depends on the machine, encoder settings, filters, frame rate and content. Test a representative short section if you need to judge whether your equipment can handle the workflow; do not infer completion time from the duration of the video alone.
Choose a bitrate and estimate the size
Begin with the output’s intended resolution, frame rate and dynamic range. YouTube publishes reference bitrates by those categories. For example, its SDR guidance gives 16 Mbps for 1440p at the standard frame-rate group and 24 Mbps for the high frame-rate group; at 2160p SDR it gives ranges of 35–45 Mbps and 53–68 Mbps respectively. HDR references differ, so do not carry an SDR figure over to HDR. These are YouTube’s recommendations, not independent quality measurements. Read the current upload encoding settings for the appropriate class rather than treating one figure as universal.
The video bitrate is not the whole file size. A useful estimate is:
approximate bytes = (video bitrate + audio bitrate) × duration in seconds ÷ 8
Keep units consistent. If bitrate is in bits per second, the result is bytes. Container overhead and other tracks add some data, and a variable-bitrate encode will not land on an exact size. At an 8 Mbps video target over 86,400 seconds, the video payload arithmetic is 86,400 megabytes, or about 86.4 decimal GB, before audio and overhead. That is a calculation from the target and duration, not a promised file size.
The example uses 384 kbps for stereo AAC audio. YouTube’s upload guidance lists that as a stereo audio reference; it is not part of the video bitrate, and a different channel layout or source may call for a different choice. If audio is already suitable, you may prefer to preserve it rather than re-encode it. Check the source codec, sample rate, channel layout and sync before choosing. YouTube lists 48 kHz as its audio sample-rate recommendation.
Leave room on the working drive for the input, final output, pass logs and any assembly intermediates. A long video may need substantial free space even if the estimate appears to fit, and an incomplete output is not useful. An external drive is one possible place for working files, not a requirement; consider your actual storage capacity and transfer workflow.
Prepare the command and keep passes aligned
The following is an illustrative Linux or macOS template using the FFmpeg libx264 encoder. It assumes a single input with a suitable first video stream, a target of 8 Mbps for that video, and audio that you want to encode as AAC stereo-compatible material. The example does not add scaling, frame-rate conversion, deinterlacing or colour conversion. It has not been tested against your particular file or FFmpeg build, so inspect your local version and available encoders before relying on it.
ffmpeg -i input.mp4 \\
-map 0:v:0 -c:v libx264 -preset medium -b:v 8M \\
-pass 1 -passlogfile encode_stats -an -f null /dev/null
ffmpeg -i input.mp4 \\
-map 0:v:0 -c:v libx264 -preset medium -b:v 8M \\
-pass 2 -passlogfile encode_stats \\
-map 0:a? -c:a aac -b:a 384k -ar 48000 \\
-pix_fmt yuv420p -movflags +faststart output.mp4
The first command writes analysis data using the encode_stats prefix and sends its encoded video to the null output rather than creating the final file. The second reads those statistics and writes the result to output.mp4. In this example 8M represents 8 megabits per second in FFmpeg’s bitrate notation. Change it only after choosing a target that fits the video’s resolution, frame-rate group and SDR or HDR characteristics.
For both passes, keep the input, selected video stream, encoder, bitrate and material video processing options aligned. If you add a scale, frame-rate change, deinterlacer or other video filter, use the same intended processing in both passes. A mismatch means the analysis no longer represents the video that the final pass is encoding. Give separate jobs or inputs different pass-log prefixes so their statistics do not collide.
On Windows, use NUL in place of /dev/null for the first pass. Null output handling and encoder availability can vary by platform and build, so check your installed FFmpeg documentation. For a hardware encoder, do not assume libx264 options map directly: consult the documentation for the encoder you actually use. FFmpeg documents its general options and pass controls and the available codec options.
Run the analysis pass and review its statistics
Run the first command on the complete input. It does not create the deliverable video; it analyses and encodes the video stream for rate-control purposes while writing pass statistics. Expect it to read through the input, so check that the source is accessible and that there is enough free space for logs and working files. Keep the log files until the final pass has completed successfully.
Watch for errors in the console. If FFmpeg cannot open the input, find the selected stream, use the chosen encoder or write its log, the second pass will not be able to complete as intended. Review the reported duration and frame processing against what you know about the input. Warnings about unsupported options or filters deserve investigation rather than being ignored because the command appears to continue.
A first-pass statistics file is not a quality preview. It does not tell you that the final image is acceptable, that audio is present or that the output will be exactly the estimated size. If you need visual confidence in a filter or conversion, test that processing on a short sample first. Then use the same settings for both full passes.
Do not change the input or relevant video settings between passes. If you discover an error in the target bitrate, stream mapping or filter chain, correct the command and rerun the analysis with an appropriate pass-log prefix. Reusing statistics from a different input or materially different processing makes the second pass’s planning unreliable.
Run the final pass and inspect the output
Once analysis has completed cleanly, run the second command. It uses the matching pass log to produce the MP4, with video encoded by libx264 and audio encoded as AAC in this example. -movflags +faststart moves MP4 index data towards the beginning of the file, which can help progressive playback; it does not change the underlying duration or make the encode live. Keep the output filename distinct from the input so you do not overwrite your source.
Check that FFmpeg exits without an error and that the output is present with a plausible size. Probe the resulting file for duration, dimensions, frame rate, video and audio codecs, sample rate and channel layout. Compare the duration with the assembled input and confirm that the audio track is there. A command completing is not a substitute for checking the file.
Play samples from several points, including the opening, a section with motion or fine detail, a quiet or visually simple section, and the end. Listen for sync drift, clipping, silence or an unexpected channel mix. Inspect for blockiness, banding, colour shifts, incorrect aspect ratio or interlacing artefacts. If there is a problem, trace it to the source, chosen settings or processing step before deciding whether a different target or filter is appropriate.
YouTube recommends progressive video, H.264, 4:2:0 chroma and encoding at the frame rate at which the material was recorded. It also gives audio format and colour guidance, including BT.709 for SDR uploads. These are recommendations for uploads rather than universal requirements. Preserve or correctly signal the source’s colour characteristics; do not add colour tags blindly when you do not know the source. Uploading may involve further processing by YouTube, so inspect the uploaded result as well as the local file when the appearance matters.
Encoding ends with a file, not a running broadcast. It does not upload the file, establish a live stream or schedule playback. If your separate problem is keeping an FFmpeg live process running through interruptions, the systemd restart guide addresses process restarts rather than two-pass file encoding. For a workflow in which you want to avoid keeping your computer on to run a prepared file as a continuous broadcast, StreamNeo removes that particular operational burden after you upload the file and provide your YouTube stream key; it does not alter the encoding or rights questions described here.
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
How do I encode a 24-hour YouTube playlist with FFmpeg?
First make sure the playlist items are already assembled into one input file. Run a first pass with the chosen video encoder and bitrate, then a matching second pass to create the output; the commands above illustrate that sequence for libx264. The encode does not create a YouTube playlist or schedule a broadcast.
What bitrate should I use for a 24-hour YouTube video?
Choose a YouTube reference for the output resolution, frame-rate group and SDR or HDR type, then decide whether its average bitrate suits your size budget and source. For instance, YouTube lists 8 Mbps for 1080p SDR at standard frame rates and 12 Mbps for 1080p SDR at high frame rates. Check the current official guidance because those values are recommendations, not universal requirements.
Will two-pass encoding produce an exact file size?
No. The target is an average video bitrate, and audio, container overhead and variable scene complexity affect the finished size. Estimate from combined audio and video rates and the duration, then leave working-space margin rather than treating the calculation as a guarantee.
Do I need two-pass encoding for YouTube?
No. It is useful when targeting an average bitrate or approximate size matters, because the analysis pass informs the final pass. If you prefer quality-oriented rate control and can accept a less predictable size, another rate-control mode may suit the job better.