x265 HEVC Encoder

[stax76]

The zones feature is broken in 3.0+2, it encodes to the end but returns an error code, cmd/batch users normally don't check for the exit code, so they don't notice the problem but staxrip treats this a fatal and aborts further processing.

ffmpeg -i test.avs -f yuv4mpegpipe - | x265 --crf 22 --output-depth 10 --zones 0,200,b=1.2 --frames 300 --y4m --output test.hevc -

echo %ERRORLEVEL%
pause

Video encoding using x265 3.0+2 Wolfberry failed with exit code: -1073740940 (0xC0000374)

The exit code might be a system error code: A heap has been corrupted.

The feature you are referring to is probably this commit: Cosmetic: x264-r2204 style progress indicator

@MeteorRain's signature contains the link to the x265 binaries built from the Yuuki / Asuna branch of https://github.com/msg7086/x265-Yuuki-Asuna.

Probably yes, thanks.

[Jamaika]

I have a question.
Is it possible to use tune vmaf in x265 v3.1?

x265 has 5 tune modes (psnr, ssim, grain, zero-latency, animation) whereas SVT-HEVC
has only 3 tune modes (0 - visual quality, 1 - PSNR / SSIM and 2 - VMAF). Below 
table shows the mapping of tune modes,

+-----------------------+---------------------------+
| x265 Tune Modes       | SVT-HEVC Tune Modes       |
+=======================+===========================+
| vmaf                  | 2                         |
+-----------------------+---------------------------+
| psnr                  | 1                         |
+-----------------------+---------------------------+
| ssim                  | 1                         |
+-----------------------+---------------------------+
| grain                 | 0                         |
+-----------------------+---------------------------+
| fastdecode            | 0                         |
+-----------------------+---------------------------+
| zerolatency           | 0                         |
+-----------------------+---------------------------+
| animation             | 0                         |

If so how to initiate it?
api->param_default_preset(p, preset, "vmaf");

[Barough]

x265 v3.1_RC1+1-10decf67c077 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)

https://bitbucket.org/multicoreware/x265/commits/branch/Release_3.1

[Natty]

Originally Posted by MeteorRain

Did you say you make .yuv raw using ffv1 lossless? So would that be an AVI file instead?

i love your yuuki x265 mod, i used the latest 3.1 version, but observed that it hides encoding settings in mediainfo. i didn't change any encoding setting while using your mod..

hoping to get regular gcc 9.1 build updates from you.

[MeteorRain]

Originally Posted by Natty

i love your yuuki x265 mod, i used the latest 3.1 version, but observed that it hides encoding settings in mediainfo. i didn't change any encoding setting while using your mod..

hoping to get regular gcc 9.1 build updates from you.

Natty,

Thank you for the kind word. I have fixed the issue and slip-streamed to the same file.

I intentionally downgraded to gcc 8.3 as I expect a performance regression on newer gcc. But I might change my mind and upgrade to gcc 9.1 on final build. Suggestions welcome.

[Natty]

Originally Posted by MeteorRain

Natty,

Thank you for the kind word. I have fixed the issue and slip-streamed to the same file.

I intentionally downgraded to gcc 8.3 as I expect a performance regression on newer gcc. But I might change my mind and upgrade to gcc 9.1 on final build. Suggestions welcome.

it working fine

[birdie]

Has the meaning of CRF wildly changed since version 2.4?

I'm encoding the same source video using 2.4 and 3.0 using absolutely the same options ( -preset veryslow -x265-params keyint=600:min-keyint=30:bframes=16:crf=22:no-sao=1 - it's relatively static which is why keyint is so high) and 3.0 produces the file which is significantly heavier.

104,103,181 bytes for v2.4
128,682,330 bytes for v3.0

Also encoding has become significantly slower:

2.4: encoded 10656 frames in  6302.40s (1.69 fps), 2229.94 kb/s, Avg QP:27.68
3.0: encoded 10656 frames in 11981.75s (0.89 fps), 2780.38 kb/s, Avg QP:27.30

Full output for 2.4:

x265 [info]: HEVC encoder version 2.4
x265 [info]: build info [Linux][GCC 6.3.1][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features       : 2 / wpp(12 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: 30 / 600 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt        : 40 / 16 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 1
x265 [info]: References / ref-limit  cu / depth  : 5 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-22.0 / 0.60
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [info]: tools: rskip limit-tu=4 signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing deblock
Output #0, matroska, to '265.mkv':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf57.71.100
    Stream #0:0(eng): Video: hevc (libx265), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 29.83 fps, 1k tbn, 29.83 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      encoder         : Lavc57.89.100 libx265
    Stream #0:1(eng): Audio: aac (LC) ([255][0][0][0] / 0x00FF), 48000 Hz, mono, fltp, 96 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
frame=10656 fps=1.7 q=-0.0 Lsize=  101663kB time=00:05:57.24 bitrate=2331.2kbits/s speed=0.0567x
video:97282kB audio:4187kB subtitle:0kB other streams:0kB global headers:2kB muxing overhead: 0.192047%
x265 [info]: frame I:     20, Avg QP:20.80  kb/s: 13832.49
x265 [info]: frame P:   2322, Avg QP:22.77  kb/s: 6661.60
x265 [info]: frame B:   8314, Avg QP:29.07  kb/s: 964.32
x265 [info]: Weighted P-Frames: Y:11.9% UV:9.3%
x265 [info]: Weighted B-Frames: Y:6.8% UV:4.4%
x265 [info]: consecutive B-frames: 7.3% 5.3% 8.5% 30.1% 16.4% 21.8% 6.9% 3.2% 0.2% 0.2% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

Full output for 3.0:

x265 [info]: HEVC encoder version 3.0
x265 [info]: build info [Linux][GCC 9.1.1][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features       : 2 / wpp(12 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 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 30 / 600 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt        : 40 / 16 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 1
x265 [info]: References / ref-limit  cu / depth  : 5 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-22.0 / 0.60
x265 [info]: tools: rect amp rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00 rskip
x265 [info]: tools: signhide tmvp b-intra strong-intra-smoothing deblock
Output #0, matroska, to '265.mkv':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: isommp42
    com.android.version: 6.0
    encoder         : Lavf58.20.100
    Stream #0:0(eng): Video: hevc (libx265), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 29.83 fps, 1k tbn, 29.83 tbc (default)
    Metadata:
      encoder         : Lavc58.35.100 libx265
      handler_name    : VideoHandle
    Stream #0:1(eng): Audio: aac (LC) ([255][0][0][0] / 0x00FF), 48000 Hz, mono, fltp, 96 kb/s (default)
    Metadata:
      handler_name    : SoundHandle
frame=10656 fps=0.9 q=-0.0 Lsize=  125666kB time=00:05:57.24 bitrate=2881.6kbits/s speed=0.0298x    
video:121284kB audio:4187kB subtitle:0kB other streams:0kB global headers:2kB muxing overhead: 0.155674%
x265 [info]: frame I:     20, Avg QP:20.69  kb/s: 16303.41
x265 [info]: frame P:   2322, Avg QP:22.30  kb/s: 8450.15 
x265 [info]: frame B:   8314, Avg QP:28.71  kb/s: 1164.35 
x265 [info]: Weighted P-Frames: Y:11.9% UV:9.3%
x265 [info]: Weighted B-Frames: Y:6.8% UV:4.4%
x265 [info]: consecutive B-frames: 7.3% 5.3% 8.5% 30.1% 16.4% 21.8% 6.9% 3.2% 0.2% 0.2% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 

encoded 10656 frames in 11981.75s (0.89 fps), 2780.38 kb/s, Avg QP:27.30

[ChaosKing]

Different settings affect the CRF output: https://x265.readthedocs.io/en/defau...r-enhancements

Preset: change param defaults for veryslow and slower preset. Replace slower preset with defaults used in veryslow preset and change param defaults in veryslow preset as per experimental results.
AQ: change default AQ mode to auto-variance

[Boulder]

Filesize is probably due to the default aq-mode being 2 now. It often causes a higher average bitrate with the same CRF than aq-mode 1.

[Blue_MiSfit]

The preset changes also mean veryslow is radically different relative to 2.4.

[edit] Just saw this was mentioned already [/edit]

[katzenjoghurt]

Originally Posted by stax76

The zones feature is broken in 3.0+2, it encodes to the end but returns an error code, cmd/batch users normally don't check for the exit code, so they don't notice the problem but staxrip treats this a fatal and aborts further processing.[...]

Could some kind soul please, please, pretty please investigate this bug?
It is so annoying.

It means that after every encoding with zones (with an affected tool) your would need to do the muxing manually afterwards
as the tool crashes away due to the returned x265 error code.

See also: https://bitbucket.org/multicoreware/...hen-using-zone

[birdie]

Originally Posted by ChaosKing

Different settings affect the CRF output: https://x265.readthedocs.io/en/defau...r-enhancements

My settings were 100% identical.

[Boulder]

No they're not if you look at the output in your post. I still think the biggest difference comes from aq-mode changing from 1 to 2. The other changes should cause a much smaller change in the bitrate.

EDIT: as mentioned earlier, the presets have been changed. Veryslow in v2.4 is different from v3.0.

[Barough]

x265 v3.1_RC1+3-3bdf06e3c628 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)

https://bitbucket.org/multicoreware/x265/commits/branch/Release_3.1

[StvG]

Originally Posted by katzenjoghurt

Could some kind soul please, please, pretty please investigate this bug?
It is so annoying.

It means that after every encoding with zones (with an affected tool) your would need to do the muxing manually afterwards
as the tool crashes away due to the returned x265 error code.

See also: https://bitbucket.org/multicoreware/...hen-using-zone

Use VS20xx not GCC x.x build from here.

[katzenjoghurt]

Hey StvG,

in fact I already do. I'm using the VS2019 versions from there.

[katzenjoghurt]

Originally Posted by katzenjoghurt

Oh my.
Am I the only one having such a hard time encoding scenes with red light / red backgrounds?

[...]

Oh man. I THINK I finally found a solution for my neverending problem with red areas getting blurred and/or blocky.

People already gave me a hint to use 10bit encoding or playing around with the crqpoffs parameter. Both didn't really help.

This changed drastically now after I converted the source to YV24 colorspace and encoded it with Main 444 10.

Suddenly the crqpoffs parameter started to work wonders and setting it to -1 already brought back most of the details.


How to do it in StaxRip 1.7.0.6:
1) Click on the "AVS Filter" label. Click "Profiles".
2) Find the [Misc] section and add this line to the bottom: ConvertToYV24 = ConvertToYV24()
3) Add the Filter now via right-click -> Misc -> ConvertToYV24
4) Go into the x265 encoder settings
5) In "Basic" chose the Main 444 10 profile.
6) In "Rate Control 1" set CR QB Offset to -1.

[StvG]

Originally Posted by katzenjoghurt

Hey StvG,

in fact I already do. I'm using the VS2019 versions from there.

Hey. A week ago or so I tested VS2019 builds and I had no problems when using zones. GCC builds were crashing when using zones.

[birdie]

Originally Posted by Boulder

No they're not if you look at the output in your post. I still think the biggest difference comes from aq-mode changing from 1 to 2. The other changes should cause a much smaller change in the bitrate.

EDIT: as mentioned earlier, the presets have been changed. Veryslow in v2.4 is different from v3.0.

I thought CRF actually meant something. Not really a given bitrate but something close to it.

[mini-moose]

Originally Posted by birdie

I thought CRF actually meant something. Not really a given bitrate but something close to it.

the lower the CRF value, the higher the bitrate. slowdown is due to preset changes, bitrate differences are due to AQ mode changing from AQ1 default to AQ2 default.

I found that AQ1 was giving a higher bitrate than AQ2, but I suppose it depends on source. I think AQ1 is constant while AQ2 is variable.