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.
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
-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
-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.
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.
A drained and empty Kennington reservoir images from a drone in early July 2024. The…
Merrimu Reservoir from drone. Click images to view larger.
Using FTP and PHP to get an array of file details such as size and…
Creating and using Laravel form requests to create cleaner code, separation and reusability for your…
Improving the default Laravel login and register views in such a simple manner but making…
Laravel validation for checking if a field value exists in the database. The validation rule…