These averages further displays the smaller file size but longer encode with the h265 input file. Getting a faster encode isn’t always a win especially if the file size is drastically larger. Its a balancing act between time and the output size/bitrate. 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. 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. 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. deadline good on average is smaller and faster than a realtime deadline. With h265 (hevc) similar patterns are seen. The smaller file size also means slightly less bitrate, this could potentially mean a more efficient encode. This is surprising considering the realtime deadline is stated as “recommended for live / fast encoding”. deadline good with h264 brings an average smaller file size and a much quicker encoding time when compared to -deadline realtime average with h264. Bitrate is 3,000 kbit/s more with the h264 codec. Two codecs h264 compared to h265 (hevc)Ĭomparing 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. Part 8 was averages when grouping h264 and h265 parameters. Part 7 was both h264 and h265 (hevc) -deadline good compared to -deadline realtime. Part 6 was h265 with -deadline good compared to -deadline realtime. Part 3 was h264 with -deadline good compared to -deadline realtime. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |