x265 HEVC Encoder

[Selur]

What to use for master-display when MediaInfo reports 'Display P3' ?
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2

[Motenai Yoda]

What to use for master-display when MediaInfo reports 'Display P3' ?
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2

from x265.readthedocs.io

Example for a P3D65 1000-nits monitor, where G(x=0.265, y=0.690), B(x=0.150, y=0.060), R(x=0.680, y=0.320), WP(x=0.3127, y=0.3290), L(max=1000, min=0.0001):

G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)

[Selur]

Okay, but there is also DCI P3 Theater which has a different white point, so might be good to know which is which. ;)

[Motenai Yoda]

Okay, but there is also DCI P3 Theater which has a different white point, so might be good to know which is which. ;)
:rolleyes:

maybe (0.314,0.351)

[Boulder]

In the docs, it says that --hdr-opt should be used with AQ-mode on. --tune grain disables AQ-mode, so is it OK to use --hdr-opt anyway or better to leave it out? Also, it is said that the input video should be 10-bit 4:2:0. Is it safe to input 16-bit video (because of processing things in Vapoursynth in 16-bit land) if the original source is 10-bit 4:2:0 and signal --input-depth 16?

[benwaggoner]

Okay, but there is also DCI P3 Theater which has a different white point, so might be good to know which is which. ;)
DCI P3 is different in a bunch of other ways. If content is meant for display on an HDR TV, it won't use the DCI white point.

[benwaggoner]

In the docs, it says that --hdr-opt should be used with AQ-mode on. --tune grain disables AQ-mode, so is it OK to use --hdr-opt anyway or better to leave it out? Also, it is said that the input video should be 10-bit 4:2:0. Is it safe to input 16-bit video (because of processing things in Vapoursynth in 16-bit land) if the original source is 10-bit 4:2:0 and signal --input-depth 16?
--tune grain may not be appropriate to many HDR sources anyway. It's not a panacea. For content that doesn't need --tune-grain you waste a lot of bits to get the same output quality.

[LigH]

x265 2.6+24-69cfe46e8a3b (https://www.mediafire.com/file/a596qautmz4a5lq/x265_2.6%2B24-69cfe46e8a3b.7z) – merge with stable

Several fixes e.g. in analysis and VBV handling; added support for RADL pictures; renamed options:

--radl <integer> Number of RADL pictures allowed in front of IDR. Default 0

( --analysis-reuse-mode <string|int> removed )
--analysis-save <filename> Dump analysis info into the specified file. Default Disabled
--analysis-load <filename> Load analysis buffers from the file specified. Default Disabled

[benwaggoner]

x265 2.6+24-69cfe46e8a3b (https://www.mediafire.com/file/a596qautmz4a5lq/x265_2.6%2B24-69cfe46e8a3b.7z) – merge with stable

Several fixes e.g. in analysis and VBV handling; added support for RADL pictures; renamed options:
I hadn’t dealt with RADL before. Based on some documentation, it sounds like it relates to the frames before an IDR in an open GOP. That it requires a fixed IDR cadence suggests a pretty specific use case, like broadcast stream switching.

Anyone have some context to offer?

[x265_Project]

I hadn’t dealt with RADL before. Based on some documentation, it sounds like it relates to the frames before an IDR in an open GOP. That it requires a fixed IDR cadence suggests a pretty specific use case, like broadcast stream switching.

Anyone have some context to offer?

While an Instantaneous Decoder Refresh (IDR) picture cannot depend on any pictures before it in decoding order (nor can any pictures that follow the IDR picture), there is a concept of leading pictures that is allowed. Random Access Decodable Leading (RADL) B pictures precede the IDR in presentation order and immediately follow it in decoding order. This allows the encoder to exploit the benefits of prediction from a following frame (in presentation order). So, if there is a scene change just prior to the end of a Group of Pictures (GOP), x265 can use RADL B pictures referencing the next IDR picture (in the subsequent GOP) to get the benefits of prediction.

[Selur]

What would happen if one sets radl to max key int? :)

[x265_Project]

What would happen if one sets radl to max key int? :)
I realize you're joking, but for clarity...

**Range of values: Between 0 and `--bframes`

[benwaggoner]

While an Instantaneous Decoder Refresh (IDR) picture cannot depend on any pictures before it in decoding order (nor can any pictures that follow the IDR picture), there is a concept of leading pictures that is allowed. Random Access Decodable Leading (RADL) B pictures precede the IDR in presentation order and immediately follow it in decoding order. This allows the encoder to exploit the benefits of prediction from a following frame (in presentation order). So, if there is a scene change just prior to the end of a Group of Pictures (GOP), x265 can use RADL B pictures referencing the next IDR picture (in the subsequent GOP) to get the benefits of prediction.
So, it's sort of an enhanced Open GOP that can apply to the last frames in the prior GOP, not just the first frames in the new GOP?

I can see how that could reduce keyframe strobing and improve efficiency with fixed cadence encodes. Are there any downsides to it? Any compatibility issues?

[Asmodian]

It actually sounds like a feature for closed GOP, because the importance of closed v.s. open GOP is during decoding, frames that are decoded after an IDR frame can be presented before it while only requiring data (in the decoded picture buffer) from the current GOP. Any RADL B frames would simply be dropped when seeking to the IDR frame.

[fisherwei]

from 2.6(+22 and +24), it seems some problem in my computer.

y4m [info]: 1920x800 fps 24000/1001 i420p10 unknown frame count
raw [info]: output file: D:\x265-workspace\output\harrypotter2001\00001.1080.hevc
x265 [info]: HEVC encoder version 2.6+24-69cfe46e8a3b
x265 [info]: build info [Windows][MSVC 1900][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: Turning on repeat-headers for HDR compatibility
x265 [info]: Main 10 profile, Level-5.1 (High tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(25 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2 intra
x265 [info]: ME / range / subpel / merge : star / 25 / 5 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 1 / 360 / 40 / 5.00
x265 [info]: Cb/Cr QP Offset : -2 / -2
x265 [info]: Intra 32x32 TU penalty type : 1
x265 [info]: Lookahead / bframes / badapt : 60 / 9 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / on / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 0.9 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-19.0 / 0.70
x265 [info]: VBV/HRD buffer / max-rate / init : 100000 / 100000 / 0.900
x265 [info]: tools: limit-modes rd=4 ssim-rd rdoq=2 psy-rdoq=8.00 limit-tu=3
x265 [info]: tools: signhide tmvp b-intra lslices=4 deblock(tC=-1:B=-1)
Error: fwrite() call failed when writing frame: 77, plane: 0, errno: 32
Output 82 frames in 139.43 seconds (0.59 fps)
DONE


2.5 is OK, and sometimes 2.6 is OK too.

Anybody know what's wrong?

Windows 10 64bit

Update:
2.6+17 was OK.
2.6+22/+24 was wrong.
source stream from vspipe.exe

[Ma]

from 2.6(+22 and +24), it seems some problem in my computer.

Your options are far from default -- could you post your command line to easier reproduce the problem.

[x265_Project]

It actually sounds like a feature for closed GOP, because the importance of closed v.s. open GOP is during decoding, frames that are decoded after an IDR frame can be presented before it while only requiring data (in the decoded picture buffer) from the current GOP. Any RADL B frames would simply be dropped when seeking to the IDR frame.

Yes, if someone was seeking to (starting playback from) the IDR frame, any RADL B frames (which come after the IDR frame in decoding order) would be dropped, as they represent frames that come before the IDR frame in presentation order.

The term "current GOP" can be a bit confusing when we're talking about leading pictures. RADL B pictures require the IDR picture (the first frame of the next GOP) as a reference. But the decoder knows this already, as the NAL unit type of the IDR picture will indicate that leading pictures (from the previous GOP) follow the IDR picture in decode order (it will be an IDR_W_RADL as opposed to an IDR_N_LP - IDR with no leading pictures).

[Barough]

x265 v2.6+26-b4edf9b44d23 (http://www.mediafire.com/file/ehdt064y73u5r2o/) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[EDIT]
DL Link to v2.6+26-b4edf9b44d23 have been fixed.

[divxmaster]

Am I right in presuming that the latest "Meltdown" security issue, and the implemented KPTI fix, will not impact x265 much or at all?
From what I understand, its only multiple/regular kernel calls/ints that will cause a slowdown (TLB flush), and presumably x265 doesnt do many? (only file read and writes + text output)
Although for me at least, I have Haswell (soon to be 8700k), so it has PCID, which will mitigate TLB flushes.

Cheers
Divxmaster

[fisherwei]

Your options are far from default -- could you post your command line to easier reproduce the problem.

"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" --y4m "D:\x265-workspace\output\harrypotter2001\00001.1080.vpy" - | "D:\x265-workspace\bin\x265\x265-2.6+24-69cfe46_vs2015-AVX\x265.exe" --y4m --pool "15,-" --preset slower --tune ssim --profile main10 --level-idc 5.1 --crf 19 --cbqpoffs -2 --crqpoffs -2 --rc-lookahead 60 --me 3 --subme 5 --merange 25 --b-adapt 2 --bframes 9 --ref 5 --aq-mode 3 --aq-strength 0.9 --qcomp 0.70 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --limit-modes --limit-refs 2 --output-depth 10 --rd 4 --rdoq-level 2 --psy-rd 2.0 --psy-rdoq 8 --ssim-rd --deblock -1 --no-sao --no-open-gop --no-rect --no-amp --no-strong-intra-smoothing --no-rskip --tu-intra-depth 2 --tu-inter-depth 2 --ctu 32 --limit-tu 3 --max-tu-size 32 --qg-size 32 --b-intra --weightb --rdpenalty 1 --keyint 360 --min-keyint 1 --vbv-bufsize 100000 --vbv-maxrate 100000 --hdr-opt --aud --hrd --chromaloc 2 --max-cll "552,190" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --log-level 2 --csv "D:\x265-workspace\output\harrypotter2001\00001.1080.csv" --output "D:\x265-workspace\output\harrypotter2001\00001.1080.hevc" -


import vapoursynth as vs
core = vs.get_core()
video = core.lsmas.LWLibavSource(source=r'E:\Harry.Potter.und.der.Stein.der.Weisen.2001.MULTi.COMPLETE.UHD.BLURAY-NIMA4K\00001.m2ts')
video = core.std.CropRel(clip=video, left=0, right=0, top=280, bottom=280)
video.set_output()

[divxmaster]

Am I right in presuming that the latest "Meltdown" security issue, and the implemented KPTI fix, will not impact x265 much or at all?
From what I understand, its only multiple/regular kernel calls/ints that will cause a slowdown (TLB flush), and presumably x265 doesnt do many? (only file read and writes + text output)
Although for me at least, I have Haswell (soon to be 8700k), so it has PCID, which will mitigate TLB flushes.

Cheers
Divxmaster

Just to confirm, I have done some testing with the Meltdown/Spectre patches and x265 doesnt seem slowed at all. (within normal variance).

Run before patching: 9.73fps
After software meltdown patch 9.67fps
after hardware spectre patch 9.60fps (dell 7559 laptop)

If you havent looked into these meltdown/spectre issues yet, do it asap, this is very serious.

Cheers,
Divxmaster

[mikeq]

This might have been posted, but if I wanted to re-encode some youtube-HDR files to make them compatible with my set, how do I translate the HDR metadata?
ffprobe gives this:
Content Light Level Metadata, MaxCLL=2000, MaxFALL=300
Mastering Display Metadata, has_primaries:1 has_luminance:1 r(0.6800,0.3200) g(0.2649,0.6900) b(0.1500 0.0600) wp(0.3127, 0.3290) min_luminance=0.009900,max_luminance=2000.000000
and this:
Stream #0:0(eng): Video: vp9 (Profile 2), yuv420p10le(tv, bt709/bt2020/smpte2084), 3840x2160, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 1k tbn, 1k tbc (default)

am I correct that x265 needs:
--master-display "G(2649,6900)B(1500,0600)R(6800,3200)WP(3127,3290)L(99,20000000)" --max-cll 2000,300 --range limited --colorprim bt2020 --colormatrix bt709 --transfer smpte2084

Specially the order for --max-cll which is listed as cll,fall in the help text, and the master-display string where I did every ffprobe value * 10000, is that correct?

As near as I can tell it's every ffprobe value * 500 - if you look at the "standard" one - that's what it works out to.

[Ma]

@fisherwei
Thanks for command line -- I can reproduce x265 crash:
f:\speed\2.6+24>ffmpeg -i ../tearsofsteel-4k.y4m -v warning -strict -1 -pix_fmt yuv420p10 -f yuv4mpegpipe - | x265 --y4m --pool "15,-" --preset slower --tune ssim --profile main10 --level-idc 5.1 --crf 19 --cbqpoffs -2 --crqpoffs -2 --rc-lookahead 60 --me 3 --subme 5 --merange 25 --b-adapt 2 --bframes 9 --ref 5 --aq-mode 3 --aq-strength 0.9 --qcomp 0.70 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --limit-modes --limit-refs 2 --output-depth 10 --rd 4 --rdoq-level 2 --psy-rd 2.0 --psy-rdoq 8 --ssim-rd --deblock -1 --no-sao --no-open-gop --no-rect --no-amp --no-strong-intra-smoothing --no-rskip --tu-intra-depth 2 --tu-inter-depth 2 --ctu 32 --limit-tu 3 --max-tu-size 32 --qg-size 32 --b-intra --weightb --rdpenalty 1 --keyint 360 --min-keyint 1 --vbv-bufsize 100000 --vbv-maxrate 100000 --hdr-opt --aud --hrd --chromaloc 2 --max-cll "552,190" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --log-level 2 --csv "D:\x265-workspace\output\harrypotter2001\00001.1080.csv" --output "D:\x265-workspace\output\harrypotter2001\00001.1080.hevc" -
[yuv4mpegpipe @ 000001b607414760] Warning: generating non standard YUV stream. Mjpegtools will not work.
y4m [info]: 4096x1714 fps 24/1 i420p10 unknown frame count
raw [info]: output file: D:\x265-workspace\output\harrypotter2001\00001.1080.hevc
x265 [info]: HEVC encoder version 2.6+24-69cfe46e8a3b
x265 [info]: build info [Windows][MSVC 1900][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: Turning on repeat-headers for HDR compatibility
x265 [info]: Main 10 profile, Level-5.1 (High tier)
x265 [info]: Thread pool created using 12 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(54 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2 intra
x265 [info]: ME / range / subpel / merge : star / 25 / 5 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 1 / 360 / 40 / 5.00
x265 [info]: Cb/Cr QP Offset : -2 / -2
x265 [info]: Intra 32x32 TU penalty type : 1
x265 [info]: Lookahead / bframes / badapt : 60 / 9 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / on / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 0.9 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-19.0 / 0.70
x265 [info]: VBV/HRD buffer / max-rate / init : 100000 / 100000 / 0.900
x265 [info]: tools: limit-modes rd=4 ssim-rd rdoq=2 psy-rdoq=8.00 limit-tu=3
x265 [info]: tools: signhide tmvp b-intra lslices=4 deblock(tC=-1:B=-1)
av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
------------------------------
Finally I found the bug -- x265 is trying to write 2195 bytes to allocated 2000 bytes memory. Preparing the patch...

[psyside]

How does one play VP9/HEVC videos on youtube without insane stuttering? i got i5 2400/GTX960?

[Midzuki]

How does one play VP9/HEVC videos on youtube without insane stuttering? i got i5 2400/GTX960?

VP9 is not HEVC, and AFAIK YouTube does not use HEVC.
Also, your question is rather off-topic.

[psyside]

VP9 is not HEVC, and AFAIK YouTube does not use HEVC.
Also, your question is rather off-topic.

I'm a noob, i couldnt find any other thread to ask.

Alsoi have downloaded video from youtube, which in the media info states VP9/HEVC?

[microchip8]

I'm a noob, i couldnt find any other thread to ask.

Alsoi have downloaded video from youtube, which in the media info states VP9/HEVC?

if you haven't found a thread, start a new one! it's that simple

[benwaggoner]

Yes, if someone was seeking to (starting playback from) the IDR frame, any RADL B frames (which come after the IDR frame in decoding order) would be dropped, as they represent frames that come before the IDR frame in presentation order.

The term "current GOP" can be a bit confusing when we're talking about leading pictures. RADL B pictures require the IDR picture (the first frame of the next GOP) as a reference. But the decoder knows this already, as the NAL unit type of the IDR picture will indicate that leading pictures (from the previous GOP) follow the IDR picture in decode order (it will be an IDR_W_RADL as opposed to an IDR_N_LP - IDR with no leading pictures).
Is there a recommendation on using RADL? Is it something that can be safely used in all fixed-GOP encodes to potentially increase quality?

From the description, it sounds like the fundamental technology could also be used in variable duration Closed GOP as well.

[Ma]

from 2.6(+22 and +24), it seems some problem in my computer.
[...]
2.6+17 was OK.
2.6+22/+24 was wrong.

In commit a3334a2 (https://bitbucket.org/multicoreware/x265/commits/a3334a263d26920696091ccfcfe8e0db8be16364) (ver. 2.6+19) there are 2 new options: "analysis-load" and "analysis-save". In function x265_param2string all options are written to a memory buffer in text form (readable), the buffer size was only 2000 bytes, with example that hangs in my system it was 2028 bytes to write.

The bug is critical (even if it not hangs it writes to unknown memory) so we should fix this -- you can try patch 19377 (https://patches.videolan.org/patch/19377/) and report back if it helps.

I've prepared binaries with this patch (and patches 19378, 19379 which are not so important): x265p-2.6+27-2f3c415_vs2015.7z (http://msystem.waw.pl/x265/x265p-2.6+27-2f3c415_vs2015.7z)

[Boulder]

Can anyone explain the situation where --rd-refine could be useful? I.e. is it meant to battle against some specific issue?

[burfadel]

Can anyone explain the situation where --rd-refine could be useful? I.e. is it meant to battle against some specific issue?

I found when used it seems to improve the picture quality, sujectively of course. I think it may affect detailed low light scenes more so than other situations. Admittedly I haven't tried it on and off for a while, other changes may negate its benefits.

[Dclose]

Since when does x265 have a sub-CTU quantization group setting of 8 (instead of minimum 16) available? That's new, isn't it? Maybe it's been there a while and I'm just not remembering.

[fisherwei]

In commit a3334a2 (https://bitbucket.org/multicoreware/x265/commits/a3334a263d26920696091ccfcfe8e0db8be16364) (ver. 2.6+19) there are 2 new options: "analysis-load" and "analysis-save". In function x265_param2string all options are written to a memory buffer in text form (readable), the buffer size was only 2000 bytes, with example that hangs in my system it was 2028 bytes to write.

The bug is critical (even if it not hangs it writes to unknown memory) so we should fix this -- you can try patch 19377 (https://patches.videolan.org/patch/19377/) and report back if it helps.

I've prepared binaries with this patch (and patches 19378, 19379 which are not so important): x265p-2.6+27-2f3c415_vs2015.7z (http://msystem.waw.pl/x265/x265p-2.6+27-2f3c415_vs2015.7z)

It works for me. Thanks in advance. :thanks:

[LigH]

x265_2.6+31-3712d13c09bf (https://www.mediafire.com/file/nxo94z3lljqfuf1/x265_2.6%2B31-3712d13c09bf.7z)


important stability fix when using very verbose parameters like zones and additional files (could exceed a too small internal buffer)
input: change from ifstream to stdio stream
change date to 2018 in output file header

[x265_Project]

Hi everyone.
I've been the head of the x265 project and the head of MulticoreWare's video business from the start. But I need to let you know that I've decided to move on, joining Beamr as VP Strategy. x265 has a strong team, and it's in good hands. I'll hand this Doom9 account over to someone on the MulticoreWare team.

Tom

[Selur]

Sad to hear you leave the x265 project, but wish you good luck&co at Beamr.

[Barough]

Hi everyone.
I've been the head of the x265 project and the head of MulticoreWare's video business from the start. But I need to let you know that I've decided to move on, joining Beamr as VP Strategy. x265 has a strong team, and it's in good hands. I'll hand this Doom9 account over to someone on the MulticoreWare team.

TomSad to hear that ur leaving x265. Good luck with Beamr.

Sent from my SM-G935F via Tapatalk

[LigH]

Be well and best success, Tom. And we will appreciate your (team's) continued contact and support – here and elsewhere.

[pingfr]

Thanks for everything Tom! Be well, good luck in your future endeavors!

[_kermit]

Hi everyone.
I've been the head of the x265 project and the head of MulticoreWare's video business from the start. But I need to let you know that I've decided to move on, joining Beamr as VP Strategy. x265 has a strong team, and it's in good hands. I'll hand this Doom9 account over to someone on the MulticoreWare team.

Tom

thanks for everything and good luck

[nakTT]

Hi everyone.
I've been the head of the x265 project and the head of MulticoreWare's video business from the start. But I need to let you know that I've decided to move on, joining Beamr as VP Strategy. x265 has a strong team, and it's in good hands. I'll hand this Doom9 account over to someone on the MulticoreWare team.

Tom

Thanks for everything and best of luck in your future endeavors.

[chen]

My raw picture size varies from time to time. For instance, I get 250 frames in 1080p for the first 10 secs, and then another 250 frames in 720p in the second 10 secs, and so on. And i need to encode all these frames into a same HEVC bit stream. I found no appropriate command line option, and thus looked into the apis. The x265_encoder_reconfig() seems to be a possible solution, but I am not sure. Can someone share some ideas or experiences?

[LigH]

Sounds like DVB with different programmes; I believe this works only on a container level?!

Gosh, 5,000. :o

[Boulder]

Gosh, 5,000. :o

OT: I'm more scared of the year 2001 :p Where did all the years go?

[chen]

Sounds like DVB with different programmes; I believe this works only on a container level?!

Gosh, 5,000. :o

yes, containers supports video sections with different resolutions, and the output of my encoder will be put in a container.
Question is whether I have to create a new encoder when my picture size has changed or I just need to reconfigure my current encoder?

[nevcairiel]

Considering you need a full decoder and bitstream reset anyway to change resolution, might as well create a new encoder? At least that is known to work.

[Sachin]

X265 encoding in my system uses only Intel uhd graphic card(almost 100%) but Nvidia graphic card is not utilized(0% usage).

My graphic card GEFORCE MX150.
Processor Intel i7-8550@1.8ghz
Ram 16gb

Encoder "x265_2.6+31-3712d13c09bf" with avs2pipemod.

I searched in Google for solution but I don't got one. Please help

[LigH]

The x265 encoder uses no GPU at all; no GPU offers any useful features which would actually speed up x265 without reducing the achievable quality. If your intel GPU is utilized, then the reason may be decoding the source via QuickSync?! Unfortunately you did not post any details about your AviSynth script. But anyway, no matter how the video source is provided, x265 will not use any GPU for encoding.

[Sachin]

Thanks for reply. My doubts are cleared.

[Barough]

x265 v2.6+32-b763c22920f6 (http://www.mediafire.com/file/hs9gg177jwmhmo7/) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default