I’ve noticed that YouTube transcodes my videos after I upload them and wanted to know more. It turns out that they are internally using a form of h.265 video encoding, which reduces the data size significantly without reducing perceived quality over h.264 video compression.
I decided to run some tests using my GoPro time lapse program to see how much compression I’d get versus how much extra time for encoding.
First I had to read up on the settings for using h.265 in FFmpeg. According to https://trac.ffmpeg.org/wiki/Encode/H.265, If I add -c:v libx265 into my existing FFmpeg command line without changing anything, I’ll get an h.265 output with the defaults of -crf 23 and -preset medium.
The -preset value effects how much work is done in the compression, but shouldn’t affect the perceived quality. It will effect both time to create and output file size.
The -crf value effects the perceived quality. I’ve been using the defaults in my previous h.264 mp4 files, which should be approximately -crf 23 and supposedly -crf 28 in h.265 is equivalent to the lower h.264 value. A -crf 0 would be a completely lossless conversion. For my tests, I left crf at the default 23.
I ran all of these tests on a set of 7,129 photos I’d captured while sailboat racing on March 24th using my GoPro Hero 3+ Black. Each input image was 4000×3000 and I’m creating an output video with resolution 3840×2160 by cropping it at 3/4 of the height and scaling to fit.
The original h.264 conversion took 28:36 minutes to create and was 1,162,079,866 bytes long.
Here’s a trimmed down and sorted file listing. The first column is the time it took to create, second is filesize, and third is filename.
28:36 1,162,079,866 20180324-2160p30-cropped-h264.mp4 30:25 1,006,292,960 20180324-veryfast-2160p30-cropped-h265-crf20.mp4 21:35 328,700,100 20180324-ultrafast-2160p30-cropped-crf28.mp4 21:59 339,438,778 20180324-superfast-2160p30-cropped-crf28.mp4 25:12 350,085,434 20180324-veryfast-2160p30-cropped-crf28.mp4 25:17 349,720,030 20180324-faster-2160p30-cropped-crf28.mp4 27:24 348,582,310 20180324-fast-2160p30-cropped-crf28.mp4 52:07 365,050,252 20180324-medium-2160p30-cropped-crf28.mp4
I created a single test at -crf 20 because I was interested in seeing a higher quality video and how different it would be in size. It took slightly longer than the original h.264 compression and had a slight improvement in size.
Two things became obvious to me from this test. More time spent in compression doesn’t always mean better compression. For my application, running preset medium actually hurts the performance, both in file size and time taken.
I ran all of these tests only a single time on my desktop computer with an Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz, 3501 Mhz, 4 Core(s), 8 Logical Processor(s) running the latest version of Windows Version 10.0.16299 Build 16299. I was running FFmpeg version N-88668-g723b6baaf8 from https://ffmpeg.zeranoe.com/builds/. The variations in time could be related to background tasks running on the machine, and I should have run a more comprehensive battery of tests, averaging time and with more accurate timekeeping.
WimsWorld 