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.

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

  1. 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!

  2. 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.

  3. 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. ;)

  4. 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).

  5. 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…

  6. 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!

  7. 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. :)

  8. 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…

  9. 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. ^^

  10. 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!

  11. ~ 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. ;)

  12. 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="">