Since 2013 a video format much better than H.264 is widely available, namely H.265 (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. libx265 need more time for me doing.
ffmpeg -i input.mp4 -vcodec libx265 -crf 28 output.mp4
original size from instagram = 15,2 MB duration 47 seconds
-vcodec libx265 -crf 28 = 11,3 MB (tetapi ini prosesnya lamban)
-vcodec libx264 -crf 24 = 22,6 MB (prosesnya cepat)
-vcodec libx264 -crf 28 = 15,5 MB (prosesnya medium)
To see this technique applied using the older H.264 format,
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.mp4Additional 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
Used ffmpeg -i input.avi -vcodec libx264 -crf 24 output.avi. It reduced a 100mb video to 9mb.. Very little change in video quality. Thank you!
To scale to half size:
ffmpeg -i input.mkv -vf "scale=trunc(iw/4)*2:trunc(ih/4)*2" -c:v libx265 -crf 28 half_the_frame_size.mkv
One-third size:
ffmpeg -i input.mkv -vf "scale=trunc(iw/6)*2:trunc(ih/6)*2" -c:v libx265 -crf 28 a_third_the_frame_size.mkv
One-quarter size:
ffmpeg -i input.mkv -vf "scale=trunc(iw/8)*2:trunc(ih/8)*2" -c:v libx265 -crf 28 a_fourth_the_frame_size.mkv
One-fifth size:
ffmpeg -i input.mkv -vf "scale=trunc(iw/10)*2:trunc(ih/10)*2" -c:v libx265 -crf 28 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. Be aware that changing the resolution always requires re-encoding, so all the ins and outs of the other answers apply here as well.
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.
Constant Rate Factor (CRF) adalah pengaturan kualitas (dan kontrol kecepatan) default untuk encoder x264 dan x265, dan juga tersedia untuk libvpx. Dengan x264 dan x265, Anda dapat mengatur nilai antara 0 dan 51, dimana nilai yang lebih rendah akan menghasilkan kualitas yang lebih baik, dengan mengorbankan ukuran file yang lebih tinggi. Nilai yang lebih tinggi berarti kompresi yang lebih besar, namun pada titik tertentu Anda akan melihat penurunan kualitas.
With ffmpeg, it’d look like this:
ffmpeg -i input.mp4 -c:v libx264 -crf 23 output.mp4
For x265, the default CRF is 28:
ffmpeg -i input.mp4 -c:v libx265 -crf 28 output.mp4
For libvpx, there is no default, and CRF can range between 0 and 63. 31 is recommended for 1080p HD video:
ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 31 -b:v 0 output.mkv
If you’re unsure about what CRF to use, begin with the default and change it according to your subjective impression of the output. Is the quality good enough? No? Then set a lower CRF. Is the file size too high? Choose a higher CRF. A change of ±6 should result in about half/double the file size, although your results might vary.
You should use CRF encoding primarly for offline file storage, in order to achieve the most optimal encodes. For other applications, other rate control modes are recommended. In video streaming, for example, CRF can be used in a constrained/capped mode to prevent bitrate spikes.
