Feb 202016

H.265/HEVC logoRecently, after [successfully compiling] the next generation x265 H.265/HEVC video encoder on Windows, Linux and FreeBSD, I decided to ask for guidance when it comes to compressing Anime (live action will follow at a later time) in the Doom9 forums, [see here]. Thing is, I didn’t understand all of the knobs x265 has to offer, and some of the convenient presets of x264 didn’t exist here (like --tune film and --tune animation). So for a newbie it can be quite hard to make x265 perform well without sacrificing far too much CPU power, as x265 is significantly more taxing on the processor than x264.

Thanks to [Asmodian] and [MeteorRain]/[LittlePox] I got rid of x265s’ blurring issues, and I took their settings and turned them up to achieve more quality while staying within sane encoding times. My goal was to be able to encode 1080p ~24fps videos on an Intel Xeon X5690 hexcore @ 3.6GHz all-core boost clock at >=1fps for a target bitrate of 2.5Mbit.

In this post, I’d like to compare 7 scenes from the highly opulent Anime [The Garden of Words] (言の葉の庭) by [Makoto Shinkai] (新海 誠) at three different average bitrates, 1Mbit, 2.5Mbit (my current x264 default) and 5Mbit. The Blu-Ray source material is H.264/AVC at roughly 28Mbit on average. Also, both encoders are running in 10-bit color depth mode instead of the common 8-bit, meaning that the internal arithmetic precision is boosted from 8- to 16-bit integers as well. While somewhat “non-standard” for H.264/AVC, this is officially supported by H.265/HEVC for Blu-Ray 4K. The mode of operation is 2-pass to aim for comparable file sizes and bitrates. The encoding speed penalty for switching from x264 to x265 at the given settings is around a factor of 8. Somewhat.

The screenshots below are losslessly compressed 1920×1080 images. Since this is all about compression, I chose to serve the large versions of the images in WebP format to all browsers which support it (Opera 11+, Chromium-based Browsers like Chrome, Iron, Vivaldi, the Android Browser or Pale Moon as the only Gecko browser). This is done, because at maximum level, WebP does lossless compression much more efficiently, so the pictures are smaller. This helps, because my server only has 8Mbit/s upstream. If your browser doesn’t support WebP (like Firefox, IE, Edge, Safari), it’ll be fed lossless PNG instead. All of this happens automatically, you don’t need to do anything!

Now, let’s start with the specs.


Here are the source material encoding settings according to the video stream header:

cabac=1 / ref=4 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.40:0.00 /
mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 /
fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=1 / sliced_threads=0 / slices=4 /
nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 /
b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=1 / keyint=24 / keyint_min=1 /
scenecut=40 / intra_refresh=0 / rc_lookahead=24 / rc=2pass / mbtree=1 / bitrate=28229 /
ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 /
vbv_maxrate=31600 / vbv_bufsize=30000 / nal_hrd=vbr / filler=0 / ip_ratio=1.40 / aq=1:0.60

x264 10-bit encoding settings (pass 1 & pass 2), 2.5Mbit example:

--fps 24000/1001 --preset veryslow --tune animation --open-gop --b-adapt 2 --b-pyramid normal -f -2:0
--bitrate 2500 --aq-mode 1 -p 1 --slow-firstpass --stats v.stats -t 2 --no-fast-pskip --cqm flat

--fps 24000/1001 --preset veryslow --tune animation --open-gop --b-adapt 2 --b-pyramid normal -f -2:0
--bitrate 2500 --aq-mode 1 -p 2 --stats v.stats -t 2 --no-fast-pskip --cqm flat --non-deterministic

x265 10-bit encoding settings (pass 1 & pass 2), 2.5Mbit example:

--y4m -D 10 --fps 24000/1001 -p veryslow --open-gop --bframes 16 --b-pyramid --bitrate 2500 --rect
--amp --aq-mode 3 --no-sao --qcomp 0.75 --no-strong-intra-smoothing --psy-rd 1.6 --psy-rdoq 5.0
--rdoq-level 1 --tu-inter-depth 4 --tu-intra-depth 4 --ctu 32 --max-tu-size 16 --pass 1
--slow-firstpass --stats v.stats --sar 1 --range full

--y4m -D 10 --fps 24000/1001 -p veryslow --open-gop --bframes 16 --b-pyramid --bitrate 2500 --rect
--amp --aq-mode 3 --no-sao --qcomp 0.75 --no-strong-intra-smoothing --psy-rd 1.6 --psy-rdoq 5.0
--rdoq-level 1 --tu-inter-depth 4 --tu-intra-depth 4 --ctu 32 --max-tu-size 16 --pass 2
--stats v.stats --sar 1 --range full

Since x265 can only read raw YUV and Y4M, the source video is being fed to it via [libavs’] avconv tool, piping it into x265. The avconv commandline for that looks as follows:

$ avconv -r 24000/1001 -i input.h264 -f yuv4mpegpipe -pix_fmt yuv420p -r 24000/1001 - 2>/dev/null

If you want to do something similar, but you don’t like avconv, you can use [ffmpeg] as a replacement, the options are completely the same. Note that you should always specify the correct frame rates (-r) for input and output, or the bitrate setting of the encoder will be applied wrongly!

x264 on the other hand was linked against libav directly, using its decoding capabilities without any workarounds.

Let’s compare:

“The Garden of Words” has a lot of rain. This is a central story element of the 46 minute movie, and it’s hard on any encoder, because a lot of stuff is moving on screen all the time. Let’s take a look at such a scene for our first side-by-side comparison. Each comparison is done in two rows: H.264/AVC first (including the source material), and below that H.265/HEVC, also including the source.

Let’s go:

Scene 1, H.264/AVC encoded by x264 0.148.x:

Scene 1, H.265/HEVC encoded by x265 1.9+15-425b583f25db:

It has been said that x265 performs specifically well at two things: Very high resolutions (which we don’t have here) and low bitrates. And yep, it shows. When comparing the 1Mbit shots, it becomes clear pretty quickly that x265 manages to preserve more detail for the parts with lots of motion. x264 on the other hand starts to wash out the scene pretty severely, smearing out some raindrops, spray water and parts of the foliage. Also, it’s pretty bad around the outlines as well, but that’s true for both encoders. You can spot that easily with all the aliasing artifacts on the raindrops.

Moving up a notch, it becomes very hard to distinguish between the two. When zooming in you can still spot a few minor differences (note the kids umbrella, even if it’s not marked), but it’s quite negligible. Here I’m already starting to think x265 might not be worth it in all cases. There are still differences between the two 2.5Mbit shots and the original however, see the red areas of the umbrella and the most low-contrast, dark parts of the foliage.

At 5Mbit, I really can’t see any difference anymore. Maybe the colors are a little off or something, but when seen in motion, distinguishing between the two and the original becomes virtually impossible. Given that we just threw a really difficult scene at x264 and x265, this should be a trend to continue throughout the whole test.

Now, even more rain:

Scene 2, H.264/AVC encoded by x264 0.148.x:

Scene 2, H.265/HEVC encoded by x265 1.9+15-425b583f25db:

Now this is extreme at 1Mbit! Looking at H.264, the spray water on top of the cable can’t even be told apart from the cloud in the background anymore. Detail loss all over the scene is catastrophic in comparison to the original. Tons of raindrops are simply gone entirely, and the texture details on the tower and the angled brick wall of the house to the left? Almost completely washed out and smeared.

Now, let’s look at H.265 @ 1Mbit. The spray water is also pretty bad, but it’s amazing how much more detail was preserved overall. Sure, there are still parts of the raindrops missing, but it’s much, much closer to the original. We can now see details on the walls as well, even the steep angle one on the left. The only serious issue is the red light bleeding at the tower. There is very little red there in the original, so I’m not sure what happened there. x264 does this as well, but x265 is a bit worse.

At the next level, the differences are less pronounced again, but there is still a significant enough improvement when going from x264 to x265 at 2.5Mbit: The spray water on the cable becomes more well-defined, and more rain is being preserved. Also, the textures on the walls are a tiny little bit more detailed and crisp. Once again though, x265 is bleeding too much red light at the tower.

Since it’s noticeably not fully on the level of the source still, let’s look at 5Mbit briefly. x265 is able to preserve a tiny little bit more rain detail here, coming extremely close to the original. In motion, you can’t really see the difference however.

Now, let’s get steamy:

Scene 3, H.264/AVC encoded by x264 0.148.x:

Scene 3, H.265/HEVC encoded by x265 1.9+15-425b583f25db:

1Mbit first again: Let me just say: It’s ugly. x264 pretty much messes up the steam coming from the iron. We get lots of block artifacts now. Some of the low-contrast patterns on the ironing board are being smeared out at a pretty terrible level. Also, the bokeh background partly shows block artifacts and banding. x265 produces quite a lot of banding here itself, but no blocks. Also, outlines and sharp contrasts are more well-defined, and the low contrast part is done noticeably better.

At 2.5Mbit, the patterns repeat themselves now. The steam is only slightly better with x265, outlines are slightly more well-defined, and the low-contrast patterns are slightly more visible. For some of the blurred parts, x265 seems to be a tiny little bit to prone to banding though, in a very few spots, x264 might be just that 1% better. Overall however, x265 wins this, and even if it’s just for the better outlines.

At 5Mbit, you really need to zoom in and analyze very small details, e.g. around the outer border of the steam. Yes, x265 does better again. But you’d not really be able to notice this when watching.

How about we go cry a little bit:

Scene 4, H.264/AVC encoded by x264 0.148.x:

Scene 4, H.265/HEVC encoded by x265 1.9+15-425b583f25db:

Cutting onions would be a classic fun part in a slice-of-life anime. Here, it’s just kitchen work. And quite the bad looking one for H.264 at 1Mbit. The letters on the knife are partly lost completely, becoming unreadable. The onion parts that fly off are visibly worse than when encoded with x265 at the same bitrate. Also, x264 produced block artifacts in the blurred bokeh areas again, that simply aren’t there with x265.

On the next level, the two come much closer to each other. However, x265 simply does the outlines better. Less artifacts and sharper, just like with the writing on the knifes’ blade as well. The issues with the bokeh are nearly gone. What’s left is a negligible amount of blocking for x264 and banding for x265. Not really noticeable however.

Finally, at 5Mbit, x265 shows those ever so slightly more well-done outlines. But that’s about it, the rest looks nice for both, and pretty much identical to the source.

Now, please, dig in:

Scene 5, H.264/AVC encoded by x264 0.148.x:

Scene 5, H.265/HEVC encoded by x265 1.9+15-425b583f25db:

Let’s keep this short: x264 does blocking, and bad transitions/outlines. x265 does it better. Plain and simple.

At 2.5Mbit, x265 nearly reaches quality transparency when compared to the original, something x264 falls short of, just a bit. While x265 does the outlines and the steam part quite like in the original frame, x264 rips the outlines apart a bit too much, and slight block artifacts can again be seen for the steam part.

At 5Mbit, x264 still shows some blocking artifacts in a part that most lossy image/video compression algorithms traditionally suck at: The reds. While not true for all human beings, most eyes perceive much finer gradients for greens, then blues, and do worst with reds. Meaning, our eyes have an unequal sensitivity distribution when it comes to colors. So image and video codecs try to save bitrate in the reds first, because supposedly it’d be less noticeable. To me subjectively, x265 achieves transparency here, meaning it looks just like the original. x264 doesn’t manage entirely. Close, but not not entirely.


Scene 6, H.264/AVC encoded by x264 0.148.x:

Scene 6, H.265/HEVC encoded by x265 1.9+15-425b583f25db:

This is a highly static scene, with only few moving parts, so there is some rain again, and some shadow cast by raindrops as well. Now, for the static parts, incremental B frames really work wonders here. Most detail is being preserved by both encoders. What’s supposed to be happening is happening: The encoders save bit rate where the human eye can’t easily tell: In the parts where stuff is moving around very quickly. That’s how we lose a lot of raindrop shadows and some drops as well. x264 seems to have trouble separating the scene into even smaller macro blocks though? Not sure if that’s the reason, but a lot of mesh detail for the basket on the balcony on the top right is lost – x265 does better there! This is maybe because x264 couldn’t distinct the moving drops from the static background so well anymore?

At 2.5Mbit, the scenes become almost indistinguishable. The more static content we have, the easier it gets of course, so the transparency threshold becomes lower. And if you ask me, both of them reach perfect quality at 5Mbit.

Let’s throw another hard one at them for the last round:

Scene 7, H.264/AVC encoded by x264 0.148.x:

Scene 7, H.265/HEVC encoded by x265 1.9+15-425b583f25db:

Enough rain already? Pffh! Here we have a lot of foliage and low contrast added to the mix. And it gets smeared a lot by x264, rain detail lost, fine details of the bushes turning into green mud, that’s how it goes. x265 also loses too much detail here (I mean, 1Mbit is really NOT much), but again, it fares quite a bit better.

At 2.5Mbit, both encoders do very well. Somehow, this scene doesn’t seem to penalize x264 that much at the medium level. You’d really need your magnifying glass to find the spots where x265 still does better, which surprises me a bit for this scene. And finally, at 5Mbit – if you ask me – visual transparency is reached for both x264 and x265.

Final thoughts:

Clearly it’s true what a lot of people have been saying. x265 rocks at low bitrates, if configured correctly. But that isn’t gonna give me perfect quality or anything. Yeah, it sucks less – much less – than x264 in that department, but at a higher 2.5Mbit, where both start looking quite decent, x265 having just a slight edge… it becomes hardly justifiable to use it, simply because it’s that much slower to run it at decent settings.

Also, you need to take device compatibility into account. Sure, a powerful PC can always play the stuff. No matter if it’s some UNIX, Linux, MacOS X or Windows. But how about video game consoles? Older TVs? That kind of thing. Most of those can only play H.264/AVC. Or course, if you’re only using your PC and you have a lot of time and electricity to burn, then hey – why not?

But I’ll have to think really long and really hard about whether I want to replace x264 with x265 at this given point in time. Overall, it might not be practical enough on my current hardware yet. Maybe I’d need an AVX/AVX2-capable processor, as x265 has tons of optimizations for those instruction set extensions. But I’m gonna stay on my Xeon X5690 for quite a while, so SSE 4.2 is the latest I have.

I’d say, if you can stand some quality degradation, then x265 might be the way to go, as it can give you much smaller file sizes at lower bitrates with slight degradation.

If you’re aiming for high bitrates and quality, it might not be worth it right now, at least for 1080p. It’s been said the tables are turning once more when going up to 4K and UHD, but I haven’t tested that yet, as all my content – both Anime and live action movies – are “low resolution” *cough* 1080p or 720p.


Screenshots were taken using the latest stable mplayer 1.3.0 on Linux. Thank god they’re bundling it with ffmpeg now, making things much easier. This choice was made because mplayer can easily grab screenshots from specific spots in a video in an automated fashion. I used framesteps for this, like this:

$ mplayer ./TEST-H.265/HEVC-1mbit.mkv -nosound -vf framestep=24 \
 -vo png:z=9:outdir=./screenshots/1mbit/H.265/HEVC/:prefix=H.265/HEVC-1mbit-

This will decode every 24th frame of the video file TEST-H.265/HEVC-1mbit.mkv, and grab it into a .png file with maximum lossless compression as supported by mplayer. The .png files will be prefixed with a user-defined string and numbered, like H.265/HEVC-1mbit-00000001.pngH.265/HEVC-1mbit-00000002.png and so on, until the end of file is reached.

To encode the full size screenshots to WebP, the most recent [libwebp-0.5.0], or rather one of its companion tools – cwebp – was used as follows:

$ cwebp -z 9 -lossless -q 100 -noalpha -mt ./input.png -o ./output.webp

Now… somebody wanna grant me remote access to some quad socket Haswell-EX Xeon box for free?


Meh… :roll:

CC BY-NC-SA 4.0 A quality comparison between x264 (H.264/AVC) and x265 (H.265/HEVC) with animated content at pretty demanding settings by The GAT at XIN.at is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

  76 Responses to “A quality comparison between x264 (H.264/AVC) and x265 (H.265/HEVC) with animated content at pretty demanding settings”

  1. I know this is kind of old, but this is literally the only place on the entire fucking internet that compares the two codecs in an entirely unbiased fashion while showing clear comparison images and what each codec is getting right and wrong. I kept searching around for info on the topic, and I ran into again and again folks saying “you can encode x265 at half the bitrate of x264 and maintain the same quality!” Utter horseshit!

    Thanks a bunch!

    • Hey Max,

      Although H.265/HEVC should indeed be much better for 4K/UHD given it’s potentially larger CTUs (like macroblocks) when compared to H.264/AVC. But I haven’t really run any tests with UHD content.

      I would’ve thought that there should be many more (unbiased) articles like mine around by now, and much better ones as well. After all, I’ve only focused on animated content, and my experience with x264/x265 parameter tuning is rather mediocre as well. Maybe some comparisons can be found on the Doom9 forums?

      But that “half bitrate” claim is mostly marketing talk. Others claim this when it comes to very low bitrate videos. See my [ultra-low bitrate comparison] experiment. I’ve only picked one target bitrate there, but from the results you can guess that it may turn out that way when going this low. So in certain cases the claim may be true I guess, but not for typical 1080p encodes.

  2. You wrote “Thanks to [Asmodian] and [MeteorRain]/[LittlePox] I got rid of x265s’ blurring issues” Could you please elaborate on those issues and the solution?

    • Hello Rod,

      My bad, I’ve linked to the users’ profiles, but not to the corresponding thread with the actual information. So here’s the [link]!

      The problem I had back then was that everything was just blurry, as if you’d have applied a slight Gauss filter to the entire video, horrible. All the very fine detail and sharp lines were just lost to the blur. I’m not sure what modern x265 does about this by default, but the options that fixed the blurring problem specifically for me were the following:

      --ctu 32 --max-tu-size 16 --no-strong-intra-smoothing

      All of it in 1920×1080 full HD, I’ve not done any tests for ≤720p or 4K/UHD. Reducing the maximum CTU size from the default 64×64 to 32×32 should prove contra-productive for very high resolutions, but it’s perfectly reasonable for 1080p, at least in my experience.

      Since then I’ve adjusted the transform unit size back to be identical to the CTU though, without noticing any detrimental effects. So this should also be fine:

      --ctu 32 --max-tu-size 32 --no-strong-intra-smoothing
      • Thanks for your reply and the link to the thread.

        I am using the latest Handbrake, v1.0.7, and MakeMKV, v1.10.8, on Windows 10 to convert a collection of Blu-rays and DVDs to h.265. I am using the constant quality setting at 20 RF for Blu-rays and 17 RF for DVDs with preset = slow, tune = none, and profile = main. All filtering is set to the defaults except decomb which is on. I don’t mind the long encode times.

        In general the files seem to look great when I play them back (I have not checked them all yet), but the DVD episodes from Babylon 5 season 4 look terribly out of focus.

        I am not sure what happened. Is this an issue with h.265 or are my settings just incorrect for such an old, low resolution TV show? I really appreciate your feedback.


        • Heh, Babylon 5! :mrgreen: Well, is it just season 4 that looks bad? It could also be that there’s some inverse telecine or some de-interlacing mess happening (The “decomb” stuff).

          You could just try and run one of the source files through handbrake while passing the additional options --ctu 32 --max-tu-size 32 --no-strong-intra-smoothing to x265. It works fine for me when dealing with DVD input. The Handbrake GUI should have an “Additional Options” field for x265, where you can specify those. If you’re doing 1-pass CRF in the slow preset, testing this shouldn’t take too long at DVD resolution.

          If that doesn’t help, try temporarily disabling the decomb and then run another test. Maybe the detected field order/field dominance for the interlaced content is wrong for those episodes, so it’s blending the fields together wrongly or something…

          If this fixes the blurring issue, you’ll need to reconfigure the decomb filter to handle the input properly. In most cases, switching the field order from top-field-first to bottom-field-first or vice versa should fix the problem. Generally, deinterlacing or decombing will always introduce some levels of blurring due to the field blending process. If you can narrow it down to the decomb, maybe Handbrake also allows you to switch the decomb filter or alter its quality settings or something (I don’t really know the Handbrake GUI, as I don’t use it myself).

          • You were right about the B5 video, it was the an interlaced video problem. I tried various handbrake de-interlace option combinations but in the end turning Decomb off fixed the problem (I am not sure how to reverse the field order). I read that letting the TV de-interlace does a better job than Handbrake and that seems to be true. Funny, frame by frame decomb looks much better but in motion no decomb looks much better.

            Using the options --ctu 32 --max-tu-size 32 --no-strong-intra-smoothing did not fix the problem but it did make my other movie encodes better. I would say it looks better than the original now, thought that should not be possible. During a fight scene in “Sherlock”, the original smeared a moving fist. With the options, at the exact same frame, the knuckles here clear again. Can the pixel motion extrapolation algorithm restore cohesion in the pixels?

            Thanks for your help

            • It shouldn’t be possible to restore motion blur in that way. The CTU/TU/intra-smoothing options I provided you with are only meant to not introduce additional blurring on top of the original content.

              It could prove useful if you could provide frame-exact comparison screenshots of the content in question. However, I may not be able to provide deeper insight into what’s happening here, even if there is a higher level of perceived detail after the transcode. The best I might be able to do is to shrug my shoulders. ;)

              So you’re probably better off showing screenshots to the people on the Doom9 forums, in the [H.265/HEVC subforum] specifically. There are some guys over there, who have much higher levels of x265 knowledge than myself!

  3. Hi, I’m using x265 2.6 with Handbrake at Linux.
    Very good article. Please of these kind “research”.

    I just started to switch from x264 to x265. Also from Windows with Avisynth and MeGUI to Handbrake at Linux.
    In the past I did some trailer encodings for digital-digest with x264 and DTS.

    x265 v2.6 runs very good and “fast” with the medium settings.


    • Hello Frankie,

      I’m also on 2.6 now, 2.6+2 to be precise. But like you, I mostly migrated away from Windows, especially since my Windows hexcore workstation (Xeon X5690) is still running XP x64, and x265 tends to run a bit slower with the XP / XP x64 compatibility patches. I’m still releasing 32/64-bit [builds for XP/XP x64/Server 2003] though, for those few people who might still be interested in encoding on those old operating systems.

      But as my new [x265 benchmark project] based on 8K content shows, Linux tends to be faster even when pitted against modern versions of Windows on the same hardware. So, good choice of OS I’d say. ;) I’m currently using it on Linux and FreeBSD UNIX, while the XP x64 workstation is usually handling H.264/AVC content only (In rare cases, it still does some x265 jobs as well, but 4K/UHD stuff is being handled by a Linux box exclusively).

      I’m still sticking to very taxing settings though, so even today (with a total of 32 cores spread across 4 machines) I haven’t fully migrated to x265. Aaand now I want some fatass AMD Threadripper or EPYC box! :mrgreen: :roll:

  4. Hey thrawn,

    It’s amazing to see you’re still replying to comments even now!

    I would like to get your opinion on some test encodes I’ve been doing. Coincidentally I’ve been using the same movie as you (Garden of words). Have you done any tests with CRF, rather than targeting a specific bitrate?

    After some testing, I settled on CRF19 with the following values

    --profile main10 --output-depth 10 --tune grain --aq-mode 1 --preset veryslow --aq-strength 0.9
    --rskip --ctu 32 --max-tu-size 16 --qcomp 0.8 --psy-rd 1.5 --psy-rdoq 5.0 --rdoq-level 1
    --deblock -2:-2 --qg-size 32 --no-sao --merange 44 --me 3 --subme 5 --no-rect --no-amp

    after some tests, I’m happy with everything about my encode, except the banding I see in a few scenes I.e the below

    The banding on the red umbrella is very obvious in low light, and seems to disappear if I pump more bitrate into the encode, but that reduces the viability of H.265 over H.264.

    Do you think there’s anything I can tune to reduce this banding, without increasing the bitrate too much?

    • for reference CRF19 gives an average bitrate of 6757kb/s for Garden of words using that profile.

      • Hello Alex,

        I had similar problems before, but other than going for 10-bit (which you already have), pumping in more bitrate has been my “solution” for this as well. There are supposed to be ways to reduce banding in addition to the sledgehammer method however, mostly focused on boosting the aq-strength in aq-mode 1. Some people suggest settings like this: --psy-rd 1.5 --psy-rdoq 2.5 --aq-mode 1 --aq-strength 1.8, some even go to --aq-strength 2.0.

        The main problem here is probably that the source already has banding artifacts, and x265 is merely amplifying them. To that end, I’ve zoomed into a part of the umbrella by 300% and boosted the brightness as well as the contrast. Here’s what a part of that umbrella looks like after that:

        BD Source banding
        This is what it looks like in the source video (+300% zoom, +45% brightness, +88% contrast)

        And this is what x265 does with it:

        x265-encoded banding
        The banding worsened, because the contrast between the brighter and darker bands has now increased (+300% zoom, +51% brightness, +82% contrast).

        Maybe you can try the settings above, with the boosted aq-strength. Other than that, I’m afraid I’m out of ideas myself. I haven’t even tried CRF on Garden of Words yet. I’ve been doing only very few CRF encodes very recently. I’m surprised that it would reach such a high ABR with a CRF of just 19. But that’s probably because of all the rain and detail…

        I fear I can’t provide any further ideas, but maybe you’d want to ask in the [Doom9 forums], maybe somebody there has better ideas for solving this issue.

        PS.: Replying on my blog is actually not that much work. It’s not overly popular in the first place, so I usually get at most 5 comments per month or so. Sometimes it’s a bit more, sometimes none at all. I find it much more amazing that people manage to put up with the insane loading times here, when posting comments I mean. Especially people who already know how bad it is and still comment a second or third time. ;) That’s what you get running modern web software on a server from 1995… :roll:

        • Thanks for your reply, detailed as always!

          I’ll run some tests with the settings you’ve mentioned and report back.

          In case you’re interested – some more 10bit H265 CRF19 average bitrates below. Interestingly enough, 6-7k seem to be the sweet spot in my encodes so far. About to run a few more Ghibli’s under the same profile.

          From up on poppy Seed hill: 7854
          kimi no na wa: 6618
          paprika: 3961
          Summer wars: 7622
          Arrietty: 5599
          Akira: 21000

          All my source files were straight BD remuxes ripped myself with MakeMKV

          Old movies with lots of grain seem to require stupid bitrates – as can be seen by Akira. Better bitrate than source, but H.264 might be better suited in those situations.

          • Ah, I’ve edited my post above while you were replying it seems (Added that last paragraph, nothing important).

            Funny: I got an ABR of ~5Mbit/s when encoding Flip Flappers. With CRF 14! Crazy. But yeah, grain is probably the biggest problem of all. You can try to add --tune grain to try and reach better results with that, but I haven’t done any comparisons using the tuning yet.

            Of course you could try to denoise the video with filters first, but I would rather invest the extra bitrate to preserve the grain as much as possible. Usually, when I tried to denoise and then sharpen, the results just looked like crap, so I stopped trying that. ;)

            • Haha noticed you edited after I replied, and ended up replying while you were replying!

              I’m already using –tune grain (It’s hidden in my command above) – I like it quite a lot, but isn’t helping too much with the bitrate.

              Was Flip flappers a direct BD source or a re encode? I’d assume the higher the source bitrate, the more opportunity for CRF to try and preserve it? Just a guess.

              I don’t like messing with filters too much as they can get pretty tedious (fix one part, make another look worse) Unless you split it up, and target only the parts of the encode you want to filter.

              I’ll mess around a bit more with the settings you mentioned, otherwise might just pump a little more bitrate into banded sources.

              • Flip Flappers was a BD source, as I do have the Blu-Rays here. Despite comparable source bitrates, it’s just not nearly as detailed as Shinkais’ movies and it isn’t grainy either, like some of the old Ghiblis. So that’s why it’s probably easier to encode.

                Anyway, please let me know if the settings helped!

                • I’m back!

                  I’ve done a lot more reading, and tests over the past few days, and I’ve settled on the below profile. This reduces visible banding compared to my last profile, and seems to reduce bitrate on average by 5-10% compared to my last profile (Some movies seem to get massive benefit though, I’m looking at you, Arrietty!)

                  Using CRF19-20 depending on the source, and I’m using the latest x265 build from https://forum.doom9.org/showthread.php?t=168814

                  --profile main10 --output-depth 10 --tune grain --aq-mode 3
                  --preset veryslow --aq-strength 0.8 --ctu 32 --qcomp 0.8 --psy-rd 1
                  --tu-intra 4 --tu-inter 4 --limit-tu 1 --psy-rdoq 5.0
                  --rdoq-level 1 --deblock -2:-2 --qg-size 32 --merange 44 --me 3
                  --subme 5 --no-rect --no-amp

                  I’ve only done three full movies so far, but bitrate examples below Interestingly enough, Arrietty is 71% smaller than on my previous settings, with these settings, with no visible quality loss.

                  Paprika – 3376kb/s 2.13GB
                  Arrietty – 3260kb/s 2.15GB
                  The Cat Returns – 6480kb/s 3.39GB

                  I’m satisfied with the results I’m getting with these settings, and unfortunately can’t spend any more time experimenting right now, so I’m going to pump my anime collection through these settings, and only manually tune/adjust if an encode comes out with a bitrate I’m super unhappy about (Looking at you, Akira!)

                  Time to go grab a coffee while I wait for your blog to post my comment! Haha.

                  • Welcome to the decelerated world of this web site, where everything feels very distant from that hectic, stressful world of modern technology that’s always moving so terribly fast! ;) :roll:

                    Ah by the way, I took the freedom to edit your posts. No content was changed of course, I just wrapped your settings in proper tags, otherwise the JavaScript here fucks everything up, like turning the -- of the options into wide dashes: . This breaks copy & paste. Stupid software.

                    Anyway, your results seem surprising. Tuning aq-mode towards dark/uniform scenes to invest more bitrate there and reduce banding… I hadn’t thought of that, even though I’ve done the very same thing for Garden of Words before (I had switched to --aq-mode 1 in the meantime… Maybe I’ll go back to 3.). Also, you lowered aq-strength? Did increasing it make things worse?

                    Hm, maybe my suggestion was completely off the mark, huh. That would mean that there is a lot of questionable information about setting those things right out there. Still shocking to see such a massive difference for Arietty though!

                    Thanks for sharing your settings and results! :)

                    • Ah thanks for that, I’ll remember to correctly format the code in the future :)

                      Yeah I was surprised myself. Wish I took notes while doing my tests – as it’s hard to remember all the details, but I don’t think I liked an aq-strength of 0.9 , coupled with an --aq-mode of 3

                      WIsh I had more time, as I haven’t properly tested adjusting the following

                      --qg-size 32
                      --merange 44
                      --me 3
                      --subme 5

                      But I’m happy with the results, and so I’ve told myself I can’t spend anymore time on this profile for increasingly tiny small returns.

        • Wow – that’s quite feat – I’m surprised the website’s even running! You working out of a museum? haha ;)

  5. Hey, thrawn. A noob encoder here. Here’s my problem. I have tons of tutorial videos, around 4 TB worth. They are all 1080p x264 AVC. I need to compress them as much as possible without making them illegible. The problem is that some of these videos are actually screen grabs which has an IDE with code open. So, too much compression would make the code illegible. And secondly, my processor is an ancient Intel i3-530 overclocked to 3.5GHz. What should be my optimal encoding settings for HEVC? I’m using Handbrake, by the way. I’ve lurked around in Doom9 fora, but I’m overwhelmed by too much information they throw at me.

    • Hello Mike,

      First: Your CPU is… *cough* “less than optimal”. In short, it sucks for encoding with x265, as the core count (2 cores with HT) is too low and you’d be lacking some helpful instruction set extensions like AVX, AVX2, BMI2, and FMA3/4 as well.

      In your case, what you’d want to achieve is a certain target quality level, and not a file size like for me. First, you’ll drop the 2-pass encoding and switch to 1-pass CRF encoding. That’ll also save you a lot of CPU time. Quality can be adjusted by changing the CRF with --crf which takes values from 0 (lossless) to 51 (very low bitrate).

      Second, encoding speed and quality can be drastically altered by switching presets with --preset. Valid values are 0..9 or the values ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow and finally placebo.

      Third, we’ll drop some “Anime options” I got from Doom9 and some Anime communities in there, as those are meant to boost quality for high contrast lines and large areas with uniform color, just like it is in your case.

      So, maybe start with this…

      --preset medium --crf 20 --aq-strength 0.65 --qcomp 0.75 --no-strong-intra-smoothing --deblock 0:0

      …and then start turning the two important knobs --preset and --crf. Handbrake should have those somewhere on its GUI as well. I’d change the preset first to reach a “somewhat ok” quality level at an acceptable encoding speed. From there I would probably tune the CRF to reach more quality, but you might find that you need to work with both at the same time to reach your goal. A very slow preset with a high (=low bitrate) CRF is likely not what you want as it’ll look bad and encode very slowly. But a preset like ultrafast with a very low, (=high bitrate) CRF like 14 might also not be quite right.

      But in essence, if you wanna keep it simple and quick, leave the rest alone and try to reach your target by adjusting just those two most significant options without touching anything else. That’s what the presets and the CRF are for anyway.

      If you have like 4TB to transcode, you might really consider buying a dedicated transcoding machine though, or just leaving it to a very fast H.265 ASIC chip like some modern Intel, nVidia and AMD GPUs have (Intel HD Graphics 6**, nVidia GeForce 10*0, AMD Radeon 4** series). AMDs Zen and Threadripper CPUs seem to be pretty good as well, when it comes to x265s’ CPU-based work, at slightly more affordable prices when compared to equally fast Intel CPUs. Just saying… transcoding 4TB of material with x265 on a Clarkdale dual-core chip like yours sounds like… agony. No matter which preset you choose.

      • Thanks for the prompt reply, mate! I do agree that an upgrade of my processor is way long overdue. I’m waiting for Coffeelake i7 – 8700 to hit the local market. I do have a NVidia Graphics card: EVGA GTX 1050 2GB Superclocked, to be exact. Would that fare better at encoding than the processor? I heard terrible things about NVenc, so I was apprehensive about using it. What should be my settings, if I choose to go down the NVenc path?

        • Hey Mike,

          At identical bitrates, it would surely never be able to reach the quality x265 can. But it would be much faster. The same was true for H.264/AVC and x264 as well. To be honest, I don’t have any actual hands-on experience with GPU/ASIC encoding, not with NVenc, Intel Quicksync or the AMD VCE. I just mentioned it, because it may become your only viable option in case the CPU is just too slow to encode H.265/HEVC at a decent quality level. I mean, 4TB of data… That’s nothing to scoff at!

          But since I don’t have any experience with any of the ASICs available myself, I can’t really recommend any settings, sorry for that. :(

          Anyway, that i7-8700 hexcore would surely be a nice option! With that modern architecture and a 4.3GHz all-core-turbo, you’d be set, at least for 1080p H.265/HEVC encoding with x265. Pricing also seems reasonable enough.

          • Hey, thrawn. I’ll be getting my new system this week. Should I go for the Ryzen 7 1700 or i7-8700? Is better IPC with less number of cores more desirable than more number of cores with worse IPC for x265 encoding?

            • Hello again Mike,

              Basically: IPC always works, but scaling across cores depends on several things: number of cores/threads, resolution of content and to a degree also your encoding settings. As for Ryzen 1700 vs. i7-8700: My own full-8K x265 benchmark is a bit too young, so I can only offer a Core i5-8600K @ 4.7GHz vs. Ryzen 1700 @ stock and @ 3.18GHz comparison. Here’s the [link]. In that test, Ryzen 1700 comes very close, but is still beaten by the highly overclocked i5-8600.

              Clearly, that’s not enough to make a decision, but the large German website “Computerbase” also uses the “x265 HD benchmark” for their CPU tests, see [this link]. In this 1080p encoding benchmark, the 8700 comes in at 27.39fps, beating the Ryzen 7 1700 at 24.61fps. That’s roughly a 10% difference.

              It seems that the 1080p benchmark might not have utilized all the 16 threads of the Ryzen 1700 as well as my 8K benchmark did. So if you’re going for 4K+, the Ryzen might be the better option, but if you’re staying at full HD, the Intel might be better.

              Anyway, both are reasonably fast, and their performance doesn’t differ too much, so you’ll likely be happy with either.

              I myself will probably go for a Ryzen Threadripper for 4K content in the future. I’m just not sure whether I should wait for the second generation that’s supposed to launch in the second half of 2018…

              • Thanks for the advice, mate. I like the TR4 platform as well, but that might be overkill for me. For now, I think I’ll settle with Ryzen 1700 and then go for Zen 2 in 2020. And my two cents, unless you’re absolutely hard pressed to get a new system right now, wait for Threadripper refresh.

  6. Hey man … this was very enlightening.

    Just a question though: Were these frames grabbed at comparable positions frametype-wise? That is, did you make sure to never accidentally compare intra-frames with inter-frames? Else that would be a bit of an unfair comparison.

    I am not sure how to guarantee this kind of thing, but thought this may be an important factor.

    • Hey Tom,

      Uh… That’s actually an interesting question… I think you might have uncovered a slight flaw here.

      I am not even sure if the GOP sizes (=the I-frame positions) are similar between my x264 and x265 runs. Even if so, the GOP structure within would likely be different, so I can’t guarantee which frame types I grabbed. There might be a mix of P- and B-frames even amongst comparisons using the same codec. Furthermore, in case the GOP sizes do differ between encoding runs, it might even be a mix of all three frame types.

      I need to look for those files and analyze their GOP structure using something like this:

      $ ffprobe.exe -show_frames video.h264 | grep pict_type >frametypes.txt

      There are ways to fix the GOP structure, like --keyint 250 --min-keyint 250 --no-scenecut --b-adapt 0. The first two fix the regular GOP size, the third ensures that adaptive I-frame placement is really turned off and the last disables adaptive B-frame placement as well. That should also lock down the position of P-frames (if I’m not making a mistake here).

      Not sure how much difference it really makes (probably not too much?), but you’re very likely right assuming that I’ve compared different frame types…

      However, to really do this 100% right, I would need to re-encode all streams and re-do the entire comparison… which quite frankly, I’m too lazy to do. :(

  7. bro thanks for this ..hevc seems to do a good job at lower bitrates comparing to x264 it gaves me a good idea about how it works ..
    i just have a question ,since you look experienced in media encoding ..
    i have small monitor and a hisense TV medium screen ..using the pc to play the video files it looks normal and sharp on the monitor ..but on the TV its always Noisy it just looks ugly whatever the video resolution is ..i tried lowering the sharping in the TV in order to wash the noise but it makes the image very blurry..the TV image is normal it self its just when playing a file from the pc through the hdmi..would appreciate any advice.

  8. Wow great article.
    Thank you so much.

    I was wondering by which program you took lossless screenshot of specific frame for comparison?
    I’m looking for similar program to compare my encodes (By screenshot of frame).

    Thanks again.

    • Hello Elwynne,

      This is actually described in the article above. ;) Please read the last part, the addendum, it addresses your question.

      You may not be a Linux or UNIX user, but the player I used to make the snapshots – [mplayer] – is also [available on MS Windows], so it should be possible to use my method on pretty much any operating system, as long as you can handle a command line terminal.

      Another standard tool for doing stuff like this would be [ffmpeg] (which is the library collection mplayer sits on top of anyway). There are Windows builds of ffmpeg too, but you need to read the documentation or search the web to learn the options for making screenshots every n frames. There should be some examples you can just copy & paste on the web.

  9. Wow. That’s really big article took lot of time but worth it. Thanks for the screenshots. Does presets matter? I recently started encoding a video in medium preset and it showed 10min video gonna take 4hrs and in fast preset it completed in 1.5 hrs. I didnt see any diff with quality. Does it stay same in all video encodes?

    • Hello Nalluri Anish (not sure which is your given name ;) ):

      Besides bitrate, presets are what matters most in terms of encoding speed and quality. But if your bitrate is high enough and you compare two presets that are comparatively close to each other (like you did), you might not spot any differences without looking very closely at the result (e.g. still image comparison, zooming in, inspecting borders, color bleeding, encoding of red gradients etc.). For reference, this is what the presets mean:


      First, the default one, the medium preset. For all the others, only options differing from the medium preset will be shown.

      --preset medium (Default):

      --aq-mode 1 --b-adapt 1 --bframes 3 --deblock [1:0:0] --direct spatial --me hex
      --merange 16 --partitions p8x8,b8x8,i8x8,i4x4 --rc-lookahead 40 --ref 3 --scenecut 40
      --subme 7 --trellis 1 -weightp 2

      --preset ultrafast:

      --no-8x8dct --aq-mode 0 --b-adapt 0 --bframes 0 --no-cabac --no-deblock --no-mbtree --me dia
      --no-mixed-refs --partitions none --rc-lookahead 0 --ref 1 --scenecut 0 --subme 0
      --trellis 0 --no-weightb --weightp 0

      --preset superfast:

      --no-mbtree --me dia --no-mixed-refs --partitions i8x8,i4x4 --rc-lookahead 0 --ref 1
      --subme 1 --trellis 0 --weightp 1

      --preset veryfast:

      --no-mixed-refs --rc-lookahead 10 --ref 1 --subme 2 --trellis 0 --weightp 1

      --preset fast:

      --rc-lookahead 30 --ref 2 --subme 6 --weightp 1

      --preset slow:

      --b-adapt 2 --direct auto --me umh --rc-lookahead 50 --ref 5 --subme 8

      --preset slower:

      --b-adapt 2 --direct auto --me umh --partitions all --rc-lookahead 60 --ref 8 --subme 9
      --trellis 2

      --preset veryslow:

      --b-adapt 2 --bframes 8 --direct auto --me umh --merange 24 --partitions all --ref 16
      --subme 10 --trellis 2 --rc-lookahead 60

      --preset placebo (You’ll likely don’t want this):

      --bframes 16 --b-adapt 2 --direct auto --slow-firstpass --no-fast-pskip --me tesa
      --merange 24 --partitions all --rc-lookahead 60 --ref 16 --subme 11 --trellis 2


      Again, for all presets aside from the default one, only differing options are listed:

      --preset medium (Default):

      --ctu 64 --min-cu-size=8 --bframes=4 --b-adapt 2 --rc-lookahead 20 --lookahead-slices 8
      --scenecut 40 --ref 3 --limit-refs 3 --me hex --merange 57 --subme 2 --rect 0 --amp 0
      --limit-modes 0 --max-merge 2 --early-skip 0 --recursion-skip 1 --fast-intra 0 --b-intra 0
      --sao 1 --signhide 1 --weightp 1 --weightb 0 --aq-mode 1 --cuTree 1 --rdLevel 3
      --rdoq-level 0 --tu-intra 1 --tu-inter 1 --limit-tu 0

      --preset ultrafast:

      --ctu 32 --min-cu-size=16 --bframes=3 --b-adapt 0 --rc-lookahead 5 --scenecut 0 --ref 1
      --limit-refs 0 --me dia --subme 0 --early-skip 1 --fast-intra 1 --sao 0 --signhide 0
      --weightp 0 --aq-mode 0 --rdLevel 2

      --preset superfast:

      --ctu 32 --bframes=3 --b-adapt 0 --rc-lookahead 10 --ref 1 --limit-refs 0 --me hex --subme 1
      --early-skip 1 --fast-intra 1 --sao 0 --weightp 0 --aq-mode 0 --rdLevel 2

      --preset veryfast:

      --b-adapt 0 --rc-lookahead 15 --ref 2 --subme 1 --early-skip 1 --fast-intra 1 --rdLevel 2

      --preset fast:

      --b-adapt 0 --rc-lookahead 15

      --preset slow:

      --rc-lookahead 25 --lookahead-slices 4 --ref 4 --me star --subme 3 --rect 1 --limit-modes 1
      --max-merge 3 --rdLevel 4 --rdoq-level 2

      --preset slower:

      --bframes=8 --rc-lookahead 30 --lookahead-slices 4 --ref 4 --limit-refs 2 --me star
      --subme 3 --rect 1 --amp 1 --limit-modes 1 --max-merge 3 --b-intra 1 --weightb 1
      --rdLevel 6 --rdoq-level 2 --tu-intra 2 --tu-inter 2 --limit-tu 4

      --preset veryslow:

      --bframes=8 --rc-lookahead 40 --lookahead-slices 4 --ref 5 --limit-refs 1 --me star
      --subme 4 --rect 1 --amp 1 --limit-modes 1 --max-merge 4 --recursion-skip 0 --b-intra 1
      --weightb 1 --rdLevel 6 --rdoq-level 2 --tu-intra 3 --tu-inter 3 --limit-tu 4

      --preset placebo (Again: You may want to stay away from this)::

      --bframes=8 --rc-lookahead 60 --lookahead-slices 1 --ref 5 --limit-refs 0 --me star
      --merange 92 --subme 5 --rect 1 --amp 1 --max-merge 5 --recursion-skip 0 --b-intra 1
      --weightb 1 --rdLevel 6 --rdoq-level 2 --tu-intra 4 --tu-inter 4

      If you want to learn more about what the settings mean, well, at least x265 has a pretty good [command line documentation], whereas you might need to search the web for detailed explanations of the x264 ones. Quite a few are of comparable effect though.

      If you want to try and spot actual visual differences between presets, you might want to pick two of them which are farther apart, like --preset veryfast and --preset slow or something, and make sure your bitrate is at sane levels.

      Ultimately, the best thing would be to pick some demanding content (hard to encode, lots of details, reds, and lots of movement plus some still scenes), and then encode that at your chosen bitrate with all available presets, and note the time required for each run. Then carefully inspect the outputs, consider the encoding times, and pick the one that’s perfect for you / your requirements.

      That’s it!

  10. Funny, funny indeed I stumbled into your article the day after I enjoyed “the garden of words” !

    (just noticed the screenshots, now I’m going on reading the real stuff)

    • Ah, I see.. I thought Makoto Shinkei only made a movie, but it seems he wrote a novel/manga before that as well… I didn’t know about that until you mentioned it just now!

      I’m also eagerly looking forward to his next movie, “Your Name.” (君の名は。 Kimi no na wa.). According to my watchlist, it’s another 217 days until the US BD release. Bah, the waiting… ;)

      • “Your name.” is Shinkai’s masterpiece, I’ve seen it in theater on release day.
        Enjoy your BD, and watch it on the biggest screen you have, it deserves it.

  11. Since I’m too lazy to edit the main article, I’ll just post this as a comment instead: I did a quick & dirty ultra low bitrate comparison now as well, to see how x264 and x265 behave under extreme constraints.

    While I would typically pick 2500kbit/s for Anime, I did two runs at just about ~2-3% of that bitrate.

    Link: [x264 vs. x265 ultra low bitrate comparison]. It’s not a very extensive comparison, but I was just curious how bad things would get at “near-modem” level bandwidths. ;)

  12. Just want to say. Thank you so much for this article and comparisons!!

    • Hello dahlia.

      You’re welcome! :) Please note though, that this comparison is getting a little old now. These tests were run with an early x265 v1.9 after all, while we’re now at 2.2+23, and there’ve been quite a few changes in the meantime.

      While I can’t say how significant those are quality-wise, this comparison will get less and less representative over the years, so maybe I’ll redo it in a new post sometime in 2017 or 2018. I’m also planning on doing an extremely-low-bitrate comparison as well (just for fun, that one).

  13. Specifically didn’t read this article because of the use of anime instead of an actual movie.

    Please don’t do that.

    • Hello Mr./Mrs. Anonymous,

      Oh, I will continue to “do that” (transcode animated content and talk about it publicly, that is, amongst many other things). So please, refrain from commenting on articles you did not even read, that are about things you seemingly do not even have any interest in. It makes you look like a troll. Also, please refrain from telling other people what they should do with their time, skill or interests. Makes you look like a troll as well.


      Thank you very much.

      PS & FYI: I do not have any interest in “what everyone does”. I have interest in what I want to do. And that’s about it. You don’t like it? Fine! Then it’s go-away-day for you. ;) The internet is wide and open, just go find an article that piques your interest more than this one…

  14. umm hello sir.. im noob at video compression. what software did you use for this topic? can i use same settings in handbrake?

    • Hello Firos,

      I’ve used libavs’ avconv.exe as well as x264.exe and x265.exe. The x264 binary was taken from the [developers], the x265 one I’ve compiled myself[1][2], you can download my versions of avconv and x265 [here].

      I’m not really a Handbrake user, but I assume you could feed the options seen above to it as well, given that Handbrake is also just using libx264 and libx265. You’ll have to mix the settings together though, as some of them can already be configured on Handbrakes’ GUI itself, while others need to be passed to it as “Additional options”. In that text field you should be able to enter the options directly as seen above, e.g. --no-fast-pskip --cqm flat --non-deterministic and so on.

      You’ll have to play around with that a bit though, also regarding the 2-pass mode I’m using. It might be easier to recreate what I did here if you just stick to the command line. I can elaborate on the exact commands I launched later, but for now I’ll have to leave for our workplaces’ Christmas party! ;) If I don’t forget, I’ll post the exact command lines here later!

  15. Hi,

    My sister had a massive collection of movies but she renamed them all and remove the 264x and 265x in the filename . . . is there a way to know which is 264x and the 265x?

    • Hello John,

      Ah, yes, there are ways. However, I am more of a UNIX user these days, and I’ll just blatantly assume that you’re on Microsoft Windows, yes? So I’ll show you how you can achieve that using the tools I’m using, but you’ll need to set up a bit of software:

      • [Notepad++] (a very good text editor, we’ll need it because the file we’re going to open with it will have UNIX line breaks, which Notepad can’t handle.)
      • [GnuWin32] (A collection of free and open source UNIX/Linux tools for Windows. We’re going to use the `grep´ tool coming with it.)
      • [MediaInfo] (A tool to get media stream information. Works with pretty much every multimedia file. Make sure you get the CLI version, not the GUI version! We want this to be scriptable!)

      GnuWin32 will take a bit of time to install I think, so please be patient with it. Also, make sure that the tools grep.exe and MediaInfo.exe are in your search path before continuing, it makes things easier. If you don’t know how to do that on your version of Windows, just search the web for "Windows 7" path environment variable or so, it’s really easy.

      Now, if grep, MediaInfo and Notepad++ are all installed, we can combine the Windows commandline with the power of some UNIX tools. For now, let’s assume your video files are in a collection of subfolders sitting in X:\videos\. It does not matter how deep the folder structure runs. Furthermore, let’s assume it’s all .mkv files. Hit <Windows Key>+R or click Start/Run, then enter cmd.exe, hit <ENTER>. Now you can run a simple recursive FOR loop over all your files (see [FOR /R documentation]):

      X:\>FOR /R "X:\videos\" %I IN (*.mkv) DO MediaInfo.exe "%I" | grep -e videos -e 264 -e 265 >>X:\analysis.txt

      This loop will run through all files ending with .mkv somewhere in or below X:\videos\, run MediaInfo on them and filter the ouput for a part of the path name (you’ll see why) and for the strings 264 as well as 265, then write the resulting report to X:\analysis.txt in append mode (>>).

      When it’s done, just open X:\analysis.txt in Notepad++, and you’ll have what you need. I’ll give you a (partially fake) sample, it should look somewhat like this:

      Complete name	: X:\videos\subfolder2\file1.mkv
      Writing library	: x264 core 148 r2705 3f5ed56
      Complete name	: X:\videos\subfolder2\file2.mkv
      Writing library	: x265 1.9+200-6098ba3e0cf16b11:[Windows][MSVC 1600][64 bit] 10bit

      If you’re unfamiliar with UNIX or any Windows command line, you might find this complicated and unnecessarily hard, but it’s much, much easier than doing everything manually in the long run, especially since you said it was a “massive” collection.

      I really hope this helps! :)

      • Thanks for reply :)

        I almost got a headache reading your instructions :) beacause I’m not that computer techie guy and you’re right I’m totally no clue about UNIX and Windows command line but still I give it a shot.

        I’m collecting videos which is x264 format only and copying to my sister’s 4TB video collection yeah that’s a lot “massive” and that’s really painstaking task to identify which is x264 if only she didn’t renamed them.

        Hopefully there’s a software that can identify the format of batch video files with only a few clicks . . .

        Thanks a lot thrawn :)

        • Hello again John.

          Ok, I understand. Hm, maybe I could pack the tools into a portable version for you, so you only have to run a simple batch script that does the magic for you. Shouldn’t be too hard to do. I’ll fool around a bit with it and report back here, as soon as I’m done. I’ll have to leave now, but in the afternoon (I’m in UTC+1) I should find some time to do that.

          • Wow! thanks a lot thrawn that will be a really great help because it will make the task very easy for me, can’t wait the portable tool batch script you make :)

            I posted to other pages but none got the solutions, luckily i find your page :)

            • Hey again John,

              Ok, I think it’s all done and ready for use. You can’t just double-click it however, you’ll still have to use the command line. But it’s going to be easy enough I think. First, download the package:

              I suggest you unpack it directly to C:\ to make things easy. Now, launch a cmd terminal window, like this on Windows 7 for instance:

              Start the cmd on Windows 7

              Enter the directory C:\identifyMedia\ and run identifyMedia.bat like shown below:

              Running identifyMedia on Windows 7
              How to enter the directory where identifyMedia was unpacked, and how to launch it (Click to enlarge)

              So the syntax is identifyMedia.bat "<MEDIA PATH>" "<REPORT FILE>"! Note that you must put the directory names and file names under double quotes to make sure it’ll behave properly. Otherwise the script will easily fail.

              So, in essence: Unpack the identifyMedia.zip to C:\, start a cmd, enter the directory where it was unpacked and run identifyMedia.bat with proper parameters. Wait until it’s done, then open Notepad++ (also included with the package) and open the report text file in that editor. That should do it.

              The script will test if the media directory exists and it will test whether you’ve provided two parameters for it. That’s how far error handling goes. If you want to see how the script works, just edit the .bat file with Notepad.

              Currently, it’ll look for and scan the following file names: *.mkv, *.mk3d, *.mp4, *.ogm, *.avi, *.mov, *.mpeg and *.mpeg2. Adding more types is very easy by editing identifyMedia.bat, just look for the extension list near the end of the script.

              I hope this is simple enough for you to handle this way. I don’t think I can strip it down any further without investing considerable work. I can’t easily build you a graphical user interface for this… Too time-consuming for such a simple task.

              • Hi thrawn,

                Yes! this is it, thanks for making your instructions so simple as possible and easy to follow considering me as a total noob :)

                I appreciate your effort and i don’t know how to thank you enough, this is really a great help and very useful tool for the video and movie collectors like me :)

                Right now I’m on a trip, I will share this page to others needing this. Thanks again thrawn!

                • Hey John,

                  Good to hear that it works for you! :) It’s still too specialized and too error-prone to be of any general use though. It would need better error handling & user feedback as well as support for identifying other codecs like DivX, XviD, MPEG-2, WebM and so on and so forth. Also, it should support more file suffixes, like .webm or .flv and others.

                  But anyone who knows just a tiny little bit of programming/scripting could easily extend it to make it more useful in that regard. It’s just that Windows Batch is such a weird, obscure language… Writing it is quite painful, so I’d rather stop now, since your problem has been solved anyway. :)

  16. What are people generally exporting H.265 at compared to H.264? We have been trying 8bit and it has been working well. But so many people insist we are going too low so I have started testing 10bit. I dont have a big UHD TV to test on at the moment, so any experiences would be welcomed. At 8bit we were getting file sizes almost a third of the H.264 version. We just kept pushing it down and didnt seem to lose any quality until below 8bit.

    • Hello James,

      I’m having a bit of trouble fully understanding your English, but I think you’re asking about acceptable bitrates? Please be advised, that 8-bit vs. 10-bit isn’t typically about the actual color space, but rather about something very different, and that holds true for both H.264/AVC and H.265/HEVC. And it’s the reason why nobody does 12-bit for releases (besides 12bpc not being a part of the BD4K spec).

      On 8-bit per color channel, all internal arithmetics are being done using 8-bit integers as well. That makes sense, right? However, when going to 10-bit, an 8-bit operation couldn’t handle it and an 8-bit operand couldn’t hold the data. There are no 10-bit ops however, so what’s the next step? 16-bit.

      So by going from 8-bit to 10-bit, you boost the internal arithmetic precision of some parts of the code from 8-bit to 16-bit, and that’s a good thing! It’ll cost you some time in encoding, but it’ll give slightly better results on one part: color gradients. So if you’re doing animated content with lots of fine color gradients, going to 10-bit is worth it. Going to 12-bit is not, because there are nearly no hardware decoders for 12-bit and the internal precision wouldn’t be boosted any further either. Needless to say, nobody has deep color monitors/TVs for that anyway (36-bit color). If you want a better color representation, you’d be better off boosting the chroma subsampling from 4:2:0 to 4:2:2 or all the way to 4:4:4 first, including the necessary linear bitrate boost (only applicable if your source is raw/4:4:4 of course).

      That being said, if you can afford to deliver 10-bit H.265, by all means do! If your clients can handle it, it’d be worth it, even at the same bitrates!

      Now, about the bitrates; This is subjective. I would recommend presenting several sample clips to your user base, all encoded at different bitrates, and have them vote on “which is the best” or something similar. But you need to make the test blind enough so users can’t tell whether they’re getting high or low bitrate content beforehand!

      That should give you some information about the point at which users start to notice a drop in visual quality. From that point on, go 1 notch higher, and you’re done. I’d recommend 1000kbit steps for 4K and maybe 500kbit steps for 1080p, could be 3-4 steps for each.

      Alternatively, you could do the comparison all by yourself in-house and just see at what point you would perceive a clear drop in visual quality. Just make sure you’re feeding yourself data you know nothing about beforehand, so you can judge objectively.

      Problem solved?

      PS.: There is no “below 8-bit”. 8 bits per color channel are the lowest you can go to my knowledge anyway…

  17. Love this topic p much

    As for me being enter the encode stuff like 2 day ago with 2011 Pentium 4 and no VGA Card.
    This topic really satisfied me when watch those screen comparisons. xD

    Meanwhile reading this topic, I’m waiting to finish x264 (Episode 360p Anime) > x265 Medium & 2-Pass 256 Bit in Ripbot264 took me around 2 hrs.

    I can’t imagine how much time to the 1080p one :(

    • Hey,

      360p… Haven’t touched anything in that field for quite some time. However, I am using x265 to transcode low-res stuff (480p – 576p), because it’s faster and it plays back on all kinds of devices. As for how slow it can be with 1080p @ 2.5Mbit, well… quite slow. In the end, what you’ll need to make it bearable is a Haswell or Skylake x86 processor with 8 or more cores. At round 16-20 cores (=S2011-3 Xeons) the fun starts I’d say.

      With that kind of hardware, you wouldn’t need to worry any more. I’m just “emulating” that by pushing jobs to my Linux workstation (i7 980X hexcore) and my FreeBSD encoding slave (AMD FX-9590). But yeah, x265 at insane settings does take its toll…

      • Thanks for reply :D

        Actually my yesterday from x264 (1059kbps) > x265 (259kbps) took me for 2+2 hrs

        I’ve no idea that 2-Pass also meant 2 times O_o
        Hard learn…

        I’d want to know if you using any commands for x265 Encode/Transcode in specific frame (or time) like frame 500 to frame 600. Command that similar to –sync in mkvmerge or anything that make it fast for testing and failing. Been looking in x265 Doc but still no clue.

        Its seem like taking full Episode / Movie are forever long with my poor pc also my UPS went bad lately so I can’t rely on this anymore hahaha

        Thank again thrawn

        • Hello,

          This is not something that should be done in the encoding stage for now. It would be better to do it in the decoding stage, e.g. with ffmpeg or avconv. Let’s give you an example:

          $ avconv -r 24000/1001 -i video.h264 -ss 00:05:00 -frames:v 100 -f yuv4mpegpipe \ 
          -pix_fmt yuv420p -r 24000/1001 - 2>/dev/null | x265 - --y4m -D 10 --fps 24000/1001 \ 
          -p veryslow --pmode --pme --open-gop --ref 6 --bframes 16 --b-pyramid --bitrate 500 \
          --rect --amp --aq-mode 3 --no-sao --qcomp 0.75 --no-strong-intra-smoothing \
          --psy-rd 1.6 --psy-rdoq 5.0 --rdoq-level 1 --tu-inter-depth 4 --tu-intra-depth 4 \
          --ctu 32 --max-tu-size 16 --pass 1 --slow-firstpass --stats v.stats --sar 1 \
          --range full -o pass1.h265 && avconv -r 24000/1001 -i video.h264 -ss 00:05:00 \
          -frames:v 100 -f yuv4mpegpipe -pix_fmt yuv420p -r 24000/1001 - 2>/dev/null | x265 - \
          --y4m -D 10 --fps 24000/1001 -p veryslow --pmode --pme --open-gop --ref 6 \
          --bframes 16 --b-pyramid --bitrate 500 --rect --amp --aq-mode 3 --no-sao \
          --qcomp 0.75 --no-strong-intra-smoothing --psy-rd 1.6 --psy-rdoq 5.0 --rdoq-level 1 \
          --tu-inter-depth 4 --tu-intra-depth 4 --ctu 32 --max-tu-size 16 --pass 2 \
          --stats v.stats --sar 1 --range full -o pass2.h265

          Here, avconv is being given the parameters -ss 00:05:00 for seeking to a key frame close to 5 minutes into the source video and -frames:v 100, telling it to decode 100 frames. That input is being fed to x265 as usual. Note that there’ll be some small initial delay depending on how far you seek into the file with -ss, as the decoder has to make its way through the source video up until an I-frame close to the designated point. For me it was around 10 seconds of delay seeking to 00:12:00 in a 1080p H.264/AVC stream using a Core i7 980X. Just one example.

          With this you can pick small chunks from anywhere in your source file and feed them to x265 the way you want!

          Also, please be aware that 2-pass --bitrate encoding is only for you, if you want to target specific birates and file sizes. If you want a certain level of quality without caring for what file size is needed to satisfy the required level, you might want to look into faster --crf 1-pass encoding instead of --bitrate 2-pass.

          • Hello again and thanks for an infomative knowledge.

            I’ll keep looking in your blog and x265 for WinXP / XP x64 from time to time. ^^

  18. Your x265 settings are on the extreme side. Also, bframes 16 can increase the encoding time a lot. rect and amp require a ton of encoding time, amp gives very little in quality and asks for a ton by increased encoding time. –max-tu-size 16 prevents the encoding from going down to 8×8 CUs resulting in fine details being missed. –Max-tu-size 16 is why the rain drops won’t be as crisp as they other wise could be. –ctu 32 is good and bad, it’ll help retain quality at 1080p and below, but is less efficient – I use ctu 32 as well. It’s also faster than ctu 64. :)

    Try these settings with –crf 20-22 depending upon your target bitrate. Since you mentioned 2.5 start with crf 22 and go up or down from there. Setting a specific bit rate forces the encoder to use the target bitrate even if the frame doesn’t need it, wasting bits and encoding time. CRF is a constant quality, some frames need more some need less.

    –profile main10 –output-depth 10 –ctu 32 –bframes 6 –rc-lookahead 40 –scenecut 40 –ref 5 –limit-refs 3 –me 3 –merange 26 –subme 3 –no-rect –no-amp –limit-modes –max-merge 3 –early-skip –b-intra –no-sao –signhide –weightp –weightb –aq-mode 2 –aq-strength 1 –cutree –rd 4 –tu-intra-depth 3 –tu-inter-depth 1 –psy-rd 1 –psy-rdoq 1 –rdoq-level 2 –qcomp 0.65 –no-strong-intra-smoothing –deblock -1:-1 –qg-size 16

    Since you wanted a lot of bframes, you could try using –bframe-bias 0-100 to influence how often bframes are used. Keep in mind that with a lot of motion, less bframes will be used.

    I can get anywhere from 5-15 fps with the settings above on a dual E5-2670 v1 (8c, 16t). It depends upon the crf used and the average bit rate, higher bitrates slower speeds – as you know. :)

    • Ugh I can’t edit my comment. I would use –rect in this case because the settings I suggested have –limit-modes which makes rect and amp more selective in what they processing, meaning they are faster with little quality loss.

      • Hey brumsky,

        My apologies for the missing edit function. To enable that, I’d need to give users the right to register and log in here. This is unfeasible however, because I need a pretty elaborate caching system to 1.) boost PHP speed and 2.) serve people static HTML whenever possible. If I’d let you log in I need the static HTML cache disabled, which means you’d be calling compiled PHP byte code all the time. And this is a [Pentium Pro 200MHz server] from 1995 running pretty heavy web software from 2016, the “performance” would be unbearable. Maybe you’ve noticed when you submitted your comment (an interactive action, that needs PHP calls on the server). So I can’t give people edit capabilities, because they’d find the loading times to be unacceptable.

        As for --bitrate: I had my fair share of trouble with CRF, especially with noisy files. File sizes just exploded. Also, deterministic file sizes are typically something I’d go for above assured quality levels. Of course, most people would say it’s a stupid idea in times where hard drives are so cheap, but I’m sticking to it even now. And tons of B-frames… I’m aware of them being very costly, but I was just thinking that there is so much static content in Anime, it just had to pay off? Maybe I’m wrong there…

        About --max-tu-size 16, I just copied that from somebody suggesting me that setting along others on the Doom9 forums, when I was asking about how to get rid of x265s’ terrible blurring issues. I didn’t really understand the setting. Besides --ctu 32 this was another option suggested in that context. Although maybe unrelated? I guess I could try to go back to the default --max-tu-size 32, if it helps to retain fine detail at the cost of some computation time.

        I gotta admit, there is one general problem though: I think I am one of those stupid people the “placebo” profiles were originally made for. Like, throwing entirely unreasonable amounts of CPU power at the issue at hand without getting anything above “barely measurable” back in return, while telling myself that I’m squeezing the utmost out of every byte used. I’m trying to keep that stupidity of mine under control as much as possible, but it’s not easy! :ugly:

        I guess in the end I should just take your settings and mine (maybe with --max-tu-size 32) and compare them side-by-side at my target bitrate just to see whether I can notice anything.

        Currently, I do have one Xeon X5690 (XP x64), one i7 980X (CentOS 6.8 Linux) and one AMD FX-9590 (FreeBSD 10.3) for encoding however, so I do have enough power. Right now I’m holding back a little because there are still quite a few TVs and Tablets which can’t handle H.265 very well, especially the 10-bit flavor… So I’m only encoding SDTV stuff with x265, because I can lower the bitrate, and then it’s still pretty fast even at extreme settings. :)

        But I will take your suggestions into account. At one point in time, x265 will have to become my main encoder, and then I’ll need to do use it as perfectly as possible within the constraints of given target bitrates… So thank you for your input!

        • Haha, I wasn’t attacking or anything about the lack of an edit button. :)

          For shits and giggles could you encode your anima again with the settings I suggested and post a couple of screenshots? I’d like to see the difference.


          • Hey brumsky,

            Yeah, I can do that. I’ll push the raw BD data to my FreeBSD/AMD FX-9590 video cruncher over the net, that machine doesn’t have work at the moment anyway. My other two, the CentOS Linux/i7 980X and the XP x64/Xeon X5690 aren’t free at the moment.

            You’ll have to give me a bit of time for this, I’m not sure I can get it done before or during the weekend. Maybe beginning of next week. I’ll post the screenshots when it’s done! :) Also, I’d keep the --bitrate, so it’ll be comparable! That is unless you insist on --crf?

          • Hello again brumsky;

            I might need to edit this comment a few times before the formatting looks right (galleries are a pain in comments, have to do it manually), so if it looks weird, just reload at a later time. ;) All of this is now H.265/HEVC. The first, larger image is the source file, then comes a row of my original screenshots, and then another row of screenshots with the movie encoded using your settings at each target bitrate.

            I gotta say, I seem to have forgotten my original --framestep value, so unfortunately, the scenes aren’t exactly the same. Also, it was encoded with x265 v2.0+9 instead of 1.9+15, so the encoder is much newer as well. So it’s a little bit of apples vs. oranges, but it should still be reasonable for a quick comparison. Let’s go with the first scene:

            Scene one, source
            Scene 1, source material

            Scene 2:

            Scene two, source
            Scene 2, source material

            Scene 3:

            Scene three, source
            Scene 3, source material

            Scene 4:

            Scene four, source
            Scene 4, source material

            Scene 5:

            Scene five, source
            Scene 5, source material

            Scene 6:

            Scene six, source
            Scene 6, source material

            Scene 7:

            Scene seven, source
            Scene 7, source material

            I won’t go into much detail, but it’s pretty clear that there is a noticeable detail loss across the board when going from my “extreme” settings to yours. Yes, the encode was faster by several factors (I would say 6-8 times as fast, though that’s a rough estimate, I didn’t measure the runtimes), but clearly at a cost, depending on the scene of course. At some points, detail retention seems to be equal to your settings, and sometimes yours are much worse…

            What can’t be seen in most scenes is, that your settings are giving worse blocking artifacts, which is especially noticeable at 1MBit. Look at the ironing scene for instance, here we can see a combination of both more detail loss and pretty badly visible macroblocks.

            Well, I haven’t compared all the scenes with each other yet, so those are just some spots that caught my eye. If you can find any frames / spots that do look better with your settings (like some of the rain parts?), just point them out!

            • Hey Thanks a lot for doing that. I don’t own a lot of anima so it’s difficult for me to test. I agree the 1mbit looks like shit with my settings. haha. 5mbit doesn’t look that bad to me, its not as good but theres always a trade off. Speed vs quality.

              I wonder if –early-skip is to blame for that.

              Thanks again I appreciate you taking the time to run the encode.

            • Thinking about this a bit more I can see why there is such a bit difference between my results and yours. I use CRF exclusively. Which means when a scene needs a higher bitrate it gets it. I’ve seen parts of an encode reach 4x times the average bitrate for the entire video.

              Would you be willing to share a 30 second clip of the first rain scene you took screenshots of? I’d like to test varies settings with it. I use SolveigMM AVI Trimmer+, which is free, to create test clips to find the best encoding settings.

              I bet if you made the following changes to my suggested settings, it’d make a significant improvement.

              –no-early-skip –rect –amp –aqmode 1

              early-skip is good for video with little or no motion, raining scenes will be killed by early-skip. Also aqmode 2 & 3 both take bits from high motion scenes and give them to the static parts of the video. This helps to conserve bits. aqmode 3 will spend more bits in dark scenes compared to 2 and 1.

            • I found the anime, no need for the test clip. :)

              Also, don’t take the term extreme negatively. I use that because they are between the veryslow and placebo presets which takes forever to run, that’s all.

              Your settings will get as much detail as possible per bit. Compared to mine which trades speed for size when used with CRF.

              I’ll do some testing and post back my results.

              • Good morning brumsky,

                I’ve never used it, but you should of course get a more assured quality level with --crf, I mean, that’s what it’s for. Of course, when comparing CRF encodes with ABR ones like mine, we would also need to compare total file size to see how much more/less bitrate was invested by --crf. My 2.5Mbit encode (with your settings) does sometimes peak at >4Mbit, but of course there are lots of scenes that get <1Mbit as well. Here's my final H.265 stream sizes for the three target bitrates, they should be fairly deterministic due to the 2-pass mode:

                • 1000kbit: 338 806 kiB
                • 2500kbit: 841 763 kiB
                • 5000kbit: 1 680 433 kiB

                Also, I have had my doubts about --aq-mode 3 in x265 (I’ve used --aq-mode 1 for x264).

                Now that I checked, I noticed it does invest quite a lot of bits into dark areas/scenes. Maybe I should go back to --aq-mode 1? It is said, that the human eye can see much more detail in static scenes, but then again, what do I have B-frames for?! To better compress and preserve static scenes by referencing older (and newer) frames, right? It seems I can see much more quality deterioration in the fast moving scenes here. Just like I can see compression artifacts in reds much faster than in blues/greens, despite our eyes being supposed to be tuned to greens (mine especially, my “genetic” origin is from people who have lived in pretty lush areas for a long time). Still, the reds are being punished to much, it’s not treated equally for my perception.

                The same is true with motion, at least for my eyes: Even at 1MBit most static scenes look at least somewhat ok. But the rain or other moving parts are just terrible. You think that could be because of --aq-mode 3? Shifting a few bits back to motion scenes seems like a good idea to me…

                Edit: Looking forward to your results by the way!

  19. ~ wow! it clearly was a very nice analysis, Thrawn!!
    it surely helped me to understand better the real evolution of this encoder in comparison to its antecessor, and since that the test wasn’t made by the dev team itself, it surely gives more proper credibility to confirm/benchmark the ascendance in “quality X processing time X processing power” in a reasonable environment.

    Thank you, dude. ;D

    • Good morning DannyhelMont’,

      You’re welcome! This test has its limits though, I haven’t really tried any live action contents yet, and I haven’t tried to test several different combinations of encoder settings. It might be that you can achieve almost the same level of quality while still turning down some knobs on x265 like --bframes 16 to --bframes 8. Also, it would’ve been more fair to set x264 to 16 B-Frames as well, because it also suffers a lot performance-wise when you do that.

      So it ain’t perfect. ;) By now, I have changed my x264 encoders’ settings for animated content to also use --bframes 16, because I can afford it. Overall, x264 is still my main encoder. For content that is really precious to me, I’ll go for x265 to maintain even more quality without sacrificing disk space. Unless I have more powerful hardware, I’m probably not going to switch over to x265 for all content.

      Intels’ Broadwell Core i7-6950X looks kinda sexy in that regard, but it’s just too freaking expensive. ;)

      • ya, I agree.
        btw, I’m reading some of your other posts, and it surely caught me off guard these Anime Figures ones…( ͡° ͜ʖ ͡°)

        anyway, “Keep it Up!”. ;)

        • Hey,

          Yeah, um, well… There are a few of those around here… :roll: After I started to watch Anime again in beginning of 2015, it kinda went downhill real fast, and it’s starting to ruin me and my reputation. ;) I’ll just let this guy speak for me:

          Casual Fan

          An old friend once accused me of “not being able to do anything I do normally.“. I guess he meant “with moderation”. Well, whatever. :roll:

          Ah, also; My apologies. If you kept reading stuff here (or posting comments), I’m sure you’ve noticed that this blog sometimes reacts painfully slowly. This happens if you interact with it in any other way than reading stuff, or if you hit a page that’s not pre-cached as static HTML on my server.

          The reason as to why it’s so slow is because I’m running modern web software like this blog on [Pentium Pro hardware] from 1995. I tried my best to make it perform, but there is only so much I can do (kinda went with the wrong software for this, meh…). Just so you know why it sucks so hard sometimes. ;)

  20. Interesting test !

    But why do you have used –bframes 16 and not the default –bframes 8 of the preset veryslow ? –bframes 16 use much more ressource, you should have gained some time in encoding speed with a lower value isn’t it ?

    • Hi Particular,

      My sticking with --bframes 16 has been questioned on the Doom9 forums as well, see [here]. Quoting the user [MeteorRain]:

      “[…] One of my friends actually suggested me to not go too high on b-frames, I’d say 6 or 8 is good enough, unless you’re willing to put more time for little profit. […]”

      To be honest, I’m not sure if it does much good, if anything at all. I simply thought that with static backgrounds that can sometimes stay in place for a very long time (or pan very slowly), more B-Frames would always be a good thing, so we have more bitrate to spend on I-Frames or whatever.

      My logic could easily be flawed though, as I’m not really a true expert with this, I’m just reading the documentation, then some posts on the Internets and turning up knobs until I can no longer bear the slowness of x265. ;)

      I’ve never done any actual --bframes 16 vs. --bframes 8 quality comparisons, neither for x265, nor x264…

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">