Encoder Comparison
x264 vs x265 vs VP8 vs VP9
April 20, 2020: Images have been restored.
Instructions
- Pick a bunch of stuff from the left and right sides.
- Hit the big red Show Changes button.
- Scroll down to compare the images!
- (optional)
- Use the Blue Buttons to choose between shrinking fit your screen, showing side-by-side, and showing the full resolution image (with scrollbars if it's too big to fit your screen).
Please be patient!
Beta
Note that this page is something of a "beta". Depending on traffic and interest, it could be expanded on, or could go down completely at some point. Few main items that have a bearing here:
- It originally used about 145 GB of space on a dedicated server for all the images and video clips. This expense was a little hard to justify for one page, so I recently dropped all the video but kept the images (about 9GB). For reference, the entirety of mattgadient.com is about 1 GB if you exclude the encode comparison tools.
- These are really time consuming to process (encode, generate screenshots, etc) and put together a custom page for. I have some other comparisons in mind (8/10/12-bit, denoising, audio, etc) but don't want to spend weeks putting them together if it's not something that a number of people would find helpful/useful.
- This page is pretty bandwidth-intensive for visitors. Unlike the write-ups on this site (which even dial-up can handle), this page only provides a reasonable experience for those on quick connections.
If you feel strongly one way or another (really like this page or could do without it for example), please leave a comment. It would also be helpful to know what in particular you were interested in (Did you just want to see x264 at different bitrates? Were you wanting to compare x264 with VP9? Something else...?). Thanks!
This Page
This page contains a number of Star Wars: The Force Awakens encode clips, allowing you to compare the result of different encode settings.
Output from all 4 main encoders can be found below at both 480p and 1080p, with 10 different bitrate settings (all speeds). Tune settings & 10 different RF settings are available for x264 and x265.
A few things to note:
- 1080p and 480p refer to "pre-cropped" versions. Once black bars were cropped, the dimensions became 1920x800 and 854x356 respectively.
- Bitrate-based encodes all used full 2-pass to try and get the file sizes as exact as possible for fixed-bitrate comparisons between encoders.
- Only medium speed is provided for RF based encodes.
- Very low bitrates (50, 100, etc) may result in blank/grey images. This is not a bug: the encoder simply did not have enough bitrate to work with in those situations.
- Only "bitrate" results are available for VP8 and VP9 - the RF variants for VP8/9 didn't encode properly and I didn't notice until it was too late, so I simply removed them from the tool.
- VP8 and VP9 appear to enforce minimum bitrate thresh-holds. Be careful when comparing small bitrates (50kbps for example in VP8/9). In that example, while 50kbps was selected, if you look at the output filesize you'll notice that VP8/9 obviously forced the bitrate higher, up to some minimum value.
- The video clips that used to be on this page were 1m47s in duration - these clips are what the "Video clip size:" sections are referring to. They were comprised of the following time periods from SWTFA, all merged into a single video: 9m15s-9m50s, 56m07s-56m29s, 1h14m08s-1h14m58s.
Legal
Contains content from Star Wars: The Force Awakens ( © & ™ Lucasfilm Ltd.)This content has been legally used on this site, pursuant to Section 29.0 of the Canadian Copyright Act (Royal Assent June 29/2012, Effective Nov 7/2012).
The copy of HandBrake used was built from source in early June for the Linux CLI. It should be similar to the nightly builds at https://handbrake.fr/nightly.php . There *may* be small differences in the encoder output - this used the latest x264 and x265 sources in June whereas the ones in HandBrake are only updated periodically. Much of the x264/x265 improvements are minor fixes, optimizations, or ARM-based improvements, so I suspect they only update the included build when there's a good benefit to be had for HandBrake users.
The grain setting for x265 isn't in the denoise area: it should be in the Encoder Tune section, similar to x264 (near preset and profile). I just downloaded and checked the Windows nightly and it's there, so hopefully it's there across all platforms.
I'd like to thank you first off. I have used all your work to help me understand Handbrake better for a while now, though I am still not the best at it. I have a question not related to this page, but couldn't find where else to contact you.
I have Handbrake version 0.10.5.0 on Windows. in this version, there is an option for H.264 (Intel QSV) to be used as the video codec. I have a Haswell processor with Intel HD Graphics (which it says it requires), and it seems to be much less work on my processor to encode movies using it rather than x264. The problem is that to get files encoded this way to be a similar size to the x264 encoded ones, the quality seems to me to be quite noticeably worse.
My questions are, 1: Could you explain this Intel codec to me, or at least why it should have larger output files? Also, if you know how to configure it better that would be great. I hope to use it to put less stress on my CPU.
2: Is there a way to lower the stress on my CPU when encoding in x264? The encodes keep my processor at 100% utilization for the entire encode. I know I can limit my processor, but that doesn't seem really practical.
Thank you so much for all your help, and sorry for asking here if there is a better place
Brendan
I believe that's simply an option for Intel's QuickSync. It's a hardware-based encoder which is why it's quite fast - it's literally dedicated circuitry on the CPU. Doing something in hardware (QuickSync) is almost always faster and more power efficient than doing the same via software. If you search the web for "QuickSync", you'll probably come up with a number of results that show details/comparisons/etc (I believe Anandtech had a number of articles regarding it and would be a good place to start).
As for why the files would be larger with less quality, x264 is pretty complex. And it *can* be, because it's software-based. Dedicated circuitry on the CPU on the other hand comes at a cost - they have to dedicate a certain amount of silicon to any hardware-specific features. I suspect the "code" is a little more low-level too, so it would probably take an awful lot of engineers to create a hardware encoder with the complexity/quality of x264.
As for lowering the stress on the CPU when encoding x264, processor limits are really the only way I know of. There *is* a switch to limit the threads, which might make it possible to use only 1 core of your CPU (instead of say... 4), but obviously the encode would likely take about 4 times as long. For the most part, it's something you usually just have to deal with - x264 is a great encoder, but it needs a lot of CPU oomph to flex it's muscles.
Hope that helps!
-Matt
It definitely helps. I will research Quick sync and see if I can deal with the larger sizes or worse quality to hopefully save my cpu a little work. If not then I guess it's back to x264, which is definitely not anything bad at all.
Keep up the great work! I do as much trial and error as I can to better understand the encodes, but you always explain it better than I can figure out on my own.
I've used x264 a good deal, usually 1-pass with crf, but don't really have a good handle on which crf settings in x265 would be roughly comparable to crf settings in x264. This does a lot to help answer that.
Which encoder versions did you use, by the way?
I believe I used the latest build for x265 as of mid-June. For x264 I don't recall if I used the latest build (mid-June) or just the one included in the HandBrake nightly at the time - most of the x264 commits seemed to be for ARM, AVX2, etc enhancements, so when doing various tests I wasn't particularly concerned about whether I pulled the latest version there or not. VP8 and VP9 were just the versions in the nightly.
Worth noting that HandBrake's GitHub page is now showing even newer versions of both x264 and x265 - if you're successful in finding comparable x264 and x265 CRF settings on the page here, it's probably worth doing a quick test encode on your end just to verify that it's still holding true in newer versions / HB nightlies before hunkering down and doing full encodes.
thanks for this useful webpage... but, unfortunately, this made me AGAIN more (and more, more more) confusion on HOW i have to encoding my personal bluray...
i have encoded some parts of my original films with Handbrake 10.5.0 (under Snow Leopard) and with the standard setting present in the side tab of software...
i select High Profile, and after this i setup all the rest... please, see the attached report to have an idea of my encoding:
ROBOCOP (2014)
cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=64 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=15.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=62500 / vbv_bufsize=78125 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
i prefer to use the CRF mode with RF value from 18 to 15 (depending by the video quality of the bluray), set the VERYSLOW preset, Tune=FILM, TAB ADVANCED only the MERange=64 and Anamorphic=STRICT with DECOMB=OFF
the mkv resulting is great, BUT at today i continue to see many other encoding with 2pass mode that PRESERVE ALL THE DETAIL (very very very minimal difference) and with video Kbps low (from 8500 to 13000)... i try to stay into the 15000kbps with my encoding, but i am very surprised from the other encoding that i see...
also HERE, your image with RF18 (x264) are very very close to the original, also the dithering (i see only little difference in the color... why?)
how you reach these result? you use some specific setting?
i attached the report from another (and impressive) encoding of bluray (my friend encoding this):
ZOOTROPOLIS
cabac=1 / ref=5 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.90:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=0 / bitrate=8500 / ratetol=1.0 / qcomp=0.70 / qpmin=10 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=50000 / vbv_bufsize=50000 / nal_hrd=none / filler=0 / ip_ratio=1.40 / pb_ratio=1.20 / aq=2:1.00
JUNGLE BOOK (2016)
cabac=1 / ref=4 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.90:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=7 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=0 / bitrate=12700 / ratetol=1.0 / qcomp=0.70 / qpmin=10 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=50000 / vbv_bufsize=50000 / nal_hrd=none / filler=0 / ip_ratio=1.40 / pb_ratio=1.30 / aq=2:0.70 / zones=138095,152358,b=0.6
can you help me to understand how i am wrong?
best regard
P.S. if you have a email i can send you some pics to see the Original and Encode
In regards to the results here at RF18 (and all results), the settings used are very "stock". Basically the settings you select are precisely what was used via the command-line encoder, with default behavior existing for every other setting. One exception in some of my testing is that I restricted the profile to avoid crashes that would happen in certain edge cases, but I don't recall if that was for these or for some 8/10/12-bit testing I was doing.
Color difference you see likely has to do with whether there was color profile information stored that ffmpeg made use of when extracting the screenshots from the videos.
As to differences in your friend's encodes vs yours, it's been quite a long time since I've delved into the nitty-gritty of all the advanced options, but at a glance, besides the obvious differences that come with using bitrate instead of RF, your friend uses what I'd call "sharper" deblock options (-3), and different PsyRd and AQ settings. PsyRd and AQ have an impact on detail retention - kind of like an imaginary slider that helps determine whether to put more bits in detailed vs flat areas. Those might be providing the biggest visual differences. They also disable fast pskip and use no-dct-decimate which has less to do with overall detail retention but offers potential advantages in other areas which I mention just because it's something worth noting.
I wouldn't say you're doing anything horribly "wrong", but if you're looking for high detail retention in something straightforward, I'd be inclined to just start with a couple tests at "tune grain" without using the advanced options at all (disable it). Reason I'd avoid mixing presets with the advanced options is because I'm not sure if it actually transfers the preset settings to the advanced options in the way you'd expect in the HandBrake interface. If you go with just presets, using "tune grain" tends to get things looking closer to the original (more detail retention), but at the expense of bitrate - since you're using RF values between 15-18, I'm assuming you probably don't mind the higher bitrates.
If you run into walls starting (and working) from there, you can certainly delve into the advanced options, and even mimic the settings from your friends 2-pass encodes if you really like those results. Ignore the presets entirely in that case - you might want to just explicitly specify each and every advanced option in that case and tweak/test as you go along until you come up with a result you're really happy with.
Hope something in there helps!
thanks for these important info and explain me...
i have try again to encoding with CRF mode and compare the result respect the 2-PASS... ... ... ... now i have check the resulting image with more and better precision, and the result is: CRF mode is VERY GOOD and the image quality are BETTER... i have encoded THE WOLVERINE with CRF=15 (VERYSLOW+FILM+MERange=64) and the average bitrate resulting is 12,9Mb... very close to the result of my friend... if i try to use these bitrate (with the 2-PASS setting) in some particular scene I LOST ALL THE MICRO DETAIL...
finally, NOW i am SURE that my encoding are WELL MADE (probably are my eyes and the STILL IMAGE of my friend to made me wrong about my encoding)
one question about the FULL 1080p screen (no crop image)... when i use CROP IMAGE from original source 1920x1080 to 1920x800, example, i set STRICT... if i want to use FULL IMAGE at 1920x1080 (black bands up and down the effective resolution of the movie) i have to use STRICT or NONE?...
many thanks again for your suggestion and help me to open WELL my eyes...
best regard
For retaining the black bars in your example, it won't matter whether you use "strict", "none", or even "loose" (with modulus 2). I'd generally recommend getting in the habit of using "strict" though just because it'll tend to work better when you use anamorphic content (typically DVD material), while working just fine even if it's not anamorphic (your example).
To actually retain the black bars themselves, you'll have to change Cropping from Automatic to "Custom" and change the top/bottom values to 0.
Very new Handbrake user here and this page has been extremely informative, so thank you for writing it.
I am curious on one point, based mostly off the Best Settings page that linked here, you list h.265 as still being too young to warrant heavy use. Do you still believe this to be the case? I couldn't tell what date those comments were from but they look a few years old.
I have a few HEVC compatible devices but I am using Plex to serve the media so it will transcode for all the incompatible devices regardless.
Are the space savings worth the trouble of h.265 or is h.264 still the way to go. I am running a 6TB NAS at present and it is approaching full so I was hoping to save space while keeping quality as much as possible when ripping all my DVDs (and eventually my blurays when I get a new drive).
Also is it worth going through and recoding my existing h.264 videos as h.265 to make the most of the available space?
Time is not a real factor as I can queue the jobs before going to work and leave them running over night whenever necessary.
Thanks in advance and a big thanks for the guides, they will be tremendously helpful.
It sounds like between device support and Plex you've got HEVC compatibility stuff covered, so if you're pretty sure the lack of compatibility on older devices isn't going to be a hindrance, I see no problem in starting to shift to x265.
Whether the space savings makes recoding your videos worthwhile, I suppose my viewpoint is this: At lower bitrates (higher RF values), HEVC/x265 really comes out ahead. Encode times take awhile, but you've got a respectable space savings in most cases. However, if trying to retain every bit of detail (grain, etc) - something normally done by using really high bitrates (or small RF values), the space savings tends to get a lot smaller. I don't think I'd go recoding everything at that point unless desperate for every bit of space.
Just to be clear, I'm talking about recoding from the source material (DVD, BluRay, or other original source). I wouldn't normally try to take a previous x264 encode and recode *that* because you're effectively taking a photocopy of a photocopy. Exception here might be if you're really desparate for space and can't find your originals - sometimes you just don't have much choice in the matter.
Hope that helps!
Interestingly, the lighting and skintones in the VP8 or VP9 encodes are much closer to the original when compared to x264 or x265. Do you know why?
VP8 at 100kbp/s can not retain those visuals at all and certainly not with a 2K image ;)= . Anyway did some handbrake encoding and x265 was as fast or faster than VP8 while creating smaller files ... not sure why VP8 or Theora are even included (handbrake). If speed was the primary concern, encode with quicksync (C)RF 30 to 35 .. 14min later a 2h 2K film is encoded ... or in 5ish if you downscale to 720p. (best quality 130fps, balanced close to 250fps). I´m actually surprised how well the quicksync encoder is working ... even at 100kbp/s (at the end it used close to 1mbit) the image quality was superior to VP8 and X265 at 100kbp/s and it took only like 25s to encode while up to 5min30s with the others each run.
Here the images for those interested.
https://imgur.com/a/8NkX4
I really haven't played much at all with QuickSync since it's Windows-only in HandBrake (though I believe that may be changing for at least Linux). There's also the potential issue where different QuickSync versions tied to different CPU's (Sandy, Ivy, Haswell, etc) can result in different levels of output quality as Anandtech mentioned here: http://www.anandtech.com/show/7007/intels-haswell-an-htpc-perspective/8 . So someone's QuickSync result on Kaby Lake might be quite different from someone's result on Sandy Bridge. Makes things a bit more of a pain when doing comparisons.
QuickSync's definitely fast, and your results certainly look good - I just haven't delved into it much at all personally because the support in HB hasn't been cross-platform and I'm usually on either OSX or Linux.
Thx for including the images of your results btw!
1: There's only a very slight loss in sharpness and detail when VP9 and X265 are compared at 6400 bitrate to the original source. There would be a bigger difference at 1920x1080 not 1920x800.
2:X264/5 encoders both change the tint from slightly red to slightly green when compared to the original, but VP8/9 encoders do not!
3: Obviously VP9 and X265 are better than VP8 and X264 at a similar file size. However at a similar encoding time the picture quality of X264/5 quality is better compared to VP8/9.
4:VP9 and X265 have a bigger advantage in picture quality over their predecessors at typical 480p/540p bitrates (800/1600) than typical 720p/1080p bitrates (3200/6400).
Thanks.
Can you a new compare mode that trigger image change on mouse in and out? so I can just compare image in same place, I think it's more sensitive to human eyes.
IMHO compare, x264 crf 16 > x265 crf 16, but x265 crf24 = x264 crf24
Note that the "invisible box" it uses to detect mouse hover extends to the width of the web browser window even if the image is smaller, so if you have whitespace on either side of the image, you'll either have to drag the mouse off the top/bottom of the image, or sideways outside the web browser.
It can also take a little time if the 2nd image is still loading in the background - you'll see the text change once it's ready (depending on web browser).
If someone really needs the same functionality working on mobile (touch), let me know - too sleepy to work on that at the moment.
I've been looking in understanding H.265 and how it differs from H.264 to understand what the benefits are for visual quality and file sizes, yet at the same time understand what all the tweaking in Handbrake does.
I highly commend you for your work on this!
Just wanted to take a min to say Thank you for your time and efforts. I really appreciate the content offered here.
These are the final encode times and file size when done.
ORIGINAL x264 SETTING I USED
- [x] RF22
* Filesize (GB): 2.55
* Encode Time: 22min
MEDIUM SETTING
- [x] RF24
* Filesize (GB): 1.37
* Encode Time: 38min
- [x] RF23
* Filesize (GB): 1.49
* Encode Time: 39min
- [x] RF22
* Filesize (GB): 1.65
* Encode Time: 40min
- [x] RF21
* Filesize (GB): 1.85
* Encode Time: 43min
- [x] RF20
* Filesize (GB): 2.11
* Encode Time: 43min
- [x] RF19
* Filesize (GB): 2.45
* Encode Time: 45min
- [x] RF18
* Filesize (GB): 2.89
* Encode Time: 46min
- [x] RF17
* Filesize (GB): 3.44
* Encode Time: 49min
- [x] RF16
* Filesize (GB): 4.14
* Encode Time: 51min
SLOW SETTING
- [x] RF22
* Filesize (GB): 1.59
* Encode Time: 1h31m
- [x] RF21
* Filesize (GB): 1.77
* Encode Time: 1h36m
- [x] RF20
* Filesize (GB): 2.00
* Encode Time: 1h43m
- [x] RF19
* Filesize (GB): 2.31
* Encode Time: 1h51m
- [x] RF18
* Filesize (GB): 2.73
* Encode Time: 1h59m
- [x] RF17
* Filesize (GB): 3.29
* Encode Time: 2h08m
- [x] RF16
* Filesize (GB): 4.00
* Encode Time: 2h18m
I do see some of the detail loss from h.264 that people mention under some RF values in h.265, but per bitrate there is no comparing.
This would be a bit more useful if the bars in the originals were cropped off.
I know it's old now, but I still really appreciate this tool!
Thanks so much for this informative page. I am a newbie to encoding my videos and like some of the commentators above, I need to save space. Short of deleting many cherished video files, I find it necessary to convert many of my video files to smaller file size to conserve space. Your Website has helped me to get up to speed on figuring out which setting I should use to encode my videos - H.264 or H.265. I am going to use H.265.
Thanks again for your time and talents putting all this information together for comparison purposes.
I hope you get the time and inclination to someday add AV1 into the mix. I'd love to see that difference.
thanks
Thanks for this, it's extremely useful! Per your request that we comment to say what we're using it for:
I have a video library I'm intending to convert to h265 en-masse to save some space and was looking for a comparison of image qualities between h264 and h265 at various RF settings, since the overwhelming majority of my media is h264.
I realise there're caveats to this, particularly that some of my source video is of pretty abysmal quality and will only look worse re-encoded but I think for the majority of it I'll not be able to tell the difference, and it remains a useful comparison.
The only thing I miss is speed presets for RF, maybe just Fast, Medium and Slow because I don’t fully understand their effect on RF (lower filesize? Better quality overall?)
The page at https://mattgadient.com/results-encoding-8-bit-video-at-81012-bit-in-handbrake-x264x265/ has a few speed presets (ultra, faster, slow, placebo). It's similar to the tool for this page, but is only for x264 and x265.
However, one of the reasons speed presets for RF were the first thing "cut" from this page is that they tend to be inconsistent (at least in x264). The short version is at a given RF value, using a slower setting should give you a better quality/filesize ratio: however compared to the "equivalent" faster preset there are no guarantees as to whether the size will be bigger/smaller or whether the quality will be better/worse. If that sounds a bit crazy, I went into the details a little at https://mattgadient.com/handbrake-rf-slower-speeds-craziness/ .
If it's an area you don't feel like digging into right now, I'd generally suggest finding the slowest speed preset you're comfortable with time-wise, stick with that, and then adjust the RF until you're happy with the result. After that, tweak RF values when necessary. Don't do the opposite (don't settle on a RF and then tweak speeds in an attempt to further tweak quality or size) as that will give highly variable results.
I should mention that images were pulled from the videos via ffmpeg and weren't modified to strip color profiles, to be browser friendly, etc. So it's as "raw" as I was able to keep it. If something looks slightly off it could simply be encoder differences, but could also be color profiles displaying differently in the web browser (right-click-download and check in Photoshop/etc to verify this) or even a byproduct of ffmpeg extraction.
Really appreciate your hard work on it!