How can I reduce a video's size with ffmpeg?

Question

How can I use ffmpeg to reduce the size of a video by lowering the quality (as minimally as possible, naturally, because I need it to run on a mobile device that doesn't have much available space)?

I forgot to mention that when the video can use subtitles (*.srt or *.sub), I'd like to convert them too to fit the parameters of the converted video file.

Answer 1

Update 2020: This answer was written in 2009. Since 2013 a video format much better than H.264 (AVC) is widely available, namely H.265 (HEVC; better in that it compresses more for the same quality, or gives higher quality for the same size). To use it, replace the libx264 codec with libx265, and push the compression lever further by increasing the CRF value — add, say, 4 or 6, since a reasonable range for H.265 may be 24 to 30. Note that lower CRF values correspond to higher bitrates, and hence produce higher quality videos.

ffmpeg -i input.mp4 -vcodec libx265 -crf 28 output.mp4

You can also specify a libx265 preset, which affects file size and quality.

---

To see this technique applied using the older H.264 format, see this answer, quoted below for convenience:

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

Answer 2

You mentioned wanting to reduce the file size to fit more videos on a mobile device, which is my use case as well.  All the answers here are for reducing the compression quality, but nobody has mentioned reducing the video frame size.  It's a lot quicker, up to multiple times faster depending on your source, and the amount of the resolution decrease, as there are fewer pixels to be encoded.  As a result, the file size can be reduced significantly.

The downside is you also lose a large amount of quality because fewer pixels means less image detail.  But when converting for a small device this may be acceptable.

See the FFmpeg docs on scaling for more info.

To scale to half size:

ffmpeg -i input.mkv -vf "scale=trunc(iw/4)*2:trunc(ih/4)*2" half_the_frame_size.mkv

One-third size:

ffmpeg -i input.mkv -vf "scale=trunc(iw/6)*2:trunc(ih/6)*2" a_third_the_frame_size.mkv

One-quarter size:

ffmpeg -i input.mkv -vf "scale=trunc(iw/8)*2:trunc(ih/8)*2" a_fourth_the_frame_size.mkv

One-fifth size:

ffmpeg -i input.mkv -vf "scale=trunc(iw/10)*2:trunc(ih/10)*2" a_fifth_the_frame_size.mkv

In these examples, the size is divided by twice the value and multiplied by two to ensure the pixel size is a multiple of two, which is required for some codecs, including H265.

You can also scale to a specific size in one parameter and automatically keep the same ratio using -2 for the other. For example 360 pixels in one direction would use:

-vf "scale=-2:360"

Be aware that changing the resolution always requires re-encoding, so all the ins and outs of the other answers apply here as well, and these examples are compatible with H265 options like -c:v libx265 -crf 28. 

Answer 3

I tested most of the other proposed answers to this question. The test data conclusions are below. These are the proposed answers that I tested:

(BR) Modify the bitrate, using:

ffmpeg -i $infile -b $bitrate $newoutfile 

(CR) Vary the Constant Rate Factor, using:

ffmpeg -i $infile -vcodec libx264 -crf 23 $outfile

(SZ) Change the video screen-size (for example to half its pixel size), using:

ffmpeg -i $infile -vf "scale=iw/2:ih/2" $outfile

(BL) Change the H.264 profile to "baseline", using:

ffmpeg -i $infile -profile:v baseline $outfile

(DF) Use the default ffmpeg processing, using:

ffmpeg -i $infile $outfile

DATA

• "size" - percent pixel size of the converted video in relation to the original.
• "bitrate" - bitrates of original and converted videos.
• "definition" - pixel size of videos.
• "convert" - time to convert the video in seconds.

I calculated the target bitrate for (BL)using the proposed method.

=== File A - How Node Is Helping To Propel Angular-Fnbixa7Ts6M.mkv ===

            original    BR         CR         SZ         BL         DF
            --------    ---        --         --         --         --
size        64152 kb    214%       76%        40%        83%        76%
bitrate     411 kb/s    883        313        165        342        313
definition  1920x1080   1920x1080  1920x1080  960x540    1920x1080  1920x1080
convert     --          648        509        225        427        510

=== File B - Using GraphQL with Angular _ By - Lee Costello-OGyFxqt5INw.mkv ===

            original    BR         CR         SZ         BL         DF
            --------    ---        --         --         --         --
size        410301 kb   33%        109%       28%        143%       109%
bitrate     2687 kb/s   880        2920       764        3843       2920
definition  3840x2160   3840x2160  3840x2160  1920x1080  3840x2160  3840x2160   
convert     --           2307       3188       1116       2646       3278

CONCLUSIONS

• The (SZ) method is definitely the quickest method. It was 2X to 4X faster. This can be very much an issue on high-def videos, since all of the other methods took longer to convert than the actual length of the video! For example, The (CR) method took 53 minutes to convert the 21 minute video.

• The (SZ) method is definitely the best method if the definition of the video is larger than the definition of the screen that will be displaying it. For example, if your phone can only display a 1080p picture, sending it a 3840x2160 video is just wasteful. It would be best to half its size to 1080p.

• Some of the proposed answers actually INCREASED the size of some videos. For example, the (BR) method more than doubled the size of the 1080p sample. It did however make the 2160p size one-third. For the high-def sample, the (CR), (BL) and (DF) methods all INCREASED the size of the video.

Correct (or best) Answer

It is always best to first lower the resolution to the maximum supported by your target display.

If you want to reduce file size further, it will depend on personal choices. You can either reduce information content or increase compression.

• You can lower the resolution more if that is not something that concerns you.

• If the video doesn't include fast action scenes, you may want to lower the frame rate.

• If you have a powerful processor and space is the only issue, you can increase the compression rate.

• Bit rate is a combination of multiple factors. So just telling ffmpeg to lower the bit rate may not give you the results you want.

• Another way of lower information content is to lower the color depth. How to do this was not yet discussed.

Answer 4

Note that it seems that ffmpeg already performs some optimization when ran without options, so before trying to use settings you don't understand or deciding to explicitly lose information, give a try to a default conversion :

ffmpeg -i input.mp4 output.mp4

In my case it reduced the bitrate of both the video and audio (you can check and compare the input and output file by running ffprobe on them), transforming a 700 Mb video into a 60 Mb one of seemingly similar quality.

Answer 5

Unless you're looking for a specific bit rate, I'd recommend the -crf option.

This is most commonly used for x264 encoding as described in this article.

In short: a constant rate factor (CRF) of 23 would make a DVD quality movie (~700MB - 1GB) and lower CRF values would be higher quality (larger files).

An example from the linked article:

ffmpeg -i input.mp4 -c:v libx264 -crf 28 output.mp4

Smaller sizes can be achieved by using libx265 instead of libx264 within the above command. However that causes issues with web browser compatibility and may take way longer.

Answer 6

I compressed a 40-minute HD video presentation from 505MB to 183MB
That's like going from 100MB → 36MB.
Original video was HD and output was almost zero noticeable difference.
It's a video file "I'd like to keep around, but HD is overkill."
Here's the command I used with reasons:

ffmpeg -n -loglevel error -i inputfile.mp4 -vcodec libx264 -crf 28 -preset faster -tune film outputfilename.mp4

• -n : avoid overwriting output files (safer for testing then batching)
• -loglevel error : show errors and hide the rows and rows of progress
• -i inputfile.mp4 : input file name
• -vcodec libx264 : swiped from the top answer above
• -crf 28 : single-pass compression with minor noticeable difference ("0 = lossless, 23 = default, 51 = worst; subjectively sane range is 17–28") ref docs
• -preset faster : looks 2x faster than default encoding time of 'medium' ref docs
• -tune film : specify input is an HQ video (other options include 'cartoon', 'stillimage'..) ref docs
• outputfilename.mp4 : output file name

For a directory of video files:

for i in *.{avi,flv,m4v,mov,wmv,mp4,MP4,TS,mkv}; do ffmpeg -n -loglevel error -i "$i" -vcodec libx264 -crf 28 -preset faster -tune film "cc${i}"; done

Issues:

• a cleaner way of collecting "all video files" without having all the extensions in the command
• a cleaner way to output the filename without "cc" prefix, AND being able to confirm video before deleting
• .webm files don't work with the command. Had to swap "cc${i}" → "${i%.*}.mp4"

Handbrake is an open-source alternative with a UI

Answer 7

If you’re targeting a specific file size (or bitrate) rather than a specific quality, you'll need to use a two-pass average bitrate encoding (or “2-pass ABR” for short) to fit the video within this size without reducing the quality too drastically.

In short, for the same bitrate it achieves a better quality than a single-pass bitrate encoding (as demonstrated in this answer), because the first pass allows the codec to allocate bit usage based on needs, i.e. it can spare bits on easy frames and have more available to spend on more demanding frames. By contrast, in the single-pass mode, the codec cannot know ahead of time what is coming but still has to enforce a constrained bitrate.

See this blog post (or this archived one) for an enlightening explanation, and ffmpeg’s wiki about H.264 for a more synthetic how-to.

Typical command line:

ffmpeg -i <INPUT> -c:v libx264 -preset medium -b:v <BITRATE> -pass 1 -an -f <OUTPUT_CONTAINER> -y /dev/null && \
ffmpeg -i <INPUT> -c:v libx264 -preset medium -b:v <BITRATE> -pass 2 <AUDIO_OPTIONS> <OUTPUT>.<OUTPUT_CONTAINER>

You’ll have to pick a number of things.

• Set a target bitrate, e.g. 1M (1 Mbit/s) or 500k (500 kbit/s). See this answer for how to compute a relevant bitrate.
• Nowadays (2020), you’ll probably replace the libx264 video codec with the newer libx265 codec, which gives higher quality for the same size. See ffmpeg’s wiki for how to adapt the 2-pass options to that codec.
• Set whatever options you want for audio encoding. For example, to re-encode with the Opus codec at 128 kbit/s, write -c:a libopus -b:a 128k (in 2020 I would recommend Opus over any other lossy audio codec, such as AAC). But, unless you know what you are doing, your best option may be not to re-encode audio at all, i.e. write -c:a copy. This way, you don’t even bother and your audio won’t lose in quality. Anyway, re-encoding audio often doesn’t save much (many audio streams in the wild are already bitrated at about 128kbit/s or less) and audio streams often have a negligible size when there is a video stream. See there for more guidelines on audio re-encoding.
• Pick the container format of your liking. Most relevant ones (2020) are webm, mkv and mp4.

Answer 8

An option not mentioned yet is -r 30 to limit framerate to 30 fps, or whatever value you like.

Answer 9

I have a recipe I originally forged for myself in order to convert the Motion JPEG videos my old camera generates (they are very large videos, since each frame is an entire JPEG image) to h264. Here's an adaptation for other kinds of videos (courses, etc).

I'm not using ffmpeg, but mplayer and mencoder. First, We have to demux the audio with mplayer:

mplayer -vo null -ao pcm:fast:file=<audio_pcm.wav> <video>

• The -vo null and -ao null parameters tells mplayer to not extract video.

In the next steps, we'll do a 3-pass compression with mencoder. At the first pass we'll choose a suitable Constant Quality Mode compression (crf parameter) as a start point:

mencoder <video> -ovc x264 \ 
         -x264encopts ratetol=100:preset=veryslow:crf=<value>:pass=1 \
         -nosound -o video1.h264

• You can add slow_firstpass parameter to the -x264encopts if you are paranoid with the final quality of the video. Mencoder manual says that this option disable some parameters that “significantly improve encoding speed while having little or no impact on the quality of the final pass”. So, use it only at the last step.

• You should try several values for crf — try starting from 25 and goes on increasing it until you note artifacts at the resulting video (higher values compresses more). Remember subsequent encoding passes will improve the quality you have choosed for crf.

• Alternatives for the veryslow preset are slower, slow, medium etc. See mencoder manual for the complete list.

• ratetol controls the bitrate variation — I'm not sure if I'm doing the right thing here, but I set it to the maximum value in order to let total freedom to mencoder to choose the right bitrate for each scene.

After the first pass, you'll note that the last line gives you the average bitrate you will use at the next steps:

(...)
x264 [info]: kb/s:526.43

Change the crf parameter, recommended at the first pass, to bitrate, required at the subsequent passes:

mencoder <video> -ovc x264 \
       -x264encopts slow_firstpass:ratetol=100:preset=veryslow:bitrate=526:pass=3 \
       -nosound -o video2.h264

This second pass encoding will read the statistics generated at the first pass (divx2pass.log and divx2pass.log.mbtree) in order to optimize the compression.

• Note you'll use the same video input, not the generated by the first pass — first pass' output video is only useful to check the initial quality.

• Note also that the pass=3 (not pass=2) will generate a new statistics file, so you can repeat the last step as many times you want. I usually do pass=3 twice, always paying attention to the result bitrate.

Meanwhile, you can compress the audio too, using lame or oggenc:

oggenc -q<n> <audio_pcm.wav>

Finally, we'll remux audio and video

mencoder -audiofile <audio>.ogg video2.h264 -oac copy -ovc copy \
         -of lavf -lavfopts format=mp4 -o <video>.mp4

• The -of lavf -lavfopts format=mp4 generates mp4 file format using the lavopts muxers.

Answer 10

I wrote a bash script for reducing the size of the video and trying automatically different crf values.

Basically you will

• choose a range of crf values
• run the script
• check the size of the generated videos and pick the one you want

This is really handy when you have a size limit you want to achieve and you don't know what is the crf value which will allow you to do it.

I hope this will help someone. I shared with my colleagues and everyone found it helpful.

#!/bin/bash

# bigger values of crf will lead to a bigger compression (smaller video size)
#for i in 1 2 3 4 5
for i in {25..28}
do
# you can remove the option -y if you want to be asked if to overwrite a file with the same name (leave the -y only if you understand what you are doing, otherwise you might rewrite an important file)
   ffmpeg -y -i NAMEOFTHEVIDEOTOCOMPRESS.mp4 -c:v libx264 -crf $i -preset veryfast -profile:v baseline -level 3.0 -strict -2 out_$i.mp4
   printf "\n>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Done compression at crf=$i \n\n"
done

Answer 11

Here is a 2 pass example: Pretty hard coded, but it really puts on the squeeze

#!/bin/bash

ffmpeg -y
-i "$1" 

-c:v libvpx-vp9 

-pass 1 

-deadline best 

-crf 30 -b:v 664k -c:a libopus 

-f webm /dev/null 

&& ffmpeg 

-i "$1" 

-c:v libvpx-vp9 

-pass 2 

-crf 30 -b:v 664k  -c:a libopus 

-strict 

-2 "$2"

Answer 12

Needed on macOS: to preserve compatibility encoding H.265/HEVC for QuickTime

ffmpeg -i i.mp4 -c:v libx265 -preset fast -crf 28 -tag:v hvc1 -c:a eac3 -b:a 224k o.mp4

Answer 13

I use the mpdecimate filter to reduce the size of my desktop captured videos because there are a lot of duplicated frames to ignore.

The command I use is:

ffmpeg -i original_file.mp4 -vf mpdecimate -vsync vfr -acodec copy mpdecimated.mp4

Answer 14

I want to point out on how you can use hardware acceleration to speed up the encoding process. I have took many parts of the upcoming command from the top answer. Without hardware acceleration, it takes a long time to make the small-sized file, so I used the command: ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i something.mp4 -c:a copy -c:v hevc_vaapi -crf 28 something_else.mp4. Users may need to change vaapi to one of these values: vdpau, dxva2, d3d11va, vaapi, qsv. The driver file for the graphics card may be in a different file too.

Answer 15

I generally use this on a mac. It has helped me convert a 4gb video under 40mb without hardly affecting the quality

ffmpeg -i ~/Desktop/demo.mov -c:v libx264 -crf 23 -c:a aac -strict experimental -b:a 128k ~/Desktop/output_video.mov 

Tip: I understand its hard to remember this command so I have saved this as a keyboard shortcut. Under Settings->Keyboard->text replacements

typing <ffmpeg in a textinput suggest me with this command

Answer 16

RTFM

There is semi-official documentation for exactly what we are trying to do: https://trac.ffmpeg.org/wiki#Encoding

Other's have linked to parts of the FFmpeg wiki but not this particular portion which is what you actually need.

There is also the official documentation, but it's less beginner-friendly.

From there, we're in business. The codec matters a lot, so we have to select the right one for us, the right one always depends on the person and their use case.

H265/HEVC and AV1 are the 'best' codecs, they have the best quality to size ratios. If your only goal is to make the file smaller they are usually the way to go, but support for them is not that great. I believe AV1 provides better compression (but worse overall quality) however it takes orders of magnitude more time to encode with, at least when encoding with the CPU.

H264 and VP9 are the second-best ones, they are the most commonly supported. If you want to upload your videos, if you want them to be playable in apps like discord or signal, you will likely want to use one of these two. The files will be bigger relative to their quality, but you'll be able to play them more or less everywhere.

No other codec than these 4 are really worth considering for our purposes at the time of writing.

Audio codecs also to a lesser degree matter for file size (the longer the file the more it starts to matter), setting the audio codec to libopus is a great option if you want to play with this, it's also necessary if you wish to encode to WebM.

You need to pick a codec based on your needs and follow the encoding guide for it.

Tip: H264 to an .mp4 container is the best configuration for maximum compatibility with everything, it's the closest you'll get to a file that can be played anywhere.

Obtain codec information

You can use

ffmpeg -v 0 -encoders

To list all possible audio and video codec options/all codec variants.

There is a way for ffmpeg to tell you the major options available for any codec, it's this command:

ffmpeg -v 0 -h encoder=codec 

where you replace codec with the codec you want to see options for for instance ffmpeg -v 0 -h encoder=av1 will list most options for all av1 encoders.

If you run:

ffmpeg -v 0 -h encoder='av1' | head -1

It will give you this output:

Encoder libaom-av1 [libaom AV1]:

Which tells us the default software encoder used when you use the -c:v av1 argument is libaom-av1.

Now knowing what encoder is actually being used for software encoding, we can do this:

ffmpeg -v 0 -h encoder='libaom-av1' 

And this will tell us all available options for the default av1 encoder.

If we want the options for some specific other variant, like say hevc_nvenc, we just type in the name of that encoder instead:

ffmpeg -v 0 -h encoder='hevc_nvenc' 

Example Commands

Here are a few generic commands that should work well for most people.

I have excluded AV1 examples because it just takes way too long to process on a CPU and I didn't have the patience for it. I left out hardware encoding VP9 and AV1 because neither of my GPUs support those, so I can't test it.

VP9 is normally supposed to encode in 2 passes but I only do one pass using -crf in conjunction with bv:0 to make it turn out better when done that way. This means there is room for improvement there if you want to use that codec.

All of these example commands are aiming for very high quality, there should be as little perceivable quality loss with these presets as reasonably possible. This means the files will be bigger, to make them smaller you need to adjust the quality value, which is always either -crf or -qp in those commands. A bigger number makes the file smaller at the cost of quality.

Example file 1: 82.1MB, H264/AAC 720p@60fps animation 1.5 minutes.

Example file 2: 96.6MB, H264/AAC 1080p@30fps recording 1.5 minutes.

# Cpu Encoding:

High Quality Hevc
Example file 1: 26.7MB in 39 seconds.
Example file 2: 47.1MB in 35 seconds.
ffmpeg -threads $(awk '/cores/{print $4;exit}' /proc/cpuinfo) -i INPUT_FILE -movflags +faststart -c:a libopus -c:v hevc -crf 17 -preset:v fast OUTPUT_FILE
High Quality Hevc 2D Animation (according to all docs, hevc doesn't support this, but as you can see from my test, it does.)
Example file 1: 21.3MB in 36 seconds.
ffmpeg -threads $(awk '/cores/{print $4;exit}' /proc/cpuinfo) -i INPUT_FILE -movflags +faststart -c:a libopus -c:v hevc -crf 17 -preset:v fast -tune:v animation OUTPUT_FILE
High Quality 264
Example file 1: 31.9MB in 14 seconds.
Example file 2: 88.9MB in 25s
ffmpeg -threads $(awk '/cores/{print $4;exit}' /proc/cpuinfo) -i INPUT_FILE -movflags +faststart -c:a copy -c:v hevc -crf 17 -preset:v fast OUTPUT_FILE
High Quality 264 2D Animation
Example file 1: 31MB in 17 seconds.
ffmpeg -threads $(awk '/cores/{print $4;exit}' /proc/cpuinfo) -i INPUT_FILE -movflags +faststart -c:a copy -c:v h264 -crf 17 -preset:v fast -tune:v animation OUTPUT_FILE
High Quality VP9
Example file 1 (-cpu-used 4): 42.7MB in 2 minutes 12 seconds.
Example file 1 (-cpu-used 1): 39.4MB in 3 minutes 42 seconds.
Example file 2 (-cpu-used 4): 58.7MB in 2 minutes 44 seconds.
Example file 2 (-cpu-used 1): 53.2MB in 5 minutes 21 seconds.
ffmpeg -i INPUT_FILE -cpu-used 1 -movflags +faststart -c:a libopus -c:s webvtt -c:v vp9 -crf 17 -preset 5 -aq-mode 2 -b:v 0 OUTPUT_FILE.webm
Hardware Encoding:
High Quality HEVC Nvenc
Example file 1: 32.3MB in 19s
Example file 2: 62.5MB in 21s
ffmpeg -i INPUT_FILE -movflags +faststart -c:a libopus -c:v hevc_nvenc -spatial-aq 1 -multipass fullres -tune:v hq -rc:v constqp -qp 19 -preset:v p7 OUTPUT_FILE
High Quality H264 Nvenc
Example file 1: 39.4MB in 20s
Example file 2: 91.6MB in 19s
ffmpeg -i INPUT_FILE -movflags +faststart -c:a libopus -c:v hevc_nvenc -spatial-aq 1 -multipass fullres -tune:v hq -rc:v constqp -qp 19 -preset:v p7 OUTPUT_FILE
High Quality HEVC VAAPI
Example file 1: 41MB in 9s
Example file 2: 59.6 in 8s
ffmpeg  -i INPUT_FILE -movflags +faststart -vf format=nv12,hwupload -pix_fmt vaapi -c:a libopus -c:v hevc_vaapi -vaapi_device /dev/dri/renderD128 -rc_mode CQP -qp 20 OUTPUT_FILE
High Quality H264 VAAPI
Example file 1: 39.4MB in 15s
Example file 2: 53.7 in 14s
ffmpeg  -i INPUT_FILE -movflags +faststart -vf format=nv12,hwupload -pix_fmt vaapi -c:a libopus -c:v h264_vaapi -vaapi_device /dev/dri/renderD128 -rc_mode CQP -qp 20 OUTPUT_FILE

Setting the audio codec to libopus saves me about 300-500KB on filesize, but it is also lowering the bitrate and quality of the audio.

My example files are already very poorly optimized, so for you, you might not see as much reduction when running these commands, in fact it might get bigger instead worst case scenario (this would mean your file is already quite optimized).

For -crf ideally stay within a range of 18-28 with 18-20 still being very high quality and 21-23 still very decent.

For vaapi I used one of the worst available methods (CQP), it's better to use QVBR or ICQ, which you can use instead of CQP by replacing -rc_mode CQP -qp 20 with -rc_mode ICQ -qp 20 where 20 is the quality setting (lower number = higher quality). The reason I didn't include those methods in the example is that QVBR is a lot more complicated than the other methods in use, and ICQ isn't supported by my drivers.

If you're confused on how to use vaapi, here is a short guide to get vaapi working if you have problems with it.

Option Cheatsheet

It's time to learn how to fish. Every option matters. Every option here is something that could potentially reduce filesize for you.

• -c:v Allows you to select the video codec, run ffmpeg -v 0 -encoders | grep "^ V" to find possible options.
• -c:a Allows you to select the audio codec, run ffmpeg -v 0 -encoders | grep "^ A" to find possible options. Common options include aac, libopus, ac3, libvorbis, flac and libmp3lame. You can also set it to copy to copy the audio directly from the source (no re-encoding it).
• -qp Is a setting that directly controls frame quality, and it sticks to that setting from start to finish (every frame will have the same quality). It's only recommended to use this option for codecs that do not support -crf. If -crf is unavailable you can sometimes use this in conjunction with -rc:v (Rate Control) setting to get decent results, ICQ and QVBR tend to give the best results if available, with them -qp may even be better than -cfr.
• -crf does the same thing as -qp except that it adjusts the frame quality based on the frame content, this leads to better compression at no perceivable loss of quality. If you want very high quality results, you set it to 17-18, if you want good quality you set it to 21-23 if you don't care all that much about quality you can go up to 28. This is usually recommended over -qp if it is available (it's not always available)
• -preset is an option that controls how meticulously the quality to size ratio will be handled (this does not mean slower presets always produce smaller files, they can be bigger, but their quality will be higher relative to size). So you will have a higher quality and better compression ratios with the slower presets, whereas the faster presets will encode faster. for CPU H264 and HEVC the options are 1-7 or: veryslow,slower,slow,medium,fast,faster,veryfast. Some codecs and some variants either do not support this option or have different available options.
• -tune is an option for H264,HEVC (and av1 but less useful for that) that can dramatically reduce filesize at no perceivable quality loss when correctly configured, however each codec supports a different set of options for this setting. You can read the ffmpeg docs for encoding with each codec on what these options are, or you can use x264 --fullhelp or x265 --fullhelp, Some tune options also have additional settings specifically to tweak them further.
• -b:v Allows you to manually define the video bitrate, it's an older method compared to qp and crf and usually inferior too. For VP9 this setting controls average bitrate instead, which is slightly better. To use -crf this way with VP9 -b:v 0 must be set, otherwise it works a little different.
• -b:a Allows you to manually define the audio bitrate, it can be useful to reduce filesize, a value of 128k is a good compromise
• -r Sets the framerate (fps), if you have a 60fps video and you use -r 30 it will shave down the video size by half, the standard framerate for film and tv is 24, this is the lowest I can recommend setting this unless you're dealing with animation, animation is usually done at far lower framerates, such as anime for instance tends to be done at 8-12fps, for animation you can experiment with such lower values.
• -vf/-lavfi/-filter_complex are 3 separate commands for roughly the same thing, it's to allow you to build a filter graph, this is a tool for pre and post-processing. The format is -vf "filter,filter2=stuff,filter3" although the quotation marks are not typically necessary (only if there are spaces or weird symbols in an argument do you need them).
• -vf scale=N:N allows you to rescale the video, for example -vf scale=-1:720 rescales video to 720p. You can also scale a video down based on it's size, it was explained in another answer.
• -vf mpdecimate removes duplicate frames, it can in some cases lead to a dramatic filesize reduction with no perceivable visual quality loss, for instance if I use this while converting a clip to a GIF with ffmpeg, it produces a smoother GIF that is significantly smaller than otherwise, an actual quality upgrade. In most cases though it will lead to a mild perceivable drop in quality. For more advanced application you can read a guide on mpdecimate.
• -max_frame_size sets the maximum size per frame in bytes, this is a rather niche setting I don't believe very many people use it but it can be used to set a hard limit for the filesize (e.g. you count the frames in the file, divide the desired maximum size in bytes between those frames, and then set the result as -max_frame_size) I haven't personally tested this option yet, there might be untapped potential here.
• -aq-mode 2 improves quality and compression rate at the cost of time for AV1 and VP9.
• -spatial-aq 1 improves quality by adjusting -qp based on spatial characteristics, it also tends to mildly improve the overall compression for AV1 and HEVC_NVENC and H264_NVENC.
• -multipass fullres increases quality at the cost of time for AV1 and HEVC_NVENC and H264_NVENC.

Some other important options:

• -threads controls the number of threads used for CPU encoding with H264 and HEVC. I recommend setting this value to the number of physical cores you have or less. awk '/cores/{print $4;exit}' /proc/cpuinfo tells you the number of physical cores you have. Increasing the number of threads increases the speed, but once you pass a certain number of threads the speed starts decreasing instead due to the overhead of managing the extra threads. The number of physical cores is usually the cutoff point.
• -cpu-used is what VP9 and AV1 use instead of -threads, however increasing the number reduces quality and only supports a maximum value of 8, provides diminishing returns beyond 4 and reduces compression too. Setting this to 8 was slower than 4, even on a machine with 16 physical cores.
• -profile:v is a setting for H264 and HEVC that controls the profile used by the codec, by default this is automatically configured but you can use it if you want to encode in a specific profile like high10 or baseline. Setting specific profiles can affect filesize but it's somewhat situational.
• -pfmt is a universal setting for the pixel format, it functions somewhat similar to profile. And is usually best left unconfigured or set to + for auto. Like with profiles it's situational.

Helpful options (these don't affect filesize):

• -movflags +faststart this places the moov atom at the start of the file instead of the end which is great for compatibility, especially for web-based video players.
• -c:s subtitle codec. .webm only supports webvtt, .mp4 only supports mov_text, this is a necessary setting to carry softsubs over to those formats.
• -vf "subtitles=INPUT_FILE:force_style=Fontsize=24" convert softsubs to hardsubs, this way you can make the subtitles show up in your .mp4 files when uploading them online.

Answer 17

Edit: Sorry first time on this platform, seems like i've posted this in the Unix/Linux subdomain, this post can be deleted or left here since the math still applies to the solution the same anywhere.

I've been working on a Powershell script that automatically reduces filesize of a given video to a specific size entered in MB.

It works by reencoding the given video to a calculated size using ffprobe and ffmpeg and a lot of finetuning to get it just right and save on encoding time if possible and wanted by the user or it'll leave the encoder at VP9 which is the default to increase quality instead.

The Link to it here which includes a lot of other nice to have stuff: github.com/xMorioh/Script-Collection

but the current code posted here to provide it in this thread for preservation:

param (

#-----Dependencies-----
This Script requires ffmpeg as well as ffprobe, both can be found here: https://github.com/BtbN/FFmpeg-Builds/releases/download/latest/ffmpeg-master-latest-win64-gpl.zip
[string]$ffmpegPath = "$PSScriptRoot\ffmpeg.exe",
[string]$ffprobePath = "$PSScriptRoot\ffprobe.exe",
#-----User Settings-----
[string]$inputVideo = "A:\input.*", #No need to specify the file extension
[string]$outputPath = "A:\output.mp4",
[int]$targetVideoSize_megabytes = 50,
[string]$encoder = "libvpx-vp9" #Choose your prefered Encoder Library, for example x264=libx264, VP9=libvpx-vp9, AV1=libsvtav1 | libaom-av1
)
#-----Script internals-----
$inputVideo = Get-ChildItem -Path $inputVideo #search for file extension via input name
$probedFileDuration = Invoke-Expression "&'$ffprobePath' -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 '$inputVideo'"
#Try to get Video Stream bitrate, catch if containers like MKV are in use which do not support stream metadata embedding
#To mitigate streamless container size overflow of the final size, we subtract 10% here which worked best so far.
try {
[float]$probedFileVideoBitrate = Invoke-Expression "&'$ffprobePath' -v error -select_streams v:0 -show_entries stream=bit_rate -of default=noprint_wrappers=1:nokey=1 '$inputVideo'"
}
catch {
[float]$probedFileVideoBitrate = Invoke-Expression "&'$ffprobePath' -v error -show_entries format=bit_rate -of default=noprint_wrappers=1:nokey=1 '$inputVideo'"
$targetVideoSize_megabytes = ($targetVideoSize_megabytes * 0.9)
}
[float]$probedFileVideoBitrate_kbit = $probedFileVideoBitrate * 0.001
#Try to get Audio Stream bitrate, catch if containers like MKV are in use which do not support stream metadata embedding
#If Stream could not be found then Audio is embedded in the Video Stream or not present at all
try {
[float]$probedFileAudioBitrate = Invoke-Expression "&'$ffprobePath' -v error -select_streams a -show_entries stream=bit_rate -of default=noprint_wrappers=1:nokey=1 '$inputVideo'"
}
catch {
[float]$probedFileAudioBitrate = 0
}
[float]$AudioSize_megabytes = (($probedFileAudioBitrate * $probedFileDuration) / 8388608)
[float]$targetFileSize_kbit =  (($targetVideoSize_megabytes - $AudioSize_megabytes - 1) * 8192)
[float]$OutputBitrate_kbit = $targetFileSize_kbit / $probedFileDuration
Write-Host "-----DEBUGGING START-----"
Write-Host
if ($probedFileAudioBitrate -eq 0) {
Write-Host "Audio is embedded in the Video Bitrate due to a format being used that does not support stream based metadata embedding"
}
Write-Host
Write-Host "probedFileDuration                    :" $probedFileDuration
Write-Host "probedFileVideoBitrate                :" $probedFileVideoBitrate
Write-Host "probedFileVideoBitrate_kbit           :" $probedFileVideoBitrate_kbit
Write-Host "probedFileAudioBitrate                :" $probedFileAudioBitrate
Write-Host "AudioSize_megabytes                   :" $AudioSize_megabytes
Write-Host "targetFileSize_kbit                   :" $targetFileSize_kbit
Write-Host "OutputBitrate_kbit before Optimization:" $OutputBitrate_kbit
#-----Optimizations-----
#Limit kbit to the original videos kbit if it's lower than our calculation since wizards do not actually exist and the gain would be too small if any.
if ($OutputBitrate_kbit -gt $probedFileVideoBitrate_kbit) {
$OutputBitrate_kbit = $probedFileVideoBitrate_kbit
}
#--Check if we can use libx264 instead to save on encoding time if the exact same quality can be achieved in our targetVideoSize, we do not change $OutputBitrate_kbit here we still use target max kbit.
[int]$probedFileVideoWidth = Invoke-Expression "&'$ffprobePath' -v error -select_streams v:0 -show_entries stream=width -of default=noprint_wrappers=1:nokey=1 '$inputVideo'"
[int]$probedFileVideoHeight = Invoke-Expression "&'$ffprobePath' -v error -select_streams v:0 -show_entries stream=height -of default=noprint_wrappers=1:nokey=1 '$inputVideo'"
[int]$probedFileVideoPixels = ($probedFileVideoWidth * $probedFileVideoHeight)
[string]$probedFileVideoFPS = Invoke-Expression "&'$ffprobePath' -v error -select_streams v:0 -show_entries stream=r_frame_rate -of default=noprint_wrappers=1:nokey=1 '$inputVideo'"
$probedFileVideoFPSMultiplier = [Data.DataTable]::New().Compute($probedFileVideoFPS, $null) / 30
#Info: 0.00125 = ((((Baseline kbit (500kbit) / 1280*720 assuming the 500Kkbit are good for a 30fps video at that resolution) * 2) + 10%) to get a base quality number meaning kbit for each pixel per second @30fps
#*2 + 10% = x2 is for the x264 codec uplift since VP9 has around 50% better quality compared and then just 10% on top for good measure + rounding up, $probedFileVideoFPS right below here is for 30fps to 60fps when 500kbit look good at 30fps.
$x264Check_kbit = (0.00125 * $probedFileVideoFPSMultiplier) * $probedFileVideoPixels
$x264Check_megabytes = (((($x264Check_kbit * $probedFileDuration) / 8192) + 1) + $AudioSize_megabytes)
if ($x264Check_megabytes -lt $targetVideoSize_megabytes) {
$encoder = "libx264"
}
#--Check end
#Limit kbit for user set encoder, this way we can get away with a much lower filesize in some scenarios
elseif ($OutputBitrate_kbit -gt 10000) {
$OutputBitrate_kbit = 10000
}
#-----------------------
Write-Host "OutputBitrate_kbit after Optimization :" $OutputBitrate_kbit
Write-Host "-----DEBUGGING END-----"
Invoke-Expression "
$ffmpegPath -i '$inputVideo' -c:v $encoder -b:v $($OutputBitrate_kbit)k -pass 1 -an -row-mt 1 -f null NUL
$ffmpegPath -i '$inputVideo' -c:v $encoder -b:v $($OutputBitrate_kbit)k -pass 2 -c:a copy -row-mt 1 '$outputPath'
"