x265 HEVC Encoder

[davidsama]

2.1+55-67e980e is out now. Try that and see if it is any faster for you.

[CruNcher]

Wait...Pascal only 220fps for 1080p hevc encoding? Sound like CPU decoding bottleneck. Did you use hardware accelerated decoding? It is located at Basic-->Decoder-->nvencc (Native).

*Did you know one can use high quality resizer through --vpp-resize option? (assuming if you resize the video) Need to extract NPP stuff to nvencc location for cubic_bspline, cubic_catmull, cubic_b05c03, super, lanczos, bilinear, spline36 usage.

*Nvenc only make use of single reference frame for hevc encoding. It doesn't matter how many ref you specified.

*There is slight quality issue with CQP mode. It is hard to explain, so... nah, most people won't notice it anyway. Lazy to explain.

Hmm sounds indeed a little slow for Pascal HEVC depending on the bitrate and fps he talks about the 220 fps standing for :)

GM204 1080p PAL 25 FPS target 4 MBits

encoded 51445 frames, 137.58 fps, 3973.15 kbps, 974.65 MB
encode time 0:06:13 / CPU Usage: 5.48%

frame type IDR 206
frame type I 206, avgQP 24.41, total size 15.43 MB
frame type P 51239, avgQP 26.87, total size 959.22 MB

[Jawed]

Can we keep other encoders off this thread?

[Barough]

x265 v2.1+55-67e980e22c43 (http://www21.zippyshare.com/v/QAiqyE4J/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[pradeeprama]

just about CPU... i7-3930K (6-core with HT) is about 15% slower in encoding with x265 2.1+47 to HEVC 10bit 3840x1600 than i5-6600 (4-cores, no HT).

This is a very interesting comparison. The i7-3930K has 12 threads overall while the i5-6600 has only 4 threads. (Full spec comparison at http://ark.intel.com/compare/88188,63697.) Despite this, the fact that the i5-6600 achieves 15% over i7-3930K is rather impressive! The reason is because of improved single-thread performance because of AVX2 code in x265, by better pre-fetching to reduce latency, and better memory bandwidth response in the 6th gen cpu.

My bet is that with the Skylake generation (6th gen), the # HW threads where memory limits x265's performance will be much more than the # HW threads where memory limits in the Sandybridge generation (3rd gen) as x265 really benefits from all the improvements in memory bandwidth that Skylake has to offer.

[jlpsvk]

Hehe... will do the comparison with i7-6700K as soon as it will come from warranty claim.. :)

[filler56789]

x265 v. 2.1+59 is out.

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2467483#post2467483

[x265_Project]

Some progress on the HEVC patent licensing! This means that applications like VLC and Handbrake, as well as web browsers and mobile apps with HEVC software implementations are royalty free with respect to HEVC Advance.
HEVC Advance Software Policy (http://epdf.hevcadvance.com/pdf/embed?hash=84f7cae5df5424fcfbc82fb2d83fbca5)

HEVC Advance Presentation Explaining Software Policy (http://epdf.hevcadvance.com/pdf/embed?hash=d8d319a061a2c345707db25f6c9cefc5#7)

[sneaker_ger]

VLC and HandBrake also make use of HEVC hardware decoders/encoders.

[dipje]

But if I understand it correctly, they will seek licensing from (all kinds of) devices with HEVC onboard, as well as things like 'HEVC support built in operating systems'.

The text 'will not seek licensing on software products _after_ the initial safe of the device' means that if you want to buy a device with some kind of HEVC support (encoding or decoding) out of the box, licensing will need to be paid by the manufacturer / supplier of the device.. If HEVC is implemented in software or hardware doesn't matter there.

So Mac OS, Windows, Android, iOS with built in HEVC support (hardware or software) still needs a license by the device manufacturer.. right?

edit:
Just to make clear, it's great news of course! Not trying to be negative here :P.
Does this also mean that making official binaries is on the table or are there other techniques / patens / library-parts that may not be redistributed in binary form?

[x265_Project]

VLC and HandBrake also make use of HEVC hardware decoders/encoders. That's OK. They can only make use of a hardware encoder/decoder that has already been enabled (with the necessary driver) on the device. In that situation, the device manufacturer was already liable to pay the HEVC Advance royalty when they sold or later enabled the hardware encoder/decoder. Software that looks for hardware HEVC encoders/decoders, and uses them when they are present, isn't subject to a separate royalty.

[nevcairiel]

VLC and HandBrake also make use of HEVC hardware decoders/encoders.

The hardware maker would pay the licenses for that, then. Or so I would assume. They make the decoder afterall, software just accesses it.

[x265_Project]

But if I understand it correctly, they will seek licensing from (all kinds of) devices with HEVC onboard, as well as things like 'HEVC support built in operating systems'.

The text 'will not seek licensing on software products _after_ the initial safe of the device' means that if you want to buy a device with some kind of HEVC support (encoding or decoding) out of the box, licensing will need to be paid by the manufacturer / supplier of the device.. If HEVC is implemented in software or hardware doesn't matter there.

So Mac OS, Windows, Android, iOS with built in HEVC support (hardware or software) still needs a license by the device manufacturer.. right? Correct.

The point here is that HEVC Advance is looking for one royalty per device. Prior to this new policy, every software application that included an HEVC software implementation would have been liable for a separate "device royalty". This new policy allows software developers to add HEVC software encoder and decoder libraries to their apps, and distribute them without being liable to HEVC Advance for patent royalties. The caveats you see in the policy are designed to not allow device OEMs (HP, Dell, Apple, Samsung, etc.) to use the policy to avoid paying that one royalty on a device that they sell as being HEVC capable.

[Boulder]

x265 v. 2.1+59 is out.

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2467483#post2467483I did some tests and ran a clip through --limit-tu 0 to 4. To me it seems that the higher the value, the smaller blocks are used. Does this actually mean that I'm sacrificing bitrate but achieving better detail retention and faster encoding speed? I haven't done any frame by frame comparisons yet.

[dev84]

Hi

This is what i get:

https://s13.postimg.org/xsri3epk3/vlcsnap_2016_11_22_22h00m05s203.png (https://postimg.org/image/xsri3epk3/)

Here are the logs of input and output file and log from MeGui

http://www.filedropper.com/x265logs

And here is the encoded video

http://www.filedropper.com/c0005-muxed


Any idea why is this happening?

[sneaker_ger]

Plays fine here both using VLC and MPC-HC. Try latest versions of both and try software decoding.

If it still errors try ffplay. If that has error too report to ffmpeg bug tracker.

[dev84]

hmmm
have no idea i use VLC 2.2.4
i did system restore on the weekend something must be wrong with cfg, but im lost as to what :(

but this helps me a lot checking the video on other pc

thx

[WhatZit]

This new policy allows software developers to add HEVC software encoder and decoder libraries to their apps, and distribute them without being liable to HEVC Advance for patent royalties.

Currently, any AVC vs HEVC comparisons are the subject of specialised forums such as this one, which have limited visibility.

Taking the lead-time for commercial editing/encoding software development into account, this change means that we will FINALLY start seeing a plethora of "x264 vs x265" articles appearing in the mainstream.

This can only be a very good thing for the fostering of HEVC demand.

[nevcairiel]

This is just HEVC Advanced though, how is the MPEG-LA's stance on this?

[x265_Project]

This is just HEVC Advanced though, how is the MPEG-LA's stance on this?

At the moment, there is no change in their license program. I'm optimistic that the companies who have pooled their HEVC patents in MPEG LA's license program will recognize the wisdom of adopting this policy enabling most software implementations to be royalty free.

[burfadel]

I did a quick test with the revised -tu-limit settigs in 2.1+59. I had both inter and intra TU levels set at 4. No point using anything less since the whole point of this is to be able to make use of a higher inter TU without the performance penalty, right? So 4 makes sense, and likewise therefore 4 for intra as well.

What I found was --limit-tu 3 appeared the nicest to look at without any penalty of file size worth mentioning. I redid the tests with PSNR and SSIM stats enabled. Yes I know that with psy etc this isn't exactly a good way of testing, but --limit-tu 3 had better PSNR and SSIM, which matched what I saw visually. Do take into mind that I did the subjective visual test first without seeing the results.

[LigH]

x265 2.1+59-a895b6344a82 (https://www.mediafire.com/file/q63pahl3why2fm0/x265_2.1+59-a895b6344a82.7z)

CLI changes:
(new)
--scenecut-bias <0..100.0> Bias for scenecut detection. Default 5.00

(changed descr.)
--[no-]vui-timing-info Emit VUI timing information in the bistream. Default enabled
--[no-]vui-hrd-info Emit VUI HRD information in the bistream. Default enabled
--[no-]opt-qp-pps Dynamically optimize QP in PPS (instead of default 26) based on QPs in previous GOP. Default enabled
--[no-]opt-ref-list-length-pps Dynamically set L0 and L1 ref list length in PPS (instead of default 0) based on values in last GOP. Default enabled

[burfadel]

x265 2.1+59-a895b6344a82 (https://www.mediafire.com/file/q63pahl3why2fm0/x265_2.1+59-a895b6344a82.7z)

CLI changes:
(new)
--scenecut-bias <0..100.0> Bias for scenecut detection. Default 5.00

(changed descr.)
--[no-]vui-timing-info Emit VUI timing information in the bistream. Default enabled
--[no-]vui-hrd-info Emit VUI HRD information in the bistream. Default enabled
--[no-]opt-qp-pps Dynamically optimize QP in PPS (instead of default 26) based on QPs in previous GOP. Default enabled
--[no-]opt-ref-list-length-pps Dynamically set L0 and L1 ref list length in PPS (instead of default 0) based on values in last GOP. Default enabled

Plus there's --limit-TU 3 and 4, although command line help doesn't show it. The information is available with the full x265 documentation though: http://x265.readthedocs.io/en/default/cli.html#cmdoption--limit-tu

--limit-tu <0..4>

Enables early exit from TU depth recursion, for inter coded blocks.
Level 1 - decides to recurse to next higher depth based on cost comparison of full size TU and split TU.
Level 2 - based on first split subTU’s depth, limits recursion of other split subTUs.
Level 3 - based on the average depth of the co-located and the neighbor CUs’ TU depth, limits recursion of the current CU.
Level 4 - uses the depth of the neighbouring/ co-located CUs TU depth to limit the 1st subTU depth. The 1st subTU depth is taken as the limiting depth for the other subTUs.

Default: 0

Not quite a direct quote as I think it is easier to read like above instead of all being in one paragraph. I simply changed it so each level is represented as a new line.

As I said previously, I believe 'level 3' which I bolded above gives the most favourable results IMO.

[Gravitator]

Megablock very bad impact on the formation of each of the second frame (wood edge demonstrates). > test(p-b).mkv (http://files.videohelp.com/u/227452/test(p-b).mkv)

[Barough]

x265 v2.1+59-a895b6344a82 (http://www66.zippyshare.com/v/T5jgAbsH/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[pradeeprama]

I did some tests and ran a clip through --limit-tu 0 to 4. To me it seems that the higher the value, the smaller blocks are used. Does this actually mean that I'm sacrificing bitrate but achieving better detail retention and faster encoding speed? I haven't done any frame by frame comparisons yet.

Limit-tu isn't trying to favour smaller TUs over larger TUs at all. It is only trying to limit the depth of recursion that is used. In fact, I would think that you would see larger TUs with limit-tu enabled when compared to no limit-tu.

Can you share your command-lines so that we can comment?

[Boulder]

Limit-tu isn't trying to favour smaller TUs over larger TUs at all. It is only trying to limit the depth of recursion that is used. In fact, I would think that you would see larger TUs with limit-tu enabled when compared to no limit-tu.

Can you share your command-lines so that we can comment?Sure, here's the command line I used to test:

vspipe.exe --y4m "c:\x265\hotfuzz.vpy" - | C:\sources\x265\build\vc14-x86_64\Release\x265.exe --input - --y4m --input-depth 16
--dither --sar 1:1 --profile main10 --keyint 480 --ref 5 --rskip --colormatrix "bt709" --colorprim "bt709" --transfer "bt709"
--preset slower --rc-lookahead 60 --deblock -3:-1 --no-strong-intra-smoothing --limit-refs 3 --limit-modes --limit-tu 0
--tu-inter-depth 4 --tu-intra-depth 4 --merange 38 --tune grain --crf 21 --csv q:\hotfuzz_limittu0.csv --csv-log-level 2 --output "q:\hotfuzz_limittu0.hevc"

Here are the csv logfiles from my five encodes at different values for --limit-tu : https://drive.google.com/open?id=0BzeF_1syecQwRHJLdVNfRDdNbWM

In my tests, the bitrate and encoding speed was as follows:

--limit-tu 0 : 4875.60 kbps, 1.64 fps
--limit-tu 1 : 4899.45 kbps, 1.84 fps
--limit-tu 2 : 4990.49 kbps, 1.93 fps
--limit-tu 3 : 5037.98 kbps, 1.99 fps
--limit-tu 4 : 5044.37 kbps, 2.02 fps

The black mattes were cropped and the result downsized to 1280x544. The original source clip is here: https://drive.google.com/open?id=0BzeF_1syecQwakhsX3RuZGhWcjA

[burfadel]

Which did you find looked better?

[Boulder]

Which did you find looked better?

It's really hard to tell. I could even say that there is no clear winner there, especially if you don't use still frames to compare.

[K.i.N.G]

Hi anyone know if it is possible to use the x265 encoder on android devices?

I've got a Nvidia Shield (Tegra X1 cpu) which encodes x264 pretty well (via the plex app).
So since x264 works on it, I 'assume' x265 is possible aswell?

I googled it a few times and searched in the play store but I can't find any apps/tools available (yet)..

[sneaker_ger]

I assume Plex is using Nvidia's H.264/AVC encoder, not x264. Running x264 or x265 would be slow on the Shield's CPU. Likewise, you'd need an app that uses Nvidia's H.265/HEVC encoder for fast H.265/HEVC encoding. Maybe you can ask Plex developers if they are willing to add this functionality.

[LigH]

If you can compile x26* for this target OS and CPU architecture, you can probably also use the encoder on it; but I would not recommend using mobile devices for such time and energy consuming tasks. Such CPUs may preferably save energy, instead of executing highly efficient SIMD instructions. And x265 requires a magnitude more processing power than x264, and highly efficient instruction extensions (especially vector math extensions like AVX) help x265 a lot more. Tegra X1 is highly parallelized, but will probably have a lower complexity in available instructions. And x265 does not require maximum parallelizability, instead rather wide and purpose-relevant SIMD and vector instructions.

[filler56789]

x265 v. 2.1+60

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2467866&viewfull=1#post2467866

[K.i.N.G]

I assume Plex is using Nvidia's H.264/AVC encoder, not x264. Running x264 or x265 would be slow on the Shield's CPU. Likewise, you'd need an app that uses Nvidia's H.265/HEVC encoder for fast H.265/HEVC encoding. Maybe you can ask Plex developers if they are willing to add this functionality.

Yeah that's what I thought but the presets they use are exactle named as the x264 ones... so I later 'assumed/hoped' it could be x264.
Plex also runs on multiple platforms which many aren't intel and/or nvidia related (windows, unix, my NAS, etc...)

anyway, you're right about contacting them. Wil do so.

If you can compile x26* for this target OS and CPU architecture, you can probably also use the encoder on it; but I would not recommend using mobile devices for such time and energy consuming tasks. Such CPUs may preferably save energy, instead of executing highly efficient SIMD instructions. And x265 requires a magnitude more processing power than x264, and highly efficient instruction extensions (especially vector math extensions like AVX) help x265 a lot more. Tegra X1 is highly parallelized, but will probably have a lower complexity in available instructions. And x265 does not require maximum parallelizability, instead rather wide and purpose-relevant SIMD and vector instructions.

its not really a portable device though and its cpu/gpu got some more punch (still not close to an i7 or i5 naturally)...
And the reason I want to use it for encoding is exactly the point you bring up: time & power...
I dont need the power of my media station as much as I need my work station :)
I wouldnt mind if it needs a whole week. As long as I can set it as a lower priority task so i can watch a movie from time to time in between.

[LigH]

OK, so I maybe confused the "controller tablet" with the host on one hand, and CPU with GPU on the other, when I first read another source of technical facts.

According to the English Wikipedia, the Tegra X1 has a Dual QuadCore structure (four ARM Cortex-A57 cores and four ARM Cortex-A53 cores in big.LITTLE configuration). And this "big.LITTLE" architecture may cause some issues (http://www.mono-project.com/news/2016/09/12/arm64-icache/), as I recently read: Threads can be shifted between either kind of CPU, depending on their processing power demand, and must always be aware of whether they run on a CPU with a small or a large cache line. And efficient use of cache lines is a very important speed optimization strategy.

My conclusion for now would be that x265 developers would need to double-check strategies to support this architecture class. They would neither wish to get their threads shifted to a low-power core, nor would they enjoy data corruption due to false assumptions about cache line capacities in an unfortunate moment.

[K.i.N.G]

Well,... I looked again and it's indeed using the x264 encoder.
Don't know why I missed the obvious the last time I checked... oh well :p

http://i.imgur.com/lHuLE9J.jpg

And got a reply in the plex forums aswell (yes, i'm feeling stupid now)
:
"Yes, it is the x.264 library in a highly customized version of ffmpeg."
So how hard would it be to include x265?

[LigH]

As I tried to explain: Probably harder than supporting multi-socket systems with identical CPUs. The CPUs in a big.LITTLE system are not identical, therefore its support needs special care.

Well, and if it can be supported at all ... then the PLEX team would have to release a new ffmpeg built for their specific purposes, and now including libx265.

[K.i.N.G]

As I tried to explain: Probably harder than supporting multi-socket systems with identical CPUs. The CPUs in a big.LITTLE system are not identical, therefore its support needs special care.

Well, and if it can be supported at all ... then the PLEX team would have to release a new ffmpeg built for their specific purposes, and now including libx265.

Ok, so if I get it correctly the already heavily modified ffmpeg they have already (to make x264 work on it) would not be enough?
To support x265 they need to heavily re-adjust it again? Too much difference between x264 and x265?

Sounds like you're pretty sure it wont happen anytime soon... :(
I think it will happen eventually at some point though...

[LigH]

I don't know how "heavily" PLEX had to modify ffmpeg. I just assume they did not include libx265, like libx264. Possibly because there is no certain support for your platform (OS and CPUs) yet. Because x265 depends a lot on optimal use of the available CPU architecture, it would be a very bad idea to compile it without any assembler optimization; yet, it may be possible. But in this case, expecting a week per movie is not unrealistic. Nevertheless, the mentioned problems with the big.LITTLE architecture may also happen for code generated by C/C++ compilers only, this is a general risk factor.

[K.i.N.G]

Ok, thank you for your patience and the great explanation :thanks:

[Kavitha]

I did a quick test with the revised -tu-limit settigs in 2.1+59. I had both inter and intra TU levels set at 4. No point using anything less since the whole point of this is to be able to make use of a higher inter TU without the performance penalty, right? So 4 makes sense, and likewise therefore 4 for intra as well.

What I found was --limit-tu 3 appeared the nicest to look at without any penalty of file size worth mentioning. I redid the tests with PSNR and SSIM stats enabled. Yes I know that with psy etc this isn't exactly a good way of testing, but --limit-tu 3 had better PSNR and SSIM, which matched what I saw visually. Do take into mind that I did the subjective visual test first without seeing the results.



yes, on testing limit-tu options with several videos observed that limit-tu 4 gives the best SSIM and visually limit-tu 1 and 3 are good

[filler56789]

x265_2.1+63 (commit 5ae077d7053d)

SEA motion search Implementation 0_o

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2468451&viewfull=1#post2468451

[LigH]

And again, and again, over and over: Could anyone please, pretty please, show me diagrams of different motion search ranges, so I can visually imagine their difference? In this topic, I am out of luck using Google (including their image search engine).

[MoSal]

(Using x265 2.1)

I did two encodes from the same source(BD 1080i + w3fdif).
The first output is 60fps.
The second is 30fps (roughly dropping every other frame).
All other settings are equal including crf and keyint.

The 2nd encode ended up with a larger bitrate (~11.3Mb/s vs. ~9.7Mb/s).
QP values used for I/P/B frames are also significantly lower in the 2nd encode.

Is this intended behavior?


ffmpeg -i sample.mkv -vf w3fdif -c:v hevc -preset slower -crf 19 -x265-params keyint=500:psy-rd=3:psy-rdoq=6:sao=0:qcomp=0.72:ipratio=1.18:pbratio=1.23:deblock=-2,-2 60.mkv

ffmpeg -i sample.mkv -vf w3fdif -c:v hevc -preset slower -crf 19 -x265-params keyint=500:psy-rd=3:psy-rdoq=6:sao=0:qcomp=0.72:ipratio=1.18:pbratio=1.23:deblock=-2,-2 -r 30 30.mkv

I can upload the sample if needed.

[Magik Mark]

x265_2.1+63 (commit 5ae077d7053d)

SEA motion search Implementation 0_o

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2468451&viewfull=1#post2468451

What is sea motion? Right now 2pass x265 encoding 10bit is taking twice amount of time to encode

[filler56789]

What is sea motion? Right now 2pass x265 encoding 10bit is taking twice amount of time to encode

I don't know 0_o I just compile x265.exe and share my builds. I don't even do minimal encoding tests anymore.

[ispano]

What is sea motion? Right now 2pass x265 encoding 10bit is taking twice amount of time to encode

From x265 docs:

SEA is similar to FULL search; a three step motion search adopted from x264: DC calculation followed by ADS calculation followed by SAD of the passed motion vector candidates, hence faster than Full search.

0. dia
1. hex (default)
2. umh
3. star
4. sea
5. full

[Jamaika]

It is certainly an interesting solution. Visually, it looks better as star motion. There isn't discoloration and less banding. I'm waiting for the correction presets and adjust the decoder LAV.
My suggestion tune grain:
--input-csp i422 --input-depth 10 --output-depth 10 --preset veryslow --crf 28 --me sea --aq-mode 0 --no-cutree --ipratio 1.0 --pbratio 1.5 --qpstep 1 --sao --psy-rd 4.0 --psy-rdoq 10.0 --no-rskip
http://i68.tinypic.com/5bpbh0.png
--input-csp i422 --input-depth 10 --output-depth 10 --preset veryslow --crf 28 --me star --aq-mode 0 --no-cutree --ipratio 1.0 --pbratio 1.1 --qpstep 1 --no-sao --psy-rd 4.0 --psy-rdoq 10.0 --no-rskip
http://i66.tinypic.com/207vrt1.png

EDIT: I use codec https://builds.x265.eu/x265-64bit-10bit-2016-11-30.exe
On the codec 10bit of this web page are the other results.
http://msystem.waw.pl/x265/x265-2.1+64-e44b7b5_gcc62.7z
EDIT2: I use decoder LAV http://tmod.nmm-hd.org/LAVFilters/old/LAVFilters-0.68.1-35-av1_test7-git-r3785(ed499ca).7z with MPC-HC
I am not satisfied with the visual quality of the video decoder http://www.videohelp.com/download/LAVFilters-0.68.1-45.exe

[LigH]

Anyone please visualize them!

[jlpsvk]

It is certainly an interesting solution. Visually, it looks better as star motion. There isn't discoloration and less banding. I'm waiting for the correction presets and adjust the decoder LAV.
My suggestion tune grain:
--input-csp i422 --input-depth 10 --output-depth 10 --preset veryslow --crf 28 --me sea --aq-mode 0 --no-cutree --ipratio 1.0 --pbratio 1.5 --qpstep 1 --sao --psy-rd 4.0 --psy-rdoq 10.0 --no-rskip
http://i68.tinypic.com/5bpbh0.png
--input-csp i422 --input-depth 10 --output-depth 10 --preset veryslow --crf 28 --me star --aq-mode 0 --no-cutree --ipratio 1.0 --pbratio 1.1 --qpstep 1 --no-sao --psy-rd 4.0 --psy-rdoq 10.0 --no-rskip
http://i66.tinypic.com/207vrt1.png

EDIT: I use codec https://builds.x265.eu/x265-64bit-10bit-2016-11-30.exe
On the codec 10bit of this web page are the other results.
http://msystem.waw.pl/x265/x265-2.1+64-e44b7b5_gcc62.7z
EDIT2: I use decoder LAV http://tmod.nmm-hd.org/LAVFilters/old/LAVFilters-0.68.1-35-av1_test7-git-r3785(ed499ca).7z with MPC-HC
I am not satisfied with the visual quality of the video decoder http://www.videohelp.com/download/LAVFilters-0.68.1-45.exe

encode times and bitrates?