An MP4 file can be much larger after FFmpeg re-encoding because the new video or audio streams use more data than the originals. MP4 is the container, not the compression setting: compare the streams and the command before changing the extension or guessing at a fix.
For a YouTube upload, a larger file is not automatically a problem. First check whether you changed the codec, bitrate, resolution, frame rate, audio, or quality target; then decide whether the extra size is worth the visible difference for your video.
MP4 is a container, not a size setting
An MP4 file packages streams and related information together. A common combination is H.264 video and AAC audio, but a file can contain different codecs, multiple audio tracks, subtitles, or other streams. Its .mp4 extension does not tell you how efficiently those streams were encoded.
A useful first estimate is that size depends on the average combined bitrate and duration. A longer file or a stream encoded at a higher bitrate will generally take more space. Container overhead exists, but it is usually not the reason a re-encoded video has grown substantially.
That distinction matters when you compare an input in one container with an output in another. If the source was already compressed efficiently and you re-encode it to H.264 using a high quality target, the output may be larger even though both look similar. Conversely, changing containers without re-encoding may leave the encoded streams unchanged and the file size broadly similar.
Re-encoding is not the same as making a file smaller. It decodes the source and creates new encoded streams according to the selected codec and settings. The encoder does not know that you want a smaller file unless your rate-control choices make that the priority, and even then the result depends on the content and quality you accept.
If your eventual goal is a prerecorded YouTube broadcast, keep this file-size question separate from how you schedule playback. A guide to scheduling prerecorded videos for a 24/7 YouTube stream addresses the broadcast workflow; this article is about the media file you prepare for upload or playback.
Compare the input and output streams
Use a media information tool or ffprobe on both the original and the re-encoded file. Compare like with like: record each file's duration, video codec, average video bitrate, dimensions and frame rate, then note its audio codec, channels, sample rate and bitrate. Also check how many streams each file contains.
A simple inspection command is:
ffprobe -v error -show_entries format=duration,size,bit_rate \
-show_entries stream=index,codec_type,codec_name,profile,width,height,r_frame_rate,avg_frame_rate,bit_rate,sample_rate,channels \
-of default=noprint_wrappers=1 input.mp4
Replace input.mp4 with each filename in turn. Some files do not report a stream bitrate, or report it unreliably; use the format duration and size as supporting evidence rather than treating one missing field as proof. The important part is identifying which streams and properties changed.
For example, suppose the original is a short 1080p H.264 video with stereo audio, while the output has the same duration and dimensions but a higher reported video bitrate. That points you towards rate control or encoder efficiency, not the MP4 extension. If the output instead has a second audio stream or subtitles retained, account for those as well before drawing a conclusion.
Read the FFmpeg command that created the output. Look especially at -c:v for the video encoder, -crf or -b:v for rate control, -preset for libx264 compression behaviour, video filters that resize or change frame rate, and audio options such as -c:a, -b:a, and -ac. -c copy copies a stream rather than encoding it, while other options may create a new stream.
A stream-level comparison is more useful than looking only at two file sizes because it suggests a fix. If the video settings are unchanged but audio is much larger, changing video CRF will not address the cause. If the frame rate doubled, lowering an audio bitrate will not undo the extra video frames.
Check bitrate, pixels, frames and extra streams
Bitrate is a major size driver. It is the amount of encoded data used per unit of time. A re-encode may use more video bitrate because you chose a lower CRF, an explicit high -b:v, or an encoder configuration that is less efficient for the material. A higher audio bitrate or an additional audio track adds data too. Compare video and audio separately where possible.
Resolution affects how much picture information must be represented. Upscaling an image does not create real detail, but it gives the encoder more pixels to process and can increase the data needed at comparable quality. Check the actual output dimensions, not merely a label such as “Full HD” in an export menu. If the source and intended upload are already at a suitable resolution, avoid resizing without a reason.
Frame rate is another separate variable. A filter or export setting might turn a lower-frame-rate source into a higher-frame-rate output, adding frames over the same duration. YouTube advises uploading at the frame rate used during recording; that is a reason to preserve the source rate when appropriate, not to convert a video simply because a higher value sounds better.
Audio can be easy to overlook because the picture is what you see. Check whether audio was copied or encoded again, whether the output has more channels, and whether an extra language or commentary track was kept. For a devotional music loop, for instance, stereo music may be central to the experience, while a silent visual loop may not need a large audio stream at all. Do not remove a track until you know it is not needed.
Also inspect subtitles, data streams and attachments. Tools and presets can map or retain streams in ways you did not intend. A subtitle track may contribute little compared with video, but additional media streams or unusually large metadata can explain discrepancies. The stream listing tells you whether the output contains more than the one picture and one soundtrack you expected.
If your source came from an existing live-stream workflow, the recording may already have been encoded. Re-encoding it again can add size without adding useful detail. For context on the data side of continuous delivery, see how much data a 24/7 FFmpeg YouTube stream uses; upload-file size and ongoing stream data are related to bitrate but are not the same planning question.
Understand what CRF changes
With FFmpeg's libx264 encoder, CRF is a quality-oriented rate-control method. You choose a quality level and the encoder varies bitrate to represent the material; complex motion, texture, grain or rapid scene changes can need more data than simple static pictures. As the CRF value rises, quality is reduced and output is commonly smaller. A lower CRF generally preserves more quality and commonly produces more data.
There is no CRF value that guarantees a particular file size. Two videos with the same duration and CRF can differ substantially because their visual content differs. A still image with a clock may be easy to encode; a detailed moving scene with foliage or noise may demand more bits. The source quality, encoder build and the viewer's tolerance for artefacts also affect what is acceptable.
If a re-encoded MP4 is unexpectedly large, inspect whether the command used a low CRF for libx264. That may be a deliberate choice to preserve quality, but it can be the opposite of what you intended if your priority was storage or upload time. Raise the CRF in modest steps, encode a representative sample, and inspect it at the size at which viewers will watch. Look at motion, fine text, gradients and dark areas, not just a paused frame.
If the image becomes visibly worse before the file is small enough, do not keep raising CRF blindly. Reconsider whether you need to re-encode at all, whether the output resolution or frame rate should be preserved, or whether a predictable bitrate workflow better suits the constraint. For a 24/7 channel that repeats a prepared video, the source file's quality can affect every playback, so a saving in storage may not be worth persistent banding or smeared movement.
The FFmpeg documentation describes libx264's CRF quality/size trade-off and the direction of change, but it cannot predict your output size without the source and settings. Treat CRF as a control to test, not a file-size calculator. See the FFmpeg codec documentation for the encoder's options.
Understand what the preset changes
For libx264, -preset governs the encoder's speed-versus-compression-efficiency trade-off. Faster presets spend less encoding effort and can produce a larger file than a slower preset at similar perceived quality. A slower preset can improve compression efficiency, but takes longer to encode; it does not automatically make an output smaller if other settings or quality targets differ.
This is why comparing two commands by CRF alone can mislead. If one used a fast preset and another a slower one, their sizes and image quality may differ even with the same nominal CRF. Keep the codec, CRF, preset, filters and audio options consistent when you make a controlled comparison, changing one setting at a time.
For an offline upload file, you may have time to use a slower preset and let the encode finish. For a workflow that must prepare footage quickly before a scheduled broadcast, speed may matter more than squeezing out encoding efficiency. Neither choice is universally right; the practical target is a file that looks acceptable and is ready when you need it.
Do not assume the slowest preset is the answer to an oversized file. If the output grew because you doubled the frame rate or encoded at a lower CRF, changing the preset may not solve the main cause. Diagnose the difference first, then test whether a different preset gives a meaningful size or time trade-off for your content.
Put YouTube's bitrate guidance in context
YouTube's upload recommendations list MP4 as a container and H.264 as a video codec, and advise retaining the frame rate used in recording. For SDR uploads, the guidance gives reference bitrate values by resolution and frame-rate band: 1080p at 24, 25 or 30 fps is listed at 8 Mbps; 1080p at 48, 50 or 60 fps at 12 Mbps; 720p at standard frame rates at 5 Mbps; and 720p at high frame rates at 7.5 Mbps. These are YouTube's recommendations as shown on its upload guidance, accessed in 2026.
Treat those values as orientation for upload encoding, not hard caps, guaranteed file sizes, or a ready-made FFmpeg command. Actual size also depends on duration, audio, stream contents and how the encoder distributes bits. A CRF encode may vary bitrate throughout a video, so it will not necessarily sit at one of those figures.
YouTube states that it accepts uploaded video and re-encodes files as necessary. In its video and audio formatting specifications, it says, “YouTube will still accept your video content and then re-encode your video files as necessary.” The upload's size therefore does not promise the size or exact encoding of the playback rendition viewers receive.
Do not confuse upload recommendations with YouTube Live streaming settings. A file prepared for upload and a live encoder sending a real-time stream have different constraints. If your material is destined for a prerecorded channel, a prerecorded concert workflow on YouTube may help with the channel context; it does not change the stream-level reasons an MP4 grows.
Choose a target that fits the job
Start by deciding what you are optimising: smaller storage, faster upload, preservation of visible quality, compatibility, or a predictable average size. These aims can conflict. A visually faithful file may be larger; a fixed bitrate can give you more predictable sizing but may spend too few bits on a complex scene and too many on a simple one.
| Priority | Practical starting point | What to watch |
|---|---|---|
| Keep the source looking similar | Preserve resolution and frame rate, then test a modest CRF adjustment | Inspect motion, texture and text for visible loss |
| Reduce encoding time | Use a faster preset if time matters more than compression efficiency | The file may be larger at similar quality |
| Meet an approximate size or bitrate need | Use an explicit bitrate target and a suitable rate-control workflow | Quality can vary with scene complexity |
| Avoid needless generational loss | Copy streams when no conversion is required and the streams suit the destination | Confirm the codecs and stream layout are acceptable |
For an ordinary YouTube upload, keep the original resolution and frame rate unless there is a clear reason to change them. If the source is already H.264 at a suitable quality and your problem is not compatibility or size, copying the video stream may avoid an unnecessary generation of loss. If conversion is needed, compare a short representative section before processing the whole programme.
If you need a predictable average bitrate for a specific upload or storage constraint, choose an explicit target and the appropriate rate-control method rather than expecting CRF to hit an exact size. Check the resulting file and playback quality. A bitrate value cannot tell you by itself whether the video is good enough, and YouTube's reference figures are not a rule that every upload must meet.
For a long-running channel, a prepared file that is needlessly large can make uploads and replacements slower. Once the media is ready, a cloud-run broadcast workflow can remove the separate burden of leaving your own computer on to keep a prerecorded stream running: StreamNeo turns an uploaded file into a YouTube live stream after you provide the stream key, with monitoring and automatic restart if it drops. It is YouTube-only, so it does not replace the need to choose and check the source file carefully.
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 changing the file extension make an MP4 smaller?
No. Renaming a file does not change its encoded streams. Remuxing into another container may change a little container overhead, but a meaningful size change usually comes from encoding settings, stream content or duration.
Why is my output larger at the same CRF?
CRF is not a fixed bitrate or a size promise. Content complexity, preset, encoder build, resolution, frame rate and audio settings can all differ, so compare the streams and the full command rather than CRF alone.
Should I cap every YouTube upload at the recommended bitrate?
No. YouTube's published figures are reference recommendations, not hard caps. Use them to orient your decision, then consider duration, quality, frame rate, audio and the requirements of your own upload.
Will a larger uploaded file look better on YouTube?
Not necessarily. A larger source can contain more encoded data, but that does not guarantee a visible improvement, and YouTube may re-encode the upload. Compare the source quality and intended playback rather than assuming file size predicts what viewers will see.