x265 HEVC Encoder

[_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

[nakTT]

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

[Boulder]

Originally Posted by LigH

Gosh, 5,000.

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

[chen]

Originally Posted by LigH

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

Gosh, 5,000.

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 (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

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

[FranceBB]

Originally Posted by LigH

The x265 encoder uses no GPU at all.

Exactly. I remember having this conversation before in 2015 when we were talking about x264-like OpenCl encoding acceleration. x265 team said that the encoder was still in the main phase of its development and many things were changing, so they didn't have time implement OpenCl. Now it's 2018, years passed, x265 has become a very good codec, with many enhancement since 2015. Perhaps it's time to implement OpenCl encoding acceleration?

[chen]

Because HEVC max qp is 51, i wonder if there's some special reason that x265 takes 69 as the max qp. Does someone have a clue?

[sneaker_ger]

Probably to control vbv emergency denoising.

[chen]

Originally Posted by sneaker_ger

Probably to control vbv emergency denoising.

Oh, i see. Nice design. Thanks for the hint.

[3ngel]

Hi to all,
i've starting recently experimenting x265 as an alternative to x264
I've done a test to a clip with the same bitrate, and the result is not what i was hoping.

These are the screens

Original


x264
--pass 1 --slow-firstpass --profile high --level 4.1 --preset veryslow --tune grain --bitrate 5414
--pass 2 --slow-firstpass --profile high --level 4.1 --preset veryslow --tune grain --bitrate 5414



x265
--pass 1 --slow-firstpass --preset veryslow --tune grain --bitrate 5414
--pass 2 --slow-firstpass --preset veryslow --tune grain --bitrate 5414

avs [info]: AviSynth+ 0.1 (r1576, x64)
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 1920x816
avs [info]: Video framerate: 24000/1001
avs [info]: Video framecount: 205
avs4x26x [info]: "x265.exe" - --pass 1 --slow-firstpass --preset veryslow --tune
grain --bitrate 5414 -o 1pass.hevc --frames 205 --fps 24000/1001 --input-res 1
920x816 --input-csp i420
yuv [info]: 1920x816 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: 1pass.hevc
x265 [info]: HEVC encoder version 2.6+31-3712d13c09bf
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 B
MI2 AVX2
x265 [warning]: Rc Grain removes qp fluctuations caused by aq/cutree, Disabling
aq,cu-tree
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / on
x265 [info]: Rate Control / qCompress : ABR-5414 kbps / 0.60
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=4.00 rdoq=2 psy-rdoq=10.00
x265 [info]: tools: limit-tu=4 signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock stats-write

x265 [info]: frame I: 3, Avg QP:27.67 kb/s: 8761.29
x265 [info]: frame P: 30, Avg QP:27.57 kb/s: 5084.63
x265 [info]: frame B: 172, Avg QP:27.61 kb/s: 4393.54
x265 [info]: Weighted P-Frames: Y:3.3% UV:0.0%
x265 [info]: Weighted B-Frames: Y:5.8% UV:1.7%
x265 [info]: consecutive B-frames: 12.1% 0.0% 0.0% 9.1% 9.1% 21.2% 9.1% 18.2% 21
.2%

encoded 205 frames in 155.38s (1.32 fps), 4558.59 kb/s, Avg QP:27.60

-----
avs [info]: AviSynth+ 0.1 (r1576, x64)
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 1920x816
avs [info]: Video framerate: 24000/1001
avs [info]: Video framecount: 205
avs4x26x [info]: "x265.exe" - --pass 2 --slow-firstpass --preset veryslow --tune
grain --bitrate 5414 -o 2pass.hevc --frames 205 --fps 24000/1001 --input-res 1
920x816 --input-csp i420
yuv [info]: 1920x816 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: 2pass.hevc
x265 [info]: HEVC encoder version 2.6+31-3712d13c09bf
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 B
MI2 AVX2
x265 [warning]: Rc Grain removes qp fluctuations caused by aq/cutree, Disabling
aq,cu-tree
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / on
x265 [info]: Rate Control / qCompress : ABR-5414 kbps / 0.60
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=4.00 rdoq=2 psy-rdoq=10.00
x265 [info]: tools: limit-tu=4 signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock stats-read

x265 [info]: frame I: 3, Avg QP:25.33 kb/s: 13683.28
x265 [info]: frame P: 30, Avg QP:26.53 kb/s: 5932.95
x265 [info]: frame B: 172, Avg QP:26.47 kb/s: 5163.89
x265 [info]: Weighted P-Frames: Y:3.3% UV:0.0%
x265 [info]: Weighted B-Frames: Y:5.8% UV:1.7%
x265 [info]: consecutive B-frames: 12.1% 0.0% 0.0% 9.1% 9.1% 21.2% 9.1% 18.2% 21
.2%

encoded 205 frames in 160.23s (1.28 fps), 5401.11 kb/s, Avg QP:26.46

As you can see, x264 does overally a better job than x265.
In particular you can see banding and more "encoding artifact".
Is this the expected behaviour at this stage of x265 development or I'm missing parameters?

Thank you very much for your work

[benwaggoner]

Originally Posted by 3ngel

Hi to all,
i've starting recently experimenting x265 as an alternative to x264
I've done a test to a clip with the same bitrate, and the result is not what i was hoping.

These are the screens

Original


x264
--pass 1 --slow-firstpass --profile high --level 4.1 --preset veryslow --tune grain --bitrate 5414
--pass 2 --slow-firstpass --profile high --level 4.1 --preset veryslow --tune grain --bitrate 5414



x265
--pass 1 --slow-firstpass --preset veryslow --tune grain --bitrate 5414
--pass 2 --slow-firstpass --preset veryslow --tune grain --bitrate 5414




As you can see, x264 does overally a better job than x265.
In particular you can see banding and more "encoding artifact".
Is this the expected behaviour at this stage of x265 development or I'm missing parameters?

Thank you very much for your work

--tune grain are designed pretty differently for x264 and x265 IIRC. I wouldn't expect identical results even at the same net psychovisual preference. And from the still it isn't obvious to me that --tune grain is appropriate for this source. I would probably have tried --tune film in x264 (which doesn't have a x265 preset implementation).

These are relatively subtle differences; can you see the difference when playing at full speed?

Also, these are pretty high bitrates for VBR in either case. The point of x265 is for bitrates where x264 isn't good enough. Maybe try 2000 to see some bigger differences.

[3ngel]

@benwaggoner

Thanks for the reply, i'll try --tune film out of my curiosity.

Concerning subtle differences, my concept was to use x265 for "archival purposes", but i realize reading more and more around that x265 currently (or by design?) isn't aimed toward "archival" (high bitrates) but for "streaming" (low bitrates) and you confirm this too

The point of x265 is for bitrates where x264 isn't good enough.

So i can conclude i have to remain on x264 for archival for now.

Thanks

[pradeeprama]

Originally Posted by benwaggoner

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.

We have some broadcast partners using 3-4 frames of RADL pictures reporting that it helps improve efficiency for them in closed GOP scenarios, and to switch between streams easily. I don't see any downside in using it for fixed-GOP encodes as long as the decoder on the downstream can support it.

[pradeeprama]

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

x265 does not support changing resolution of the encode on the fly for a single instance of x265. Although this should be possible by just changing the resolution with a new SPS/PPS, from my experience, decoders don't always support this flawlessly in a single stream without a new VPS.