[FFmpeg-user] Why H264 Encoder is slower than H265 Encoder?

[Zak]

Hello Shi Qiu,

I have two thoughts:

1. Is that the best possible experiment with only one variable changed 
between the two cases? It looks like the input format changed, too, 
although the filenames are possibly fake simple examples (simplicity is 
good). The H264 output has a.h264 as the input and the H265 output has 
a.h265 as the input file. Even if the contents should be the same, for 
instance if they are the same short film, the a.h265 file may be 
significantly easier to compress for some reason. I would do the 
experiment with a totally different video format, maybe VP9, and use the 
exact same input file for both output formats.

2. Algorithms that have seen more development attention in the recent 
past are often faster than older algorithms, even if in theory the older 
algorithm should be simpler to implement. This is because recent 
attention often means optimizations. In the case of H.265, I'm not sure, 
but aren't there special CPU instructions on recent Intel processors? 
There are other ways to optimize code if you have time and money. A good 
example that you can see in ffmpeg is the LAME library (libmp3lame) 
compressing 320 kbps CBR (constant bitrate) versus V0 VBR (variable 
bitrate) MP3 outputs. 320 kbps CBR and V0 VBR are the highest-quality 
CBR and VBR formats, respectively. The CBR algorithm is older. The VBR 
algorithm is newer, has seen more recent development attention, and is 
about 5 times faster in my tests on MacOS 10.12 and Kubuntu 17.04. Here 
are the tests I used:

# Output 320 kbps CBR:

ffmpeg -i Exact_same_song.flac -codec:a libmp3lame -b:a 320k 
-map_metadata 0 output.mp3

# Output V0 VBR, about 260 kbps average depending on input:

ffmpeg -i Exact_same_song.flac -codec:a libmp3lame -q:a 0 -map_metadata 
0 output.mp3

You get the same result if you use the LAME CLI directly, but you need 
to make a WAV file for input first (perhaps with ffmpeg):

# Output 320 kbps CBR:

lame -b 320 -q 0 -T --id3v2-only --tt "Song" input.wav output.mp3

# Output V0 VBR:

lame -V0 -q 0 -T --id3v2-only --tt "Song" input.wav output.mp3

I included metadata in both cases, ffmpeg and LAME CLI, because if an 
ID3 tag is not needed then it will not write the Xing (VBR) or Info 
(CBR) header in the MP3. Inspecting this header, it is not entirely 
clear, but it looks like ffmpeg does not use -q 0. ffmpeg probably used 
-q 3, which is the default, and this may explain why ffmpeg was faster. 
-q 0 tells the encoder to use the highest-quality and slowest 
algorithms. In both cases, VBR (the newer but more complex algorithm) is 
about five times faster than CBR (the older and simpler algorithm).

If anyone is curious, 320 kbps output gets a little faster every single 
time you decrease the quality (-q 0 is 14 minutes encoding time for a 
1-hour sound file, -q 1 is 7 minutes (twice as fast), -q 2 is 6 minutes, 
-q 3 is 3.5 minutes, and so on), but VBR output only gets faster when 
you pass certain values of -q n. To be specific, -q 0, -q 1, and -q 3 
seem to be totally identical, and -q 7, -q 8, and -q 9 are also 
identical, it seems. Even at -q 0, VBR is extremely fast compared to 
CBR, and it only gets faster as you turn down the quality.

Regards,

Zak

On 2/7/18 8:41 PM, Shi Qiu wrote:
> OS: Ubuntu 16.04 64bit
> CPU: intel i7 6700
>
> H264:
> ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device
> /dev/dri/renderD128 -i a.h264 -c:v h264_vaapi -f h264 t.h264 -y
>
> 108fps
>
> H265:
> ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device
> /dev/dri/renderD128 -i a.h265 -c:v hevc_vaapi -f hevc t.h265 -y
>
> 126fps
>
> Any ideas?
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".