In this part 9 is the findings based on averages between the input codec type, deadline and cpu used parameters for speed, size and bitrate.

Part 1 was h264 -deadline good.

Part 2 was h264 -deadline realtime.

Part 3 was h264 with -deadline good compared to -deadline realtime.

Part 4 was h265 -deadline good.

Part 5 was h265 -deadline realtime.

Part 6 was h265 with -deadline good compared to -deadline realtime.

Part 7 was both h264 and h265 (hevc) -deadline good compared to -deadline realtime.

Part 8 was averages when grouping h264 and h265 parameters.

Two codecs; h264 compared to h265 (hevc)

Comparing the h264 input with the h265 when encoding to WebM VP9 has h265 on average 11,000 KB smaller but 6 seconds longer on the encoding. Bitrate is 3,000 kbit/s more with the h264 codec. ^source

codecs and deadlines

-deadline good with h264 brings an average smaller file size and a much quicker encoding time when compared to -deadline realtime average with h264. This is surprising considering the realtime deadline is stated as “recommended for live / fast encoding”. The smaller file size also means slightly less bitrate, this could potentially mean a more efficient encode.

With h265 (hevc) similar patterns are seen. -deadline good on average is smaller and faster than a realtime deadline. ^source

codecs and cpu used

-cpu-used 5 for both h264 and h265 is over 50% quicker than the -cpu-used 0 average, with only ~10,000 KB file size increase. The -cpu-used parameter is the trade-off between speed and encoding quality, this is apparent with a quicker encode and larger file size from a lower -cpu-used value to a higher one.

Through the tables and charts you cannot determine quality however the size, bitrate and seconds encoding values reveal the encoding efficiency as faster encoding cannot be more effective than a slower one.^source1

Its a balancing act between time and the output size/bitrate. Getting a faster encode isn’t always a win especially if the file size is drastically larger.

codecs, deadline and cpu used

These averages further displays the smaller file size but longer encode with the h265 input file. H264 with a deadline of good produces the faster encoding to WebM with a higher bitrate and file size when compared to h265 (hevc).^source2

The tables supplied in the source links are averages only. An example being the row for h264, deadline good and cpu 0 is the average including crf values 15 – 30.

The size + seconds chart has hevc -deadline good as the shortest tower most of the time.