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

[Shi Qiu]

Thanks Zak,

I think the problem may related to the OS or the driver. I used the same
input media (1080P video) on Windows 7, H264 encoder(240fps) is much faster
than H265 encoder(80fps).

After some tests, I've found that the problem is that SKL H264 encoder
(100fps) is quite slow with old vaapi driver, even slower than H264 encoder
HSW(250 fps). After I updated to the lastest vaapi driver, SKL H264
encoders (200fps) is still slower than that on HSW(250fps).

I'll dig into the vaapi driver to see if things work well.

You mentioned the audio codec, I don't know much about that, but maybe some
parameters in video codec also have deep impact on the  encoding speed.

Regards,

Shi Qiu

On Thu, Feb 8, 2018 at 11:35 AM, Zak <ffmpeg-user-email at m.allo.ws> wrote:

> 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".
>>
>
> _______________________________________________
> 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".