Mdthbs

Unless you're looking for a specific bitrate, I'd recommend the -crf option. This is the most commonly used for x264 encoding: http://slhck.info/articles/crf

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

You mentioned wanting to reduce filesize to fit more videos on a mobile device, which is my usecase as well. All the answers here are for reducing the compression quality but nobody has mentioned reducing video frame size. It's a lot quicker, from about 3 to 5 times quicker than recompressing in my experience. See the ffmpeg docs on scaling for more info.

ffmpeg -i input.mkv -vf "scale=iw/2:ih/2" half_the_frame_size.mkv

ffmpeg -i input.mkv -vf "scale=iw/3:ih/3" a_third_the_frame_size.mkv

ffmpeg -i input.mkv -vf "scale=iw/4:ih/4" a_fourth_the_frame_size.mkv

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.

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.

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.

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

You'll need to use 2-pass encoding to "fit" a video within a designated file size (bitrate), without reducing the quality too drastically. This is quite a detailed topic: http://web.archive.org/web/20171130050515/http://www.mpabo.com/2014/12/14/ffmpeg-and-x264-encoding-guide/