If you want to reduce the size of a video file before uploading it to YouTube, two-pass encoding can help you target an average bitrate more deliberately. It does not guarantee a smaller file or unchanged quality: the size depends on your target, the source, audio, and container overhead.
This is an offline workflow for a finished file, not a way to encode an active YouTube Live broadcast. If you are setting up live ingest, use the separate live-stream guidance below rather than applying two-pass commands to a real-time feed.
Start by separating upload files from live streams
A pre-recorded upload can be analysed and encoded before you send it to YouTube. Two-pass encoding uses that time: the encoder makes an initial analysis pass, then encodes the output using the information it gathered. You can choose an average bitrate in advance and plan approximately how much data the finished file will contain.
A live stream has a different job. Its encoder must produce frames as the event happens and send them continuously over a network connection. You cannot pause a live programme for an analysis pass over footage that has not yet been created. YouTube’s live encoder settings cover real-time ingestion, including separate bitrate and keyframe guidance. Do not treat those live settings as an offline file-size recipe, or vice versa.
This distinction matters for an always-on channel built from recorded material. If you are preparing a single long programme or clips to upload, an offline encode may suit the task. If you are sending a signal from a running encoder, its bitrate, connection and keyframe behaviour are the relevant concerns. The live bitrate and resolution guide addresses that separate situation.
Two-pass encoding is not a special YouTube requirement. YouTube’s recommended upload settings include H.264, MP4, progressive scan and variable bitrate as guidance for uploads, but they do not require two passes. You can use a single-pass encode when speed or simplicity matters more than precise average-bitrate planning.
What two-pass encoding does
In the first pass, the encoder reads through the source and records statistics about the material. These can indicate where a scene has more movement, texture, cuts or other complexity that calls for more data, and where a simpler section may need less. The first pass is analysis, not usually the finished file you intend to upload.
In the second pass, the encoder uses those statistics to distribute bits while aiming for the requested average video bitrate. A detailed scene may receive more of the available data than a still title card, for example. The purpose is to manage a bitrate target across the whole programme, rather than to give every moment identical treatment.
The FFmpeg documentation describes a first pass that writes statistics to a log and a second pass that uses that log while encoding at the requested bitrate. Its encoding documentation is useful when you are working with FFmpeg, but the general idea also applies to other encoders that support two-pass average-bitrate encoding.
Two passes take more encoding work than one. In return, you get a more informed allocation of bits toward the average target. That does not mean two-pass automatically makes a file smaller: the target bitrate, not the pass count, sets the approximate data budget. Nor does it promise that a particular target will look good. A noisy camera recording, fast movement, fine text and a static illustration can respond differently to the same settings.
When a bitrate or size target helps
A bitrate target is useful when you need to plan an upload, keep an archive manageable, or avoid an unnecessarily large export. A size target can help when you have a storage or transfer constraint, but it is not the same as a quality target. When you insist on a smaller file, you are asking the encoder to represent the material with less data, unless you also change something else such as duration, resolution or codec.
For rough planning, multiply the average total bitrate by the duration in seconds to estimate the amount of data. For example, if a programme runs for 3,600 seconds and the combined average video and audio bitrate is 8 megabits per second, the data estimate is about 28,800 megabits, or 3,600 megabytes before allowing for container overhead. This is an illustration of the calculation, not a recommended YouTube setting or a promised output size.
Include audio in that budget. If you set a target for the video stream alone, the audio track and MP4 container add to the final file. The difference may matter when you are planning close to a strict upload or storage limit. The actual result can also differ from the estimate because the requested average bitrate is not an exact byte-count instruction.
YouTube’s SDR upload recommendations offer a useful reference when the goal is an ordinary upload at a given resolution and frame rate. The figures below are recommendations, not required minimums or guarantees of quality. YouTube says no bitrate limit is required, and the figures do not describe what viewers will receive after YouTube processes the upload.
| SDR resolution and frame rate | YouTube’s recommended video bitrate |
|---|---|
| 720p at 24, 25 or 30 fps | 5 Mbps |
| 720p at 48, 50 or 60 fps | 7.5 Mbps |
| 1080p at 24, 25 or 30 fps | 8 Mbps |
| 1080p at 48, 50 or 60 fps | 12 Mbps |
| 1440p at 24, 25 or 30 fps | 16 Mbps |
| 1440p at 48, 50 or 60 fps | 24 Mbps |
| 2160p at 24, 25 or 30 fps | 35–45 Mbps |
| 2160p at 48, 50 or 60 fps | 53–68 Mbps |
These values are from YouTube Help’s upload encoding recommendations; the retrieved page does not state a publication year. Its recommendations also vary for other resolutions and for HDR. If your source is HDR, do not simply reuse the SDR numbers: check the current HDR guidance and confirm the output’s colour metadata.
If you specifically need to fit a file under an approximate size, estimate the total bitrate that would suit the duration, then reserve room for audio and overhead before choosing the video target. If you instead want a good-looking upload and have no strict size ceiling, start from YouTube’s relevant recommendation and judge the result. For an always-on playlist, the continuous lofi playlist guide may also help you think about the source material and how it will be used, although it does not replace encoding checks.
Prepare the source and choose settings
Before you encode, identify the source resolution, frame rate, duration, audio, and whether it is SDR or HDR. Decide which output resolution you actually need. Upscaling a small source does not recover detail that was never recorded, while downscaling can reduce data needs but changes the image. Preserve the source frame rate unless you have a deliberate reason to alter it; YouTube recommends encoding and uploading at the frame rate at which the content was recorded.
Choose a codec and container that suit your workflow and YouTube’s upload guidance. For a straightforward SDR H.264 upload, YouTube recommends MP4, H.264 video, progressive scan, High Profile and variable bitrate. The wording is guidance rather than a guarantee that every source or preset will be ideal. Check the current official upload page if your project uses a less common codec, HDR, unusual frame rate or a specialised editing workflow.
Next decide whether you are prioritising approximate size or visual quality. If the file must fit a known budget, estimate a total average bitrate from duration and size, then account for audio and overhead. If your main goal is quality, use the applicable YouTube recommendation as a reference and inspect the encode rather than assuming the table is a threshold. Lower video bitrate tends to reduce file size for the same duration and codec, but it also leaves fewer bits to represent image detail.
Keep settings consistent between the analysis and encode passes. The input, relevant filters, frame rate, output dimensions, codec and bitrate plan should match; otherwise the statistics may not describe the video that the second pass actually encodes. Save the output to a location with enough free space and keep the pass log somewhere you can find until encoding has finished.
For example, a devotional channel might have a long recording with a mostly static image and occasional camera movement. A single target still has to cover the full programme. Two-pass encoding can use its analysis to distribute bits more thoughtfully, but a target chosen only because the image looks simple at the beginning could fail in a later sequence with movement or detailed artwork. Sample the difficult material before settling on a final setting.
Run the first pass and save its log
The first pass should analyse the same source and intended video settings that the final encode will use. In FFmpeg workflows, the pass log is a working file used by the second pass. Keep it until that pass completes, and avoid reusing a stale log from another input or a different set of filters. A mismatched log undermines the point of the analysis.
FFmpeg command options can vary with codec and build, so check its current documentation and the encoder-specific options for the codec you select. A common pattern is to specify the input and video settings in both commands, mark the first command as pass one, and direct the pass statistics to a log file. Some workflows suppress video output during the first pass; do not assume the exact command line is interchangeable across encoders.
Plan where temporary material will go. The first pass still reads the whole source, so encoding takes time even before the upload-ready file exists. On a modest computer, this can be inconvenient for a long programme, especially if you also need to keep editing or using the machine. For a one-off video with no firm size limit, the additional analysis may not be worth the wait.
If you are using FFmpeg for live ingest rather than a file export, stop here and use the live workflow instead. The guide to adding a YouTube stream key to FFmpeg on Ubuntu covers a different setup: sending an active feed to YouTube. The shared tool does not make offline two-pass file encoding and live transmission the same task.
Run the second pass using the log
The second pass reads the same input and uses the analysis log to guide bit allocation toward the average bitrate target. This is where the encoder produces the file you can review and upload. Keep the relevant settings aligned with the first pass and make sure the output filename and container are correct for the intended upload.
If the second pass fails, check that the log is present and readable, that the source path has not changed, and that you used the matching codec and settings. Do not delete the log merely because the first pass has ended; it is needed for the next stage. Once the second pass has completed and you have checked the output, you can remove temporary pass files if you no longer need them.
Two-pass work is best scheduled when you have time to let the machine finish. It is not a way to reduce the bandwidth needed by a live encoder, and it does not make YouTube process the upload faster by definition. For a channel that relies on recorded files, you can prepare and verify them before they are needed. If instead your concern is whether an ongoing broadcast keeps running while your computer is off, that is a separate operational issue; the guide to keeping a stream running with the browser closed is about continuity, not offline file compression.
Check output size and visual quality
When the encode finishes, check the file size rather than assuming the bitrate calculation gave an exact result. Compare it with your target, bearing in mind that audio, container overhead and encoder behaviour contribute to the final number. Confirm that the file plays from beginning to end and that the audio is present, synchronised and at a sensible level.
Watch the areas most likely to reveal damage: motion, fine text, gradients, detailed artwork, dark scenes and transitions. A still thumbnail can conceal blocking or smearing that becomes obvious when the image moves. If the source contains lyrics or a small devotional image, inspect those details at the resolution viewers will actually see. Listen through difficult audio sections as well; video bitrate settings do not fix a clipped or noisy recording.
If the file is too large, first confirm that you used the intended duration, bitrate and audio settings. Then lower the target cautiously or consider whether a smaller output resolution is acceptable. If the image is poor, raise the target or revisit the source and settings rather than uploading a damaged file simply to hit a size goal. No single target works equally well for every kind of footage.
For repeatable work, note the source, frame rate, resolution, codec, target bitrate, audio choice and final file size. A short record helps you compare future exports without relying on memory. It is not a controlled test unless you hold the relevant conditions constant, so avoid turning one successful encode into a universal bitrate rule.
Choose the workflow that fits the job
Two-pass encoding is most useful when you have a specific average bitrate or approximate size in mind and can afford the extra encoding work. A one-pass workflow can be more convenient when turnaround matters, or when the encoder’s quality-based mode and file-size variation are acceptable. The choice depends on what matters for that file, not on a blanket claim that one method always looks better.
For a long upload with a strict storage ceiling, estimate the bitrate budget first and reserve for audio. Then encode a representative section, including the most complex scenes, and inspect it before processing the full programme if your software allows. If the sample looks poor, adjust the target or output settings before committing time to the whole file.
If the file will become part of a continuous YouTube channel, the encoded upload is only one element of the setup. A file that plays cleanly offline still needs to be uploaded and checked in YouTube Studio; a live channel built from recorded material also has a separate operational path. Where the recurring problem is that your computer must stay on to keep an uploaded video broadcasting, StreamNeo removes that specific burden by running the uploaded file as a YouTube live stream while your computer is off. It does not change the offline encoding decisions 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
Does two-pass encoding make files smaller?
Not by itself. Two-pass encoding uses first-pass statistics to target an average bitrate more deliberately; choosing a lower bitrate target is what reduces the data budget, with a possible quality trade-off. The final size also includes audio and container overhead.
What bitrate should I use for a 1080p YouTube upload?
YouTube Help recommends 8 Mbps for SDR 1080p at 24, 25 or 30 fps, and 12 Mbps at 48, 50 or 60 fps. These are reference recommendations, not mandatory minimums or guaranteed quality thresholds. Check the current official guidance for HDR or other unusual settings.
Is two-pass encoding better than one-pass?
It is useful when you want to target an average bitrate and can wait for the extra encoding work. A one-pass method may be preferable when speed or simplicity matters more, or when file-size variation is acceptable. Neither method guarantees a better-looking result for every source.
Can I use two-pass encoding for an active YouTube Live stream?
No: the workflow described here analyses an existing file and encodes it ahead of upload. Live ingest is real-time and uses separate encoder and network settings. Follow YouTube’s current live guidance for a broadcast rather than applying this offline file workflow.