Encoder Comparison

x264 vs x265 vs VP8 vs VP9

April 20, 2020: Images have been restored.

Instructions

This section lets you see the results of 2 encodes, side-by-side. It basically works like this:

  1. Pick a bunch of stuff from the left and right sides.
  2. Hit the big red Show Changes button.
  3. Scroll down to compare the images!
  4. (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).
    • There is also an Auto Update button you can use if you're tired of clicking the red Show Changes button each time you make a change.
Warning: If you haven't used the tool before you should scroll waaaay down and read about some of the details, caveats, and gotchas before relying on the results!
Loading comparison interface...
Please be patient!
Optimized images (smaller file size, but may have alternate color profile)

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:

  1. 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.
  2. 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.
  3. 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).

56 Comments | Leave a Comment

 Sort by Oldest | Sort by Newest
  1. Luke on July 30, 2016 - click here to reply
    [repost with email address] Hi Matt, first a big Thank You for your hard work! It is very helpful and educative. I have been fiddling with x265 settings for a couple of weeks and generating samples at different RF values. I found that at most settings things like a dark sky showed pronounced banding due to the limited color range, which is also apparent on your x265 clips down to RF16 (from 00:08 to 00:18 when BB-8 wanders away in the desert at night), however I was surprised that there's no banding when the 'grain' tuning is applied. I only found a Grain setting in the Denoise section in the Filters tab in Handbrake 0.10.5.0 and I coulndn't reproduce your result. I have since successfully got rid of that pesky banding thanks to Lazarus 10bits workaround on another thread ( https://mattgadient.com/how-to-10-bit-x264-and-10-12-bit-x265-encodes-with-handbrake-mac-os-x-linux-windows/ ) but out of curiosity what platform and Handbrake build did you encode these Star Wars clips on? And could you explain your Grain setting? I haven't been able to achieve smooth gradients in 8bit at anything setting above RF10 or so. Thank you
    • Hey Luke, first comment had actually worked (comment system just hates the caching system and doesn't provide any feedback after you hit submit: I just edited the text above the comment box to make that a little more clear).

      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.
    • As to grain reducing the banding, just a guess here but assuming it isn't noise/grain covering up the banding, it's possible there is some natural dithering that it retains a little better (I suspect dithering looks an awful lot like grain to the encoder).
      • Luke on July 31, 2016 - click here to reply
        Thanks a lot for your reply, the grain setting is indeed there in the Windows Nightly build. Though the resulting look with grain enabled is more faithful to the original (depending on the movie of course) I'm getting much higher encoding speeds and better compression in the official build at same settings so I'll be trying again with a different build next time I spend the night in front of the screen ;) Cheers
  2. vdams on August 21, 2016 - click here to reply
    congratulations for this page. i'm starting to well understand best settings for HD
  3. Brendan O'Connor on August 22, 2016 - click here to reply
    Hey Matt,

    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
    • Matt Gadient on August 22, 2016 - click here to reply
      Hey 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
      • Brendan O'Connor on August 23, 2016 - click here to reply
        Thanks again 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.
  4. rorjam on September 7, 2016 - click here to reply
    Thanks, this is very useful. Mostly just interested in x264 and x265 here, particularly with the higher bit depths. I understand this takes a lot of space and no doubt took some time to set up, but I would hate to see this go entirely. Perhaps drop some of the options if that would help (e.g. remove VP8 results, keep only three of the bitrate settings and three of the ratefactor settings, don't keep results for every single preset between ultrafast and placebo, etc.).


    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?
    • Matt Gadient on September 9, 2016 - click here to reply
      Hey rorjam,

      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.
  5. Almega on September 22, 2016 - click here to reply
    I love that you did this!
  6. Andrea on September 25, 2016 - click here to reply
    hi Matt,

    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
    • Matt Gadient on September 25, 2016 - click here to reply
      Hey Andrea,

      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!
      • Andrea on September 26, 2016 - click here to reply
        hi Matt,

        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
        • Matt Gadient on September 26, 2016 - click here to reply
          Hey Andrea,

          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.
  7. Chris on October 1, 2016 - click here to reply
    Hi Matt,

    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.
    • Matt Gadient on October 1, 2016 - click here to reply
      Hey Chris,

      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!
  8. This is amazing work
  9. Luke Austin on April 9, 2017 - click here to reply
    This is awesome. Thanks for sharing :)

    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?
  10. sexypimmel on May 19, 2017 - click here to reply
    Thanks for the effort, but something can´t be right ...

    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
    • Yeah, the VP8 and VP9 behavior/quirks at low bitrate settings were actually mentioned at the top of the page under the "This Page" section. If you watch the video clip size as you adjust the slider you'll see it enforced a minimum bitrate. It seems to still be an issue (just tried in 1.0.7 on OS X GUI) so for any comparisons involving VPx you kinda have to watch the actual resulting filesize (and optionally compute the true final bitrate).

      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!
  11. Movieman on July 3, 2017 - click here to reply
    Hi Matt this is an interesting site, and a few things stand out to me:
    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.
  12. Brad on July 20, 2017 - click here to reply
    Absolutely great and so so helpful!
  13. Ben on August 14, 2017 - click here to reply
    Thanks for this great work.

    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
    • Matt Gadient on January 14, 2018 - click here to reply
      I know it's been a few months, but I have options added for mouse hover now. Clunky in a few areas but the code's getting pretty messy and I'm sleepy so I'm settling for "it works" for now.

      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.
  14. Josh on September 27, 2017 - click here to reply
    This is a great resource! Thanks Matt!
    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!
  15. brunkduy on October 1, 2017 - click here to reply
    Hey Matt,
    Just wanted to take a min to say Thank you for your time and efforts. I really appreciate the content offered here.
  16. Sean on October 26, 2017 - click here to reply
    This page is a fantastic resource. I've been compressing short clips for website backgrounds recently and have been spending a lot of trial and error with different bitrates, framerates, frame sizes, etc, to get the best balance of lightweight compressed video and decent quality. This is a great starting point for planning out the settings for an encode and could potentially save a lot of people a lot of time. It's also a great resource for comparing the potential benefits of one codec while also considering the required encoding time to reap those benefits. Thank you!
  17. Vito on November 17, 2017 - click here to reply
    I am running some basic test myself with x264 so I can imagine how much time you spend on this. This is very usefull tool.
  18. pgm86 on January 10, 2018 - click here to reply
    Wow. This is the most informative codec comparison site for the ages. Thank you for spending a great deal of your time to share this information to us clueless/confused people regarding how to convert/rip videos for archiving.
  19. pgm86 on January 10, 2018 - click here to reply
    The most informative video codec comparison information one could get. Thank you very much. You have no idea how grateful we are.
  20. Darth Haggis on February 8, 2018 - click here to reply
    Testing encode times for a 1h30m film (1080p) 8.79Gb

    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
  21. Adrian on March 3, 2018 - click here to reply
    Thanks, this was extremely useful. I have been pondering h.265 vs h.264, and this page reinforced my confidence in my present strategy: H.265 is good for shrinking my DVDs since quality is limited on those anyway, but even with extreme settings neither can compress a blu-ray without some visible quality loss (fairly obvious in the case of h.264). That said, any HD video where I am willing to lose a small amount of static image quality could be chopped in half using h.265.

    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!
  22. Daniel on March 31, 2018 - click here to reply
    Hi Matt,
    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.
  23. HelloWorld on May 10, 2018 - click here to reply
    I was actually looking for some resource that would let me compare different codecs but with variety of bit depths so I would appreciate if You added this options here but also I understand it's time consuming.
  24. HelloWorld on May 10, 2018 - click here to reply
    PS. Now I konw that VP8 gives better file size compared to VP9 and shorter encode tinmes then HEVC :)
  25. Chris Canfield on May 19, 2018 - click here to reply
    Thank you for this page! I keep coming back to it as a way to see real-world performance on the kinds of super-low bandwidth connections I need to support.

    I hope you get the time and inclination to someday add AV1 into the mix. I'd love to see that difference.
  26. Barry on June 14, 2018 - click here to reply
    This is first class, Matt. Handy for a baseline as i'm just starting to backup all my old DVD's that never made remastering to HD.
  27. hany alsamman on July 3, 2018 - click here to reply
    detailed page, very good efforts.

    thanks
  28. Hi Matt,

    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.
  29. Klemens on July 8, 2018 - click here to reply
    This is sooo helpful ! - I remember making test series over and over again - 10 years ago... My deep bow to you !
  30. popek on September 29, 2018 - click here to reply
    Thanks for this useful page! Can you add AV1 codec to this comparison? It is now tested on youtube and compress better than VP9 and x265
  31. Minigato on October 8, 2018 - click here to reply
    Super great tool, saves a lot of time (thanks for spending it by yourself)
    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?)
    • Matt Gadient on October 8, 2018 - click here to reply
      Hey Minigato,

      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.
  32. ragg987 on May 1, 2019 - click here to reply
    Thank you for providing this resource. Was considering compressing my BD collection, but not going to now...
  33. Anonymous on April 21, 2020 - click here to reply
    Why vp9 image is so bright?
    • I'm not sure, but someone else mentioned the difference as well, impacting skin tones in particular.

      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.
  34. Marek on June 18, 2020 - click here to reply
    Hi, I just wanted to drop a "thank you". This is exactly the kind of useful, hands-on example knowledge that isn't conveyed in all the tech specs and documents describing the standards.... <3
  35. John on June 28, 2020 - click here to reply
    Really nice work but there seems to be a mess-up with the color profiles that make a comparison really hard. E.g. x264 vs vp9
  36. Anonymous on July 1, 2020 - click here to reply
    This page has been pretty helpful to me, thanks! Although, for animated content it might not be that good, it's still very helpful.
  37. cy on September 12, 2020 - click here to reply
    Thank you for your hard work.
  38. daonayt on December 2, 2020 - click here to reply
    h264 RF22 maintains more detail than h265 RF22. h265 is comparable with h264 only at RF18, at wich point the filesizes are almost the same. i thought h265 would offer the same quality for reduced filesize,
  39. Vishnu on January 22, 2021 - click here to reply
    This is a cool page. Thanks for putting it together.
  40. anon on June 19, 2021 - click here to reply
    Great page, and great execution.
  41. Bits on August 1, 2021 - click here to reply
    Thanks a million for making (and hosting) this
  42. RickOrchard on October 6, 2021 - click here to reply
    Extremely usefull website. Thank you for your time and effort.

Leave a Comment

You can use an alias and fake email. However, if you choose to use a real email, "gravatars" are supported. You can check the privacy policy for more details.