How do I reduce the size of a huge MP4 video?

Question

I have a 4GB MP4 video file that I shot with the HD Flip Mino. How do I reduce it to no more than 1GB without losing too much quality?

Solution 1

You can try using something such as ffmpeg or mencoder to reencode it with a lower bitrate, e.g.:

Calculate the bitrate you need by dividing your target size (in bits) by the video length (in seconds). For example for a target size of 1 GB (one gigabyte, which is 8 gigabits) and 10 000 seconds of video (2 h 46 min 40 s), use a bitrate of 800 000 bit/s (800 kbit/s):

ffmpeg -i input.mp4 -b 800k output.mp4

Additional options that might be worth considering is setting the Constant Rate Factor, which lowers the average bit rate, but retains better quality. Vary the CRF between around 18 and 24 — the lower, the higher the bitrate.

ffmpeg -i input.mp4 -vcodec libx264 -crf 20 output.mp4

Solution 2

You can non-destructively edit the file to clip out portions you don't want (take 1m off the beginning, 30s off the middle, 4m off the end).

Other than that, you're going to have to re-encode the mp4 as a smaller file. Try Handbrake.

• Decrease the resolution from the Mino's native 1280x720 to something smaller, just preserve the aspect ratio.
• Decrease the bitrate from the Mino's 9.0Mbps average bitrate down to something smaller

In either case you're losing quality. Try fiddling with either option (or both) and compare the results. Pick whatever looks best and has the right filesize.

Solution 3

Use "HandBrake". Import the file. Select "High Profile" and then click on "Start". It can compress 100 MB file to 27 MB or more. (Input file must not be in a already compressed state). If you use Handbrake version 0.9.5 then there is a setting to input File Size you want to compress in. (Upper version of HB does not have this feature).

Sorenson Squeeze is another professional Level tool for this kind of job.

Solution 4

Use x265 video compression to lower the filesize while retaining the same visual quality.

This question is 11+ (!!!) years old already, but in the year 2020 there is a very good new option: Using FFmpeg with x265 compression. x265 video compression can result — from my experience — in video files that are 4x to 10x smaller than x264 equivalents.

In my case I am using FFmpeg on macOS Catalina (10.15.7) and regularly use a command like this to compress large x264 MP4 videos into x265 MP4 videos:

ffmpeg -i input.mp4 \
       -map_metadata -1 \
       -c:v libx265 -crf 20 \
       -c:a aac -b:a 128k -ac 2 -vol 512 \
       -tag:v hvc1 -sn output.mp4
       ;

Note that the process of compressing x264 video into a x265 equivalent is very CPU resource intensive. Depending on your system’s specs, the process can take hours if not days. But the final product is worth the way. Video quality is visually the same as the larger x264 file but much smaller in file size.

View more solutions

Comments

[Daniel B]

If you want to achieve a certain file size with the best possible quality, you can use two-pass encoding, which is possible with many video codecs.

[Mr. Míng]

1000k is better than 1000000 in "ffmpeg -i input.mp4 -b 1000000 output.mp4"

[Jason]

-b takes the bit rate not the byte rate. If the video must be 1GB and the length is 1000 (one thousand) seconds, then the desired bit rate is approximately 1e9/1000*8 = 8e6 (8,000,000) bits per second (bps).

[Narendra Singh]

getting....The encoder 'aac' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it.

[Dante]

@Jason I am pretty sure you mean (1e9 * 8)/1000. In other word (the desired video size in byte * 8) / (length of the video in seconds).

[Jason]

@Dante, the order of operations makes your equations and mine calculate to the same number. Though I see that it may be a bit confusing to put the "*8" after the division. It still calculates to the correct result. Well... unless you're thinking about rounding errors and machine math... then it is possible they will calculate to a slightly different result.

[Dante]

@Jason You were right. I calculated the expression as 1e9/(1000*8). I didn't take into account the precedence and associativity of the operators.

[Wolfpack'08]

Your code doubled the size of my video.