x265 HEVC Encoder

[divxmaster]

Originally Posted by 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]

Originally Posted by dipje

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]

Originally Posted by psyside

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]

Originally Posted by Midzuki

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]

Originally Posted by psyside

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]

Originally Posted by x265_Project

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]

Originally Posted by fisherwei

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 (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 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

[Boulder]

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

[burfadel]

Originally Posted by Boulder

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]

Originally Posted by Ma

In commit a3334a2 (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 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

It works for me. Thanks in advance.

[LigH]

x265_2.6+31-3712d13c09bf

• 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

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]

Originally Posted by 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

Sad 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]

Originally Posted by 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

thanks for everything and good luck