ffmpeg libx264 libx265 encode duration.

posted in: 2160p, ffmpeg, H264, HEVC, VLC | 2

The version of ffmpeg used for this experiment is:
ffmpeg version N-77137-gff6dd58 Copyright (c) 2000-2015 the FFmpeg developers -- built with gcc 5.2.0 (GCC)

The following -presets were used to measure the running times:
ultrafast  superfast  veryfast  faster  fast  medium  slow  slower  veryslow

    The basic idea behind this test was to determine encoding duration of each preset using ffmpeg. These results are not far from real world examples, it goes to show that x265/hevc still needs more work to catch up to x264/h264. The tests were run on a Windows 10 machine, they were the only big thing chewing down on compute time other than the OS itself. Below you will see the specifications of the video used. The location to get it should you need it [[ Source ]]

Video Specs:
Movie name : Big Buck Bunny, Sunflower version
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 10mn 34s
Bit rate : 7500 Kbps
Maximum bit rate : 37.8 Mbps
Width : 3840 pixels
Height : 2160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive

Here is a line used in both x264 and x265. This was repeated for all 9 presets.
ffmpeg -i bbb_sunflower_2160p_30fps_normal.mp4 -c:v libx264 -preset ultrafast -b:v 2M -minrate 2M -maxrate 2M -an -report -benchmark BBB_H264_2160p_ULTRAFAST-2M.mkv
ffmpeg -i bbb_sunflower_2160p_30fps_normal.mp4 -c:v libx265 -preset ultrafast -b:v 2M -minrate 2M -maxrate 2M -an -report -benchmark BBB_H265_2160p_ULTRAFAST-2M.mkv

The first test for both encoders, -preset ultrafast:
BBB_H264_2160p_ULTRAFAST-2M.mkv — bench: utime=1809.656s
BBB_H265_2160p_ULTRAFAST-2M.mkv — bench: utime=8644.000s

-preset superfast
BBB_H264_2160p_SUPERFAST-2M.mkv — bench: utime=2602.531s
BBB_H265_2160p_SUPERFAST-2M.mkv — bench: utime=10988.734s

-preset veryfast
BBB_H264_2160p_VERYFAST-2M.mkv — bench: utime=3430.766s
BBB_H265_2160p_VERYFAST-2M.mkv — bench: utime=13521.844s

-preset faster
BBB_H264_2160p_FASTER-2M.mkv — bench: utime=5833.734s
BBB_H265_2160p_FASTER-2M.mkv — bench: utime=13548.281s

-preset fast
BBB_H264_2160p_FAST-2M.mkv — bench: utime=6543.656s
BBB_H265_2160p_FAST-2M.mkv — bench: utime=20486.453s

-preset medium
BBB_H264_2160p_MEDIUM-2M.mkv — bench: utime=7043.109s
BBB_H265_2160p_MEDIUM-2M.mkv — bench: utime=29292.734s

-preset slow
BBB_H264_2160p_SLOW-2M.mkv — bench: utime=11032.672s
BBB_H265_2160p_SLOW-2M.mkv — bench: utime=88890.312s

-preset slower
BBB_H264_2160p_SLOWER-2M.mkv — bench: utime=14856.125s
BBB_H265_2160p_SLOWER-2M.mkv — bench: utime=198312.156s

Final -preset veryslow
BBB_H264_2160p_VERYSLOW-2M.mkv — bench: utime=35074.203s
BBB_H265_2160p_VERYSLOW-2M.mkv — bench: utime=281680.375s

    Looking at the final numbers, x264 finishes its encode in 9.7hrs, x265 gets done in 78.24hrs!!! More compute time is required for x265, more compute power is required to playback x265 files. Although, after checking the footage, a faster x265(13548.281s) looks better than a slower x264(14856.125s), there is less blocking on the x265 footage.
    Here are a few shots, side by side, for science. You can of course open images in a new tab for a larger version. I have attached a compressed zip archive with all rendered files, the generated ffmpeg logs and the sample shots in this post for your convenience. [[ Link — 2.6GB ]]

*** These are only experiments, there are bound to be errors somewhere ***

2 Responses

  1. Axe

    FYI ‘bench: utime’ is not ‘real’ time that you get from ‘time’ in bash or the ‘actual elapsed time’. It is the equivalent of ‘user’ time from time in bash, and especially is more than real time in the case that the program is multithreaded or utilizes multicores.

    TL;DR : bench: utime=35074.203s doesn’t mean it took 584m.56s to run the process, it is the amount of CPU time spent in user-mode code (outside the kernel) within the process. This is only actual CPU time used in executing the process.

    • oneLastTime

      So even if the same procedure was applied to both x264 and x265. The numbers are larger on x265… would that not mean that more cpu time is needed which also adds more time for overall encode?

Leave a Reply

Your email address will not be published. Required fields are marked *