While there are lots of articles that discuss the theory and technical specifications of H.264, also known as AVC, and H.265, also known as HEVC, you will be hard pressed to find one that shows real-world data you can verify yourself.
For that reason, I am writing this article to provide real-world examples and actual video files that you can inspect yourself. In order to perform this test, I first needed a test subject.
I wanted a video file that is widely known on the internet and familiar to people who work with video encoding and streaming. It also needed to be freely available so anyone could download the same source and reproduce the results.
I decided to use the well-known, at least within the video and streaming industry, Big Buck Bunny. Specifically, I used the file named:
bbb_sunflower_2160p_60fps_normal.mp4
The original file can be downloaded from the official Blender website here. The source video is 10 minutes and 34.53 seconds long.
It has a resolution of 3840 by 2160, runs at 60 frames per second, and contains an H.264 video stream with a reported bitrate of approximately 8,002 kbps. For this comparison, both H.264 and H.265 outputs were resized to 1920 by 1080 while retaining the original 60 frames per second.
Test Configuration
Both conversions were performed on the same server using the same FFmpeg installation. The server was running Debian 12 with FFmpeg 5.1.9. The FFmpeg build included both the libx264 and libx265 software encoders.
Keeping the environment consistent is important. Running one codec on a different processor, operating system, FFmpeg version, or hardware encoder would make the timing results much less useful.
The following settings were identical for both codecs:
Source file: bbb_sunflower_2160p_60fps_normal.mp4
Output resolution: 1920x1080
Output frame rate: 60 fps
Encoder preset: medium
Pixel format: yuv420p
Audio codec: AAC
Audio bitrate: 128 kbps
Audio channels: stereo
FFmpeg selected the same AC3 5.1 source audio stream for both conversions and converted it to AAC stereo. This means the audio processing was consistent across both tests.
I ran two different comparisons because they answer two different questions. The first comparison used the same target video bitrate for both H.264 and H.265. This creates files that are approximately the same size and allows us to compare visual quality at the same bitrate.
The second comparison used CRF encoding. CRF allows each encoder to select the bitrate it needs to reach its requested quality level. This is closer to the way many people use x264 and x265 for normal conversions.
Equal-Bitrate Test
For the first test, both codecs were given a target video bitrate of 5,000 kbps.
H.264 command
time ffmpeg -i bbb_sunflower_2160p_60fps_normal.mp4 -c:v libx264 -preset medium -b:v 5000k -vf "scale=-2:1080" -pix_fmt yuv420p -c:a aac -b:a 128k -ac 2 h264.mp4H.265 command
time ffmpeg -i bbb_sunflower_2160p_60fps_normal.mp4 -c:v libx265 -preset medium -b:v 5000k -vf "scale=-2:1080" -pix_fmt yuv420p -c:a aac -b:a 128k -ac 2 h265.mp4The purpose of this test was simple:
At approximately the same file size, which codec produces better visual quality?
Equal-Bitrate File Size Results
The H.264 output was:
396,956 kB
The H.265 output was:
396,651 kB
The difference was only 305 kB. That is less than one tenth of one percent. These files are almost the same size because both encoders were told to target the same 5,000 kbps video bitrate.
Both files also have the same duration and the same 128 kbps audio configuration. File size is primarily determined by bitrate multiplied by duration. When the bitrate and duration are nearly identical, the final file sizes will also be nearly identical.
The final reported bitrates confirm this.
H.264 total bitrate: 5,124.9 kbps
H.265 total bitrate: 5,121.0 kbps
The video streams were also extremely close:
H.264 video bitrate: 4,982.37 kbps
H.265 video bitrate: 4,976.16 kbps
This equal-bitrate test does not show H.265 producing a smaller file. That was never the purpose of this part of the test. It gives both codecs approximately the same amount of data and lets us inspect how efficiently they use it. Do you see any difference?
H.264
H.265
You can download the outputs of this test below. It’s important to mention that the downloadable files should be compared during motion, not only as paused screenshots (like the ones above). I would pay close attention to detailed backgrounds, moving fur, grass, shadows, gradients, fast camera movements, and the edges around animated characters.
H.264 equal-bitrate test file: Download staticbr-h264.mp4
H.265 equal-bitrate test file: Download staticbr-h265.mp4
Equal-Bitrate Conversion Time
The H.264 conversion completed in:
9 minutes, 56.916 seconds
FFmpeg reported an average conversion speed of:
1.06x real time
The H.265 conversion completed in:
29 minutes, 34.436 seconds
FFmpeg reported an average conversion speed of:
0.358x real time
H.265 took approximately 2.97 times as long as H.264. That is a major difference. The source video is approximately ten and a half minutes long. H.264 finished slightly faster than the duration of the video itself. H.265 required almost half an hour.
For a person converting one video, the difference may be acceptable. For a service processing hundreds or thousands of videos, it has a direct impact on server capacity.
Longer conversions mean fewer completed jobs per hour, longer customer wait times, more CPU usage, and higher infrastructure costs. This result alone gives H.264 a clear advantage when conversion speed matters.
CRF Test
The second test used CRF encoding rather than a fixed video bitrate.
For H.264, I used CRF 23. For H.265, I used CRF 28. These are common starting values for their respective encoders.
H.264 CRF command
time ffmpeg -i bbb_sunflower_2160p_60fps_normal.mp4 -c:v libx264 -preset medium -crf 23 -vf "scale=-2:1080" -pix_fmt yuv420p -c:a aac -b:a 128k -ac 2 h264-crf.mp4H.265 CRF command
time ffmpeg -i bbb_sunflower_2160p_60fps_normal.mp4 -c:v libx265 -preset medium -crf 28 -vf "scale=-2:1080" -pix_fmt yuv420p -c:a aac -b:a 128k -ac 2 h265-crf.mp4CRF numbers are specific to each encoder. A CRF value of 23 in x264 is not mathematically equivalent to CRF 23 in x265. Using different CRF values is normal when comparing these encoders under common practical settings.
CRF File Size Results
The H.264 CRF 23 output was:
285,750 kB
The H.265 CRF 28 output was:
116,464 kB
The H.265 file was 169,286 kB smaller.
That represents a file-size reduction of approximately:
59.2 percent
The video bitrates explain the difference.
H.264 video bitrate: 3,546.75 kbps
H.265 video bitrate: 1,359.06 kbps
Both files contained approximately 10,033 kB of AAC audio, so nearly the entire size difference came from the video stream. This is the strongest result in favor of H.265. Under these CRF settings, it produced a file that was less than half the size of the H.264 output.
That result has practical value. A 59 percent reduction can significantly reduce storage requirements, download times, and bandwidth usage. The savings become substantial when a video is stored in multiple locations or delivered to a large audience.
There is one important limit to this result. CRF 23 in x264 and CRF 28 in x265 do not prove that both outputs have precisely identical visual quality.
I would describe them as practical quality settings, not mathematically equal quality settings. I would, however, encourage you not to take my word for it. Download the files and judge for yourself whether the H.265 output maintains an acceptable level of detail despite its much smaller file size.
H.264
H.265
H.264 CRF test file: Download h264-crf.mp4
H.265 CRF test file: Download h265-crf.mp4
CRF Conversion Time
The H.264 CRF conversion completed in:
9 minutes, 26.914 seconds
Its reported speed was:
1.12x real time
The H.265 CRF conversion completed in:
21 minutes, 25.933 seconds
Its reported speed was:
0.494x real time
H.265 took approximately 2.27 times as long as H.264. The H.265 CRF conversion was faster than the H.265 5,000 kbps conversion, but it was still more than twice as slow as H.264.
This creates a clear tradeoff. H.265 saved approximately 59 percent of the file size, but the conversion required an additional 11 minutes and 59 seconds.
Whether that trade is worthwhile depends on what happens after the video is created. A video encoded once and streamed thousands of times can justify the additional conversion time. The storage and bandwidth savings may continue for months or years.
A temporary conversion that is downloaded once and deleted shortly afterward may not justify spending more than twice as long encoding it. For an online file conversion service, I would not make H.265 the only MP4 option.
I would offer H.264 as the standard compatibility choice and H.265 as a smaller-file option for users who understand the tradeoff.
Compatibility
H.264 remains the safer codec for broad distribution. It has mature support across browsers, operating systems, phones, televisions, editing applications, hardware players, and older devices. When I do not know where a file will be played, H.264 is my default choice.
H.265 support has improved considerably, but it is still less universal. Browser support, device decoding support, licensing considerations, and container details can affect whether an H.265 file plays correctly.
Compatibility matters because a smaller file provides no value to someone who cannot open it. For private applications, controlled streaming platforms, supported televisions, modern phones, or archival storage, H.265 can be an excellent choice.
For a public download intended to work on the widest possible range of devices, H.264 remains the more reliable option.
Is Big Buck Bunny a Good Test File?
Big Buck Bunny is a good source for this comparison. The file is high resolution, runs at 60 frames per second, lasts more than ten minutes, and includes motion, textures, color gradients, detailed scenery, and animated characters.
It is also freely available and easy for other people to download. That makes the test reproducible. The main limitation is that Big Buck Bunny is animated. Animation compresses differently from live-action footage.
It does not contain the same camera noise, film grain, skin texture, low-light noise, or unpredictable motion found in real camera footage. I would not claim that the exact percentages in this test apply to sports, movies, phone recordings, surveillance footage, or every other type of video.
Perhaps in future tests, the next logical step would be to repeat the same commands using a live-action source such as Tears of Steel. That would provide a useful second data point without making the test unnecessarily complicated.
Final Results
Equal-bitrate test
H.264 file size: 396,956 kB
H.265 file size: 396,651 kB
H.264 conversion time: 9 minutes, 56.916 seconds
H.265 conversion time: 29 minutes, 34.436 seconds
H.265 took approximately 2.97 times as long.
CRF test
H.264 file size: 285,750 kB
H.265 file size: 116,464 kB
H.264 conversion time: 9 minutes, 26.914 seconds
H.265 conversion time: 21 minutes, 25.933 seconds
H.265 produced a file approximately 59.2 percent smaller.
H.265 took approximately 2.27 times as long.
So What’s The Main Takeaway?
The results give H.264 a decisive advantage in encoding speed and compatibility. H.265 has a decisive advantage in compression efficiency under the tested CRF settings.
At the same target bitrate, the files were nearly identical in size. H.265 took almost three times as long to encode, so its value in that test depends on whether the resulting video looks better at the same file size.
Under the CRF test, H.265 produced a file approximately 59 percent smaller. It also required more than twice the encoding time.
My takeaway is straightforward. I would choose H.264 when conversion speed, compatibility, and predictable playback are the main priorities. I would choose H.265 when storage space and bandwidth usage matter enough to justify slower encoding and reduced compatibility.
For a real-world conversion platform, offering both is the most practical solution. H.264 should be the standard option. H.265 should be available for users who want a smaller file and have a compatible playback environment.
