x265 HEVC Encoder

[LigH]

Weekly build, "merge with stable".

x265 1.7+433-60f30d2ead26 (GCC 4.9.2) (https://www.mediafire.com/download/1t9y8h21jqnodh9/x265_1.7+433-60f30d2ead26.GCC492.7z)
x265 1.7+433-60f30d2ead26 (GCC 5.2.0) (https://www.mediafire.com/download/9pm3dzp2z1bnz79/x265_1.7+433-60f30d2ead26.GCC520.7z)

[jhughy2010]

I'm wondering if someone could post their "optimal" settings for Handbrake? When I check the "use advanced tab" under x265 there is no advanced tab that appears.

I'm re-encoding some BD rips and want the best quality with decent file size. I want two audio tracks... one stereo and another 5.1

With that said, what would you do?

[LigH]

This is a thread about the x265 backend (encoder), not about the Handbrake frontend (GUI). Don't blame x265 for Handbrake not providing advanced options (except for being still in an often changing development state, so that the Handbrake developers may not yet feel like supporting too many advanced options, because they may change "tomorrow").

The x265 encoder is not yet in a development phase where options get tuned for the convenience of the user. Options recommendable today may not be valid anymore next month, or next year, who knows... There are already presets for different relations of encoding speed vs. encoding thoroughness, but their details may still change; and the tunings are not yet as balanced as for x264, either.

In general, I would not yet recommend to use x265 for archiving copies of whole movies. It will take several times the encoding time of x264, anyway. But if you insist ... you may use the constant quality mode like you would for x264, just the CRF values will be a bit different, you may have to discover your optimum by encoding several movies several times (which may take days, if not weeks, at the current speed of x265). In case you need to fill a medium with a tightly limited capacity, you can use 2-pass encoding as well. The recommendable container to multiplex HEVC with AC3 audio tracks is MP4, alternatively maybe MKV or M2TS.

Also take into account that not many consumer devices already support the playback of HEVC video; apart from PCs, mainly TV sets which are already prepared for UHD broadcasts.

Again: For practical use, I'd prefer x264; I would not recommend x265 for home users yet to encode a copy of a whole movie.

[jhughy2010]

This is a thread about the x265 backend (encoder), not about the Handbrake frontend (GUI).

Ok I didn't realize there was a difference. I'm new to encoding and have been using Handbrake for only a few months.

In general, I would not yet recommend to use x265 for archiving copies of whole movies. It will take several times the encoding time of x264, anyway. But if you insist ... you may use the constant quality mode like you would for x264, just the CRF values will be a bit different, you may have to discover your optimum by encoding several movies several times (which may take days, if not weeks, at the current speed of x265). In case you need to fill a medium with a tightly limited capacity, you can use 2-pass encoding as well. The recommendable container to multiplex HEVC with AC3 audio tracks is MP4, alternatively maybe MKV or M2TS.

Ok perfect that is what I will try (and what I recently experimented with). Seems a constant quality of 18 is pretty comparable to a 20 with x264. Although dark scenes with x265 seem really blocky (I don't know how else to describe it).

Also take into account that not many consumer devices already support the playback of HEVC video; apart from PCs, mainly TV sets which are already prepared for UHD broadcasts.

I mostly watch on HTPC. I have noticed that an x265 movie didn't play well on my Samsung S5. It was a bit choppy.

[NikosD]

An interesting comparison of HW encoders (HEVC, H.264) vs SW encoders (x265, x264) in terms of performance and quality using QSVEncC v2.11

It looks like that on Skylake both QSV H.264 modes - PG and FF - have the same speed and QSV HEVC encoding has half speed of QSV H.264.

Compared to SW encoders, QSV HEVC is 2x faster than x264 and 12x (!) faster than x265.

Quality pictures and performance numbers here:
http://rigaya34589.blog135.fc2.com/blog-entry-673.html

[LigH]

Well, hardware accelerated AVC and HEVC encoding may be fast ... but not very efficient. You better have plenty of bitrate or you will clearly see the disadvantages compared to elaborate software encoders.

[Atak_Snajpera]

Anime? Show me results with some killer samples like parkjoy , crowdrun and so on and then we will talk about encoding speed and image quality.

[aegisofrime]

Well, hardware accelerated AVC and HEVC encoding may be fast ... but not very efficient. You better have plenty of bitrate or you will clearly see the disadvantages compared to elaborate software encoders.

This is just a guess but probably a hybrid approach might be doable? Offload some stuff to the fixed function hardware on Skylake (I think they have fixed function motion estimation stuff) and do the rest in software. Since they are sitting on the same die there won't be much latency like with moving stuff between CPU and GPU in GPU encoding.

[LigH]

The result, if this is possible at all, may not be "x265" anymore; but even if it is possible, I don't think it would speed up the process remarkably, because there is an overhead in exchanging data between CPU and GPU, and the CPU would still do the most complex parts of the algorithm (searching for optimal matches across several reference frames), gaining only little from what the GPU could take off, I believe...

[sneaker_ger]

The biggest question is if Intel gives you access to specific parts of its encoding functions (like e.g. motion estimation) or if it's just a black box taking in raw frames and spewing out AVC/HEVC from a programmers point of view. In the worst case you'd have to let it do a full encoding and then extract e.g. motion vectors from the final bitstream. At the end of the day speed or quality might not be up to par.

[foxyshadis]

I could see a use for Quicksync as a superspeed first pass, which can be analyzed to derive a stats file, but I can't think of any other way you could effectively use it as part of x265. The actual encoding is most of what makes it x265.

[x265_Project]

I could see a use for Quicksync as a superspeed first pass, which can be analyzed to derive a stats file, but I can't think of any other way you could effectively use it as part of x265. The actual encoding is most of what makes it x265.
We think about how to accelerate x265 constantly. But as LiGH and Foxyshadis noted, we don't want x265 to simply call someone else's encoder, or part of another encoder. Where there are fixed function capabilities in new hardware HEVC encode pipelines that we can leverage, we will.

We don't feel like we compete with proprietary encoder APIs. While we don't disagree that it makes sense for semiconductor companies to offer their own proprietary encoder APIs, customers worldwide vastly prefer the quality, features, flexibility and cross platform capability of open source encoder libraries like x264 and x265. It makes sense for semiconductor companies to give us access to the full power of their new architectures. Unfortunately, these hardware pipelines aren't designed as a set of addressable fixed function units that we can quickly and efficiently access. But we're investigating all of the possibilities.

[LigH]

Another "merge with stable", including several bug fixes and some even faster AVX2 routines.

x265 1.7+470-86e9bd7dd192 (GCC 4.9.2) (https://www.mediafire.com/download/vx21tk5hqla3h22/x265_1.7+470-86e9bd7dd192.GCC492.7z)
x265 1.7+470-86e9bd7dd192 (GCC 5.2.0) (https://www.mediafire.com/download/1dwbk5t22kac176/x265_1.7+470-86e9bd7dd192.GCC520.7z)

[divxmaster]

Interesting results here from 1.7+470 (vs 1.7.382), one 1000 frame test was 9.5% faster and 3% smaller file (lots of panning)
another 1000 frame sample was 5.6% SLOWER than .382, and the same size (.16% smaller) (no panning).

4770K@3.9, 480p sample. Tests run multiple times.

Edit: On a 10000 frame test, 470 was 3.5% slower and a 1% BIGGER file. Will test entire encode now.

CHeers,
Divxmaster

[jhughy2010]

I've been experimenting with Handbrake and x265 re-encoding. I find that the quality (for my purposes) is as good if not better (for same file size if not smaller) as x264. Obviously it takes much longer to re-encode, however, I have noticed the resulting file size is much more appealing than an x264 re-encode.

What exactly is the "x265 HEVC Upgrade"? I noticed it costs $29.95, is this an application like Handbrake or is it an extension of some other piece of software?

Is Handbrake a good tool to use to re-encode to x265? I am taking full MKV files to MP4 and using default x265 settings in Handbrake ATM.

[LigH]

What exactly is the "x265 HEVC Upgrade"? I noticed it costs $29.95, is this an application like Handbrake or is it an extension of some other piece of software?

This is mainly UHDcode, a quite fast and comprehensive HEVC decoder as DirectShow filter, along with a basic recoder for AVC-in-MP4 source files. Not really necessary for most cases, LAV Filters have a good decoder implementation as well, and there are free converters in all different flavours.

[x265_Project]

I've been experimenting with Handbrake and x265 re-encoding. I find that the quality (for my purposes) is as good if not better (for same file size if not smaller) as x264. Obviously it takes much longer to re-encode, however, I have noticed the resulting file size is much more appealing than an x264 re-encode.

What exactly is the "x265 HEVC Upgrade"? I noticed it costs $29.95, is this an application like Handbrake or is it an extension of some other piece of software?

Is Handbrake a good tool to use to re-encode to x265? I am taking full MKV files to MP4 and using default x265 settings in Handbrake ATM.
The x265 HEVC Upgrade includes 2 things; the x265 Encoder (Windows application), and UHDcode (Windows DirectShow filter).

The x265 Encoder is a simple Windows 64 bit application designed to make it easy for anyone to use x265. It accepts MP4 files as input, and it will transcode the H.264 video to H.265, passing the audio through to the target MP4 file. There is a basic mode which makes it really easy for non-technical people to use. The advanced mode includes full access to all x265 settings.

The UHDcode DirectShow filter allows Windows Media Player to play video files containing HEVC.

The x265 HEVC Upgrade is available for $14.98 (50% off the MSRP) for a limited time. We hope to be able to make trial versions available, but we're still waiting to hear if the HEVC Advance patent portfolio will allow for trial software without charging an exorbitant royalty (MPEG-LA allows for trial software with no royalty).

[divxmaster]

Interesting results here from 1.7+470 (vs 1.7.382), one 1000 frame test was 9.5% faster and 3% smaller file (lots of panning)
another 1000 frame sample was 5.6% SLOWER than .382, and the same size (.16% smaller) (no panning).

4770K@3.9, 480p sample. Tests run multiple times.

Edit: On a 10000 frame test, 470 was 3.5% slower and a 1% BIGGER file. Will test entire encode now.

CHeers,
Divxmaster

Trend continued, an entire encode was 13.49fps for 382 and 13.35fps for 470. The 470 file was a little bigger. Seems somewhat odd, but just an observation.

Cheers,
Divxmaster

[downloadhub]

any buddy help me which method to encode x265 HEVC small size mobile rip i am try many of encoders but i am not manage it size if any buddy know please help me which encoder i am use for good quality with small size minimum 200MB

[jhughy2010]

The x265 HEVC Upgrade includes 2 things; the x265 Encoder (Windows application), and UHDcode (Windows DirectShow filter).

The x265 Encoder is a simple Windows 64 bit application designed to make it easy for anyone to use x265. It accepts MP4 files as input, and it will transcode the H.264 video to H.265, passing the audio through to the target MP4 file. There is a basic mode which makes it really easy for non-technical people to use. The advanced mode includes full access to all x265 settings.

The UHDcode DirectShow filter allows Windows Media Player to play video files containing HEVC.

The x265 HEVC Upgrade is available for $14.98 (50% off the MSRP) for a limited time. We hope to be able to make trial versions available, but we're still waiting to hear if the HEVC Advance patent portfolio will allow for trial software without charging an exorbitant royalty (MPEG-LA allows for trial software with no royalty).

Ok thanks. You mentioned transcoding. So the windows application does on the fly transcoding but does it re-encode like Handbrake? Does it accept MKV files?

How does the application compare to Handbrake? If it is as functional and/or better I would be will to pay (heck I'd pay for Handbrake if it wasn't free).

[LigH]

@ downloadhub:

1. "anybody"

2. There are no miracles. And there are no crystal balls. Good quality requires a minimum bitrate per image area. If you need a small size, reduce the resolution. Use a 2-pass encoding method to bring your copy down to a desired target size. And stay with H.264 (AVC) for mobile devices, because H.265 (HEVC) requires much more computing power and will drain your battery faster. For better help, post more details; but not in this thread, this is about the development of x265, not a beginners' guide how to use any converter.
__

@ jhughy2010:

I did not use it yet, but according to the description: MP4 to MP4 only. And probably no filters, just straight video conversion with audio pass-through, certainly not as flexible as Handbrake or StaxRip or MeGUI or Hybrid.

[Jamaika]

any buddy help me which method to encode x265 HEVC small size mobile rip i am try many of encoders but i am not manage it size if any buddy know please help me which encoder i am use for good quality with small size minimum 200MB
I think you can use Cyberlink Powerdiector 13. Editor AVC decoder is poor, but when you use Cineform codec you can get an interesting result HEVC output.
HEVC FullHD 4500kbps i420 8bit 30fps progressive High Quality

[LigH]

NUMA, NUMA, yeah: x265 1.7+474-e1adac00dce8 (GCC 4.9.2 (https://www.mediafire.com/download/0pl8r4cg0glv3tz/x265_1.7+474-e1adac00dce8.GCC492.7z) / 5.2.0 (https://www.mediafire.com/download/ntmn27dm6d5qm7d/x265_1.7+474-e1adac00dce8.GCC520.7z)) (multilib EXE's only) with a changed NUMA pool strategy

[x265.cc]

NUMA, NUMA, yeah: x265 1.7+474-e1adac00dce8 (GCC 4.9.2 (https://www.mediafire.com/download/0pl8r4cg0glv3tz/x265_1.7+474-e1adac00dce8.GCC492.7z) / 5.2.0 (https://www.mediafire.com/download/ntmn27dm6d5qm7d/x265_1.7+474-e1adac00dce8.GCC520.7z)) (multilib EXE's only) with a changed NUMA pool strategy

revision is bugged and just utilize one cpu core (on my hardware). Better stick with rev x265_1.7+470 (until tomorrow)

[benwaggoner]

revision is bugged and just utilize one cpu core (on my hardware). Better stick with rev x265_1.7+470 (until tomorrow)



I get the same thing on my 16-core dual Xeon. Manually trying to force multithreading via --pools didn't work either.



Semi-relatedly, what's the current thinking on gcc 4.9 v. 5.2 builds?

[Ma]

Semi-relatedly, what's the current thinking on gcc 4.9 v. 5.2 builds?

I think that code generated by GCC 5.2 is faster but bigger. Size of code does matter because L1 cache is very small (32 KB) and there are huge speed differences between L1/L2/L3 cache/memory access.

For GCC 4.9 there is a problem that MS gives VS 2015 for free and code generated by VS 2015 is smaller than code generated by GCC 4.9.

GCC 4.9 build will be probably slower than the fastest build from GCC 5.2 & VS 2015.

[burfadel]

The question then of course, is how the VS 2015 speed compares to the GCC 5.2 speed.

[Ma]

The question then of course, is how the VS 2015 speed compares to the GCC 5.2 speed.

At AVX level (i5 3450S) there was: VS 2015 builds was faster in 8 and 10-bit encoding, much slower in 12-bit encoding.

After x265 team turn off AVX assembly code that was 10% faster than SSE4, VS 2015 builds are at the same speed in 8 & 10-bit encoding, much slower in 12-bit encoding.

I try to make tables for tomorrow @ AVX level and SSSE3 level.

[benwaggoner]

I get the same thing on my 16-core dual Xeon. Manually trying to force multithreading via --pools didn't work either.
Looks like a fix should be coming today:

https://bitbucket.org/multicoreware/x265/commits/e1adac00dce8e5641cbe9aec3d50a72261c308d9#general-comments:
Pradeep Ramachandran author
Thanks. I see the error in my logic. I'll push in a fix tomorrow.

[Ma]

Speed test VS 2015 build vs. GCC 5.2.

Platform: Win7 64-bit, i5 3450S
Options: --crf 17.5 --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288 --colormatrix bt709
Builds: 1.7+473 from site www.msystem.waw.pl/x265

Encoding time in seconds (first table 8-bit, second 10-bit, third 12-bit):

fast medium slow slower verysl placebo
vs2015-AVX 69,69 108,21 274,78 368,5 393,92 400,4
msvcr120-AVX 70,3 108,24 274,73 371,23 396,06 403,91
gcc52-AVX 70,14 108,41 274,7 374,19 396,14 405,53
msvcr120-SSSE3 70,71 109,39 298,93 374,42 398,36 407,44
vs2015-SSE2 70,66 110,11 277,19 375,48 399,6 404,15

vs2015-AVX 87,89 132,82 413.04 515.14 552.64 574.87
msvcr120-AVX 88,83 133,81 413.77 518.28 555.17 580.92
gcc52-AVX 89,33 134,45 415.41 519.76 556.77 582.68
msvcr120-SSSE3 89,34 135,18 416.71 521.65 557.83 581.81
vs2015-SSE2 88,89 134,67 413.64 517.96 555.26 576.48

msvcr120-AVX 109,19 168,07 455,76 574,88
gcc52-AVX 109,69 168,56 457,26 576,78
msvcr120-SSSE3 111,96 172,47 461,8 585,26
vs2015-AVX 166,03 250,06 714,95
vs2015-SSE2 167,82 253,73 719,64


Unfortunately I took to many binaries to compare and too long samples and didn't finish. There was only 1 repeat and my Win7 in the night like to do something which affect results. Anyway vs2015-AVX build is the fastest @ 8-bit & 10-bit.

On CPU with only SSSE3 result was (encoding time in seconds, first table 8-bit, second 10-bit):

msvcr120-SSSE3 487,42 716,34 991,49 1068,54 1055,51 985,84
gcc52-SSSE3 490,43 729,44 991,58 1055,89 1057,93 983,03
gcc52-SSE2 498,47 768,78 1003,16 1053,75 1194,48 1010,54
vs2015-SSE2 608,29 873,99 1181,09 1267,78 1255,51 1153,93

msvcr120-SSSE3 618,49 899,64
gcc52-SSSE3 620,4 895,69
gcc52-SSE2 647 915,41
vs2015-SSE2 707,55 1004,47


On weak CPU vs2015 build is slow.

[NikosD]

Any test with Intel C Compiler ?

[Ma]

Any test with Intel C Compiler ?

On my i5 3450S ICC builds were very slow (months ago). Maybe it is time to make new test...

[burfadel]

Wow, VS2015 fastest with AVX, but slowest without it!

[NikosD]

On my i5 3450S ICC builds were very slow (months ago). Maybe it is time to make new test...
That would be very useful to have the 3 most common and most intelligent compilers compared to each other.

My very restricted experience with recompilations favored Intel using ICC, but I think that all three are very close (even looking your results) and is up to the specific code to have a winner.

[foxyshadis]

So much is done by yasm now that it hardly matters what compiler you use, 1% isn't so bad. I wonder what's wrong with VS2015 12-bit, though? Nearly twice as slow as the other compilers, something must not be building correctly. (Kind of amazing that they've otherwise so quickly made it to parity with 10-bit though.)

[Ma]

So much is done by yasm now that it hardly matters what compiler you use, 1% isn't so bad.

Yes, for AVX & AVX2 CPU @ 8/10-bit most important functions are in asm.

I wonder what's wrong with VS2015 12-bit, though? Nearly twice as slow as the other compilers, something must not be building correctly. (Kind of amazing that they've otherwise so quickly made it to parity with 10-bit though.)

x265 team turn off asm functions that doesn't work @ 12-bit so it is half asm half C++ solution. VS 2015 doesn't vectorize loops (for that is ICC) so it loses heavily to GCC. Maybe in the future x265 team write missing asm functions and VS 2015 builds will be fast @ 12-bit.

For 10-bit there was some action from Win7 that slow down encoding -- the results are just not right.

[Ma]

I downloaded ICC build from site http://x265.ru/en/builds/ and compared speed with VS 2015 AVX build 1.7+478 (only preset slower, 10-bit). ICC build encoding time is 105% of VS 2015 AVX build. I attached used *.bat and result file.

[LigH]

A tolerance of 5% is still marginal to me. So in general, the sources are quite portable, and the results quite reliable. Great business at MCW. :thanks:

[NikosD]

I downloaded ICC build from site http://x265.ru/en/builds/ and compared speed with VS 2015 AVX build 1.7+478 (only preset slower, 10-bit). ICC build encoding time is 105% of VS 2015 AVX build. I attached used *.bat and result file.

Thanks!

But you tested only one preset for only one encoding (10bit) and you compared that to the faster compiler of that particular test.

Looking at the first table of 10bit encodings, it seems that VS2015-SSE2 is extremely fast, sometimes faster than VS2015-AVX (!) like "slow" and "very slow" and particularly for "slow" preset is even faster almost than any other compiler at that particular test.

Are you sure ?

[Ma]

But you tested only one preset for only one encoding (10bit) and you compared that to the faster compiler of that particular test.

Yes, I was curious if the ICC build suits my favorite preset @ 10-bit -- the answer is not. For me (i5 3450S, 10-bit encoding) the best build is VS 2015 AVX. For other CPU the fastest build could be different, for example my second computer has only SSSE3 CPU and this build doesn't work at all, the fastest is GCC 5.2 SSSE3.

Looking at the first table of 10bit encodings, it seems that VS2015-SSE2 is extremely fast, sometimes faster than VS2015-AVX (!) like "slow" and "very slow" and particularly for "slow" preset is even faster almost than any other compiler at that particular test.

Are you sure ?

Numbers are copied from result file (enclosed), but my Win7 likes after long user inactivity defragment HDD or index files which highly affects the result. I will repeat this test for 10-bit and preset from slow to placebo and I will correct the table (tomorrow).

[burfadel]

Yes, I was curious if the ICC build suits my favorite preset @ 10-bit -- the answer is not. For me (i5 3450S, 10-bit encoding) the best build is VS 2015 AVX. For other CPU the fastest build could be different, for example my second computer has only SSSE3 CPU and this build doesn't work at all, the fastest is GCC 5.2 SSSE3.

Numbers are copied from result file (enclosed), but my Win7 likes after long user inactivity defragment HDD or index files which highly affects the result. I will repeat this test for 10-bit and preset from slow to placebo and I will correct the table (tomorrow).

Just had a quick look at the results. Using 12-bit, VS2015, and b-frames is broken!

For example, non-VS2015 12-bit results show under slow preset:

x265 [info]: frame P: 185, Avg QP:20.38 kb/s: 27554.99
x265 [info]: frame B: 562, Avg QP:25.83 kb/s: 3833.29

and VS2015 12-bit slow preset results in:
x265 [info]: frame P: 185, Avg QP:20.30 kb/s: 35750.58
x265 [info]: frame B: 562, Avg QP:25.76 kb/s: 12286.57

P frames also are much bigger in the VS2015 builds. The I-frames are pretty much the same size (although they're supposed to be the same across the different compilers).

[Ma]

Just had a quick look at the results. Using 12-bit, VS2015, and b-frames is broken!

Thanks! After fast check with ver. 1.7+478, command + result line:
GCC 5.2 build

x265-gc -D12 720p50_parkrun_ter.y4m wgc.hevc
encoded 504 frames in 35.80s (14.08 fps), 3168.26 kb/s, Avg QP:38.01

x265-gc -D12 --no-asm 720p50_parkrun_ter.y4m wgc-no.hevc
encoded 504 frames in 71.30s (7.07 fps), 3170.11 kb/s, Avg QP:37.99


VS 2015 build

x265-vs -D12 720p50_parkrun_ter.y4m wvs.hevc
encoded 504 frames in 52.23s (9.65 fps), 7189.06 kb/s, Avg QP:38.48

x265-vs -D12 --no-asm 720p50_parkrun_ter.y4m wvs-no.hevc
encoded 504 frames in 141.68s (3.56 fps), 14806.31 kb/s, Avg QP:38.96


So there is something wrong with 12-bit, asm output differs from no-asm, VS 2015 differs from GCC 5.2.

[x265_Project]

We're attending IBC this week. I'm here with Deepthi, manager of the x265 development team. If you are interested in meeting with us, please email me... tom.vaughan at multicorewareinc.com.

Tom

[lagittaja]

I've been evaluating x265 using HB 10.2 for a few days now.
Seriously impressed with what x265 can achieve! Thank you to all the devs working on this!

I won't be switching over from x264 just yet but I'm eager to go ahead and archive some of my Game of Thrones bluray's using x265.

Which is what I've been testing using x265. x265 on Main using medium preset, even RF20 looks impressively good either in static scenes and sword fighting scenes while achieving 70-90% compression. :eek:

So, getting to my point.
I figure that 10.2 uses version 1.5 built on GCC 4.9?
The latest version appears to be 1.7.
I guess what I'm trying to ask here is should I wait for a newer release of HB using newer version of x265?
Generally speaking, going from 1.5 what HB uses to 1.7, are there really noticeable gains in any aspect? Speed or quality or compression?

I'm encoding on OC'd Ivy Bridge i7 which doesn't have AVX2, in case that information matters.

[Jamaika]

I've been evaluating x265 using HB 10.2 for a few days now.
What is HB 10.2?
Which is what I've been testing using x265. x265 on Main using medium preset, even RF20 looks impressively good either in static scenes and sword fighting scenes while achieving 70-90% compression.
Examples please. Best not on a dark background. For me codec X265 is still a beta version.

[lagittaja]

What is HB 10.2?

Examples please. Best not on a dark background. For me codec X265 is still a beta version.

Handbrake.

I've been using three samples which I splitted of using MKVToolnix (keeping only video) from the original extracted from my Blurays using MakeMKV.
The GoT intro (probably on YT, haven't checked)
S01E02 00:37:00-00:39:30 ("static scene", decent amount of detail and crisp hair and so on.)
S01E05 00:51:00-00:53:00 (Eddard vs Jaime sword fight, can be found on YT).

I could put the original samples I use in my Dropbox but in total they're a little under a gigabyte so may take sometime for you to download depending on your connection.
And I don't know exactly what's considered a sample and this is copyrighted content after all so..

E: And I hope you didn't get my "even RF20 looks impressively good" as a "oh dear lord, RF20 looks so good it's almost transparent" statement. If I do end up archiving some of my GoT bluray's with Handbrake 0.10.2 using it's current x265 version along with the medium preset, RF setting I'd use would be either 17 or 18.
The file size using RF16 got real close to what my x264 encode at RF20 and custom settings got to while encoding speed wasn't all that different.

[Bigmango]

I figure that 10.2 uses version 1.5 built on GCC 4.9?
The latest version appears to be 1.7.


That's the problem with handbrake and why I use Ripbot.

Ripbot is updated regularly with more recent versions of x265 and you can always replace the x265.exe with a newer one in the Ripbot tools directory.

[luigizaninoni]

HB nightlies use x265 1.7. They are very stable

[Bigmango]

HB nightlies use x265 1.7. They are very stable
Good to hear, thanks for the feedback.

[lagittaja]

That's the problem with handbrake and why I use Ripbot.

Ripbot is updated regularly with more recent versions of x265 and you can always replace the x265.exe with a newer one in the Ripbot tools directory.

Thanks for the suggestion. I'll have a look at it tomorrow. But I'm not gonna lie to you, I've grown quite fond of Handbrake.

HB nightlies use x265 1.7. They are very stable

Oh, nice. Thank you sir! Almost had completely forgotten the nightlies, looks they have resumed them couple weeks ago.