Use the ffmpeg command line to invert the video sample code

Before you begin the text of this article, you first need to install the ffmpeg program (under Linux you also need to install the x264 encoding). Install brew directly under Mac:

brew install ffmpeg --with-faac --with-fdk-aac --with-ffplay --with-fontconfig --with-freetype --with-libass --with-libbluray --with-libcaca --with-libsoxr --with-libquvi --with-frei0r --with-libvidstab --with-libvorbis --with-libvpx --with-opencore-amr --with-openjpeg --with-openssl --with-opus --with-rtmpdump --with-schroedinger --with-speex --with-theroa --with-tools --with-x265

MP4 file can be suppressed using ffmpeg:

ffmpeg -i MVI_7274.MOV -vcodec libx264 -preset fast -crf 20 -y -vf "scale=1920:-1" -acodec libmp3lame -ab 128k a.mp4

Parameters as follows (reference from this and come, have modified: https: / / vistb net / 2012/02 / x264 - video - compress intro /) :

-preset: Specifies the configuration of the encoding. x264 encoding algorithm has many configurable parameters, different parameter values will lead to a wide range of encoding speed, and may even affect the quality. To save the user the trouble of knowing the algorithm and manually configuring the parameters. x264 provides a set of presets that can be specified via preset. These presets include: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow and placebo. ultrafast is the fastest, but has a lower compression rate and produces larger files, while placebo is the opposite. The default value for x264 is medium. It should be noted that preset mainly affects the speed of coding and does not greatly affect the quality of the encoded results. For compressed HD movies, I usually use slow or slower. You can also use veryslow if you have a good machine, but it's not a big benefit.

-crf: This is the most important option to specify the quality of the output video. The range of values is 0-51. The default value is 23. This option directly affects the bitrate of the output video. Generally speaking, for 480p I would use around 20, for 720p I would use 16-18, and for 1080p I haven't tried. Personally, 1 is usually not necessary to be less than 16. The best way is that you can try several values, each press for a few minutes, see the final output quality and file size, and then choose according to your needs.

There are also arguments for -b 1024k, but I found that -crf didn't work when set to -crf. According to my own simple attempt, the relationship between crf and an 18-second video of 1920x1080 shot by 5D2 (natural light in the afternoon, simple image, large area of white wall, and only 1 black door) and the size of the pressed file is as follows:

crf	文件大小
16	54M
18	39M
20	25M
22	17M
24	11M
26	7.3M
28	5.0M
30	3.6M
32	2.7M
默认	14M（crf为23）

After comparing the video quality of crf on 20, 28 and 32, it is found that the quality of 32 can still be seen to decline. 20 is really very fine, but the difference between 28 and 20 is not that big. It is better to set the value of crf between 26 and 28. If you have a size requirement, leave it at nothing and use the default (probably 31).

In addition, preset, slow and fast are only related to the running time. slow runs much longer than fast. slow produces mp4 files that are smaller (12M) and fast produces files that are larger (14M), but the difference in video quality is not obvious.

If the original video size is reduced from 1920x1080 to 960x540, the video size is changed to:

crf	文件大小
16	11M
18	6.7M
20	4.4M
22	3.0M
24	2.1M
26	1.6M
28	1.3M
30	1.1M
32	893K
默认	2.5M（crf为23）

In summary, when the quality requirement is high, choose 22 or less; When the size is very high, choose 26 (but the quality is indeed slightly worse 1), otherwise choose 24 cost-effective relatively high (or the default 23 is also OK), if the size is very, very high, it is more than 28.

Postscript Supplement (from @gghyoo)

You can use -threads n To implement multi-threaded operation, make full use of multi-core cpu

Examples are as follows:

ffmpeg -threads 2 -crf 20 -y -i ML-02.avi -strict experimental ML-02.mp4

conclusion