x265 HEVC Encoder

[FranceBB]

I will try next time to see how much time will it take. Lossless x264 ultrafast 1080p is about 8 hours.

If you really need a lossless mezzanine that doesn't require much computational cost, I think you're better off with UTVideo.
Alternatively, you can use other lossless codecs like FFV1, HuffYUV or Lagarith, although my suggestion is UTVideo or FFV1.

[~ VEGETA ~]

If you really need a lossless mezzanine that doesn't require much computational cost, I think you're better off with UTVideo.
Alternatively, you can use other lossless codecs like FFV1, HuffYUV or Lagarith, although my suggestion is UTVideo or FFV1.

I tried make it .yuv raw from virtualdub2 using ffv1 lossless, it took the same time as x264-10bit lossless if not a bit more.

Also, now x265 inputs it directly but it encodes it WAY much slower for IDK reason. Also file size is so freaking huge, maybe I did something bad despite using the exact same encoding commands:



x265_64bit_10bit.exe --preset slower --crf 17 --ref 6 --rd 6 --psy-rd 1 --ctu 32 --aq-strength 0.8 --output-depth 10 --input-res 1920x1080 --fps 24000/1001 --input "C:\videp.yuv" --output "C:\output.hevc"

pause

[FranceBB]

Also file size is so freaking huge

That's not surprising, considering that lossless codecs have limited algorithms to use in order to achieve a compression; as to the uncompressed .yuv file, well, uncompressed is uncompressed.

it took the same time as x264-10bit lossless if not a bit more.
Oh... I didn't expect that- Apparently x264 lossless is more optimized or perhaps it's because you used VirtualDub rather than ffmpeg to encode it.

now x265 inputs it directly but it encodes it WAY much slower
I didn't expect that. Encoding an uncompressed yuv source shouldn't take more than encoding an uncompressed A/V stream like the one Avisynth pipes to x265 nor encoding a lossless x264 source.
I mean, x265 is still gonna use its internal decoder to take the source in input, right?
Encoding-wise, I wonder whether its own internal decoder is more optimized for taking one thing in input rather than the other, or perhaps is just the way things have been allocated... but that cannot be since each source is lossless and there are little differences on filesize to justify a big speed different, besides compressed lossless, although with less space, still have to be "decoded", while uncompressed lossless files are ready to go but way bigger, so perhaps the hard drive is not fast enough to justify an uncompressed source as it takes longer to buffer it than decoding a losslessly compressed one... I don't know.
Perhaps someone can enlighten me as well about this.

[Wolfberry]

x265-3.0_Au+24-4217e691387c-win64-multilib (https://drive.google.com/open?id=1gCld9Iy8BubZdvR0o-V5sI07OEwbSuWT)

x265 [info]: HEVC encoder version 3.0_Au+24-4217e691387c
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 8bit+10bit+12bit
x265 [info]: (libavcodec 58.52.101)
x265 [info]: (libavformat 58.27.103)
x265 [info]: (libavutil 56.26.101)
x265 [info]: (lsmash 2.16.1)

[Leeloo Minaï]

now x265 inputs it directly but it encodes it WAY much slower

FFV1 offers one of the most efficient compression rate, size-wise, but it is also slow as hell.
And if it is slower than others lossless codecs in compression, it is also slower in decompression !

I am not surprised that x265 encoded slower too, you should try UTVideo instead.

[stax76]

The help output has one dash too much I think:

---hrd-concat Set HRD concatenation flag for the first keyframe in the buffering period SEI. Default disabled

[MeteorRain]

I tried make it .yuv raw from virtualdub2 using ffv1 lossless

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

[iAvoe]

I wish the next x265 update or build can get rid of piping files in. Something like a straight file input as x264 builds (I'm not sure why it's not working through so many years tho)

[benwaggoner]

I wish the next x265 update or build can get rid of piping files in. Something like a straight file input as x264 builds (I'm not sure why it's not working through so many years tho)
No one is making a build with ffmpeg integrated is why.

[qyot27]

*cough* (https://forum.doom9.org/showpost.php?p=1873612&postcount=6811). We're still on the same forum page.

LAVF input is only supported through patches. MCW more or less put the kibosh on the idea of it being in the upstream source a few years ago, IIRC. Something about not wanting to deal with the maintenance burden of input modules other than raw and y4m, as I recall.

I mean, I use the LAVF support patches for my personal builds of x265 CLI, but more often than not, I just use libx265 through FFmpeg, which is probably more what MCW expects people to do if they want all the exotic input file support.

[StvG]

Last time I tested avs input with this patch (https://github.com/qyot27/x265-Yuuki-Asuna/commit/28b1da7c97abb5ba5f53f751a9d7338eb8e68ee6) was quite slower than avs2yuv+x265.

[Blue_MiSfit]

+1 for just using ffmpeg :)

The only downside AFAICT is when you want to use qpfiles, this still requires piping. I'm sure there are other things too, but this is a big one

[stax76]

How do I use the patch?

x265.exe --crf 18 --output C:\out.hevc C:\test.avs

[avs2 @ 0000000002763500] Format avs2 detected only with low score of 1, misdetection possible!
[avs2 @ 0000000002763500] Could not find codec parameters for stream 0 (Video: avs2, none): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[NULL @ 0000000002747480] No codec provided to avcodec_open2()
[NULL @ 0000000002747480] No codec provided to avcodec_open2()
lavf [error]: could not find decoder for video stream
x265 [error]: unable to open input file <C:\Users\frank\Daten\Samples\test_temp\test.avs>

[qyot27]

+1 for just using ffmpeg :)

The only downside AFAICT is when you want to use qpfiles, this still requires piping. I'm sure there are other things too, but this is a big one
Do you mean zonefile? qpfile isn't marked with a CLI only disclaimer in the docs (https://x265.readthedocs.io/en/default/cli.html), so I'd assume it's usable through -x265-params. Most of the stuff marked as CLI only wouldn't be relevant to libx265 use anyway.

How do I use the patch?
Build the patched x265 source against an FFmpeg that has AviSynth support enabled first.

[qyot27]

Last time I tested avs input with this patch (https://github.com/qyot27/x265-Yuuki-Asuna/commit/28b1da7c97abb5ba5f53f751a9d7338eb8e68ee6) was quite slower than avs2yuv+x265.
Don't use 32-bit builds of x265 to encode high bit depth. They have no asm.

Proof:
J:\>x265 --preset ultrafast --crf 18 -o test-direct.mkv testavi.avs
lavf [info]:
Format : avisynth
Codec : rawvideo ( raw video )
PixFmt : yuv422p
Framerate : 24000/1001
Timebase : 1001/24000
Duration : 0:00:10
lavf [info]: 1920x1080 fps 24000/1001 i422p8 frames 0 - 239 of 240
x265 [info]: Using preset ultrafast & tune none
mkv [info]: output file: test-direct.mkv
x265 [info]: HEVC encoder version 2.9+2-7e978ed93d608697
x265 [info]: build info [Windows][GCC 8.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
x265 [info]: Main 4:2:2 10 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(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 16
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : dia / 57 / 0 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 0 / 5.00
x265 [info]: Lookahead / bframes / badapt : 5 / 3 / 0
x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0
x265 [info]: References / ref-limit cu / depth : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.60
x265 [info]: tools: rd=2 psy-rd=2.00 early-skip rskip tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock
x265 [info]: frame I: 1, Avg QP:22.97 kb/s: 119.50
x265 [info]: frame P: 60, Avg QP:22.41 kb/s: 5591.55
x265 [info]: frame B: 179, Avg QP:25.33 kb/s: 1784.29
x265 [info]: consecutive B-frames: 1.6% 0.0% 1.6% 96.7%

encoded 240 frames in 16.02s (14.99 fps), 2729.17 kb/s, Avg QP:24.59

J:\>avs2yuv testavi.avs -o - | x265 --y4m --preset ultrafast --crf 18 -o test-pipe.mkv -
testavi.avs: 1920x1080, 24000/1001 fps, 240 frames
converting input clip to YV12
y4m [info]: 1920x1080 fps 24000/1001 i420p8 unknown frame count
x265 [info]: Using preset ultrafast & tune none
mkv [info]: output file: test-pipe.mkv
x265 [info]: HEVC encoder version 2.9+2-7e978ed93d608697
x265 [info]: build info [Windows][GCC 8.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
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(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 16
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : dia / 57 / 0 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 0 / 5.00
x265 [info]: Lookahead / bframes / badapt : 5 / 3 / 0
x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0
x265 [info]: References / ref-limit cu / depth : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.60
x265 [info]: tools: rd=2 psy-rd=2.00 early-skip rskip tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock
x265 [info]: frame I: 1, Avg QP:22.97 kb/s: 116.81
x265 [info]: frame P: 60, Avg QP:22.44 kb/s: 4963.89
x265 [info]: frame B: 179, Avg QP:25.33 kb/s: 1607.71
x265 [info]: consecutive B-frames: 1.6% 0.0% 1.6% 96.7%

encoded 240 frames in 14.40s (16.67 fps), 2440.54 kb/s, Avg QP:24.60

J:\>

Summary:
Direct input of testavi.avs to 64-bit x265 with LAVF input: 14.99 fps
Piping from 32-bit avs2yuv bm2 to 64-bit x265: 16.67 fps

That's not 'quite slower', it's within the margin of error (especially considering the overhead of having the libav* libraries loaded in the x265 process). Re-running the test with the script converting to 4:2:0 before handing it to x265 or avs2yuv bm3 flipped the values around: direct use was faster than piping:

J:\>x265 --preset ultrafast --crf 18 -o testdirect.mkv testavi.avs
lavf [info]:
Format : avisynth
Codec : rawvideo ( raw video )
PixFmt : yuv420p
Framerate : 24000/1001
Timebase : 1001/24000
Duration : 0:00:10
lavf [info]: 1920x1080 fps 24000/1001 i420p8 frames 0 - 239 of 240
x265 [info]: Using preset ultrafast & tune none
mkv [info]: output file: testdirect.mkv
x265 [info]: HEVC encoder version 2.9+2-7e978ed93d608697
x265 [info]: build info [Windows][GCC 8.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
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(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 16
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : dia / 57 / 0 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 0 / 5.00
x265 [info]: Lookahead / bframes / badapt : 5 / 3 / 0
x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0
x265 [info]: References / ref-limit cu / depth : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.60
x265 [info]: tools: rd=2 psy-rd=2.00 early-skip rskip tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock
x265 [info]: frame I: 1, Avg QP:22.97 kb/s: 116.81
x265 [info]: frame P: 60, Avg QP:22.44 kb/s: 4963.89
x265 [info]: frame B: 179, Avg QP:25.33 kb/s: 1607.71
x265 [info]: consecutive B-frames: 1.6% 0.0% 1.6% 96.7%

encoded 240 frames in 14.11s (17.01 fps), 2440.54 kb/s, Avg QP:24.60

J:\>avs2yuv testavi.avs -o - | x265 --y4m --preset ultrafast --crf 18 -o testdirect.mkv -
testavi.avs: 1920x1080, 24000/1001 fps, 240 frames
y4m [info]: 1920x1080 fps 24000/1001 i420p8 unknown frame count
x265 [info]: Using preset ultrafast & tune none
mkv [info]: output file: testdirect.mkv
x265 [info]: HEVC encoder version 2.9+2-7e978ed93d608697
x265 [info]: build info [Windows][GCC 8.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
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(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 16
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : dia / 57 / 0 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 0 / 5.00
x265 [info]: Lookahead / bframes / badapt : 5 / 3 / 0
x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0
x265 [info]: References / ref-limit cu / depth : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.60
x265 [info]: tools: rd=2 psy-rd=2.00 early-skip rskip tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock
x265 [info]: frame I: 1, Avg QP:22.97 kb/s: 116.81
x265 [info]: frame P: 60, Avg QP:22.44 kb/s: 4963.89
x265 [info]: frame B: 179, Avg QP:25.33 kb/s: 1607.71
x265 [info]: consecutive B-frames: 1.6% 0.0% 1.6% 96.7%

encoded 240 frames in 14.35s (16.72 fps), 2440.54 kb/s, Avg QP:24.60

J:\>

Direct: 17.01 fps
Piped: 16.72 fps

The DJATOM fork of avs2yuv is, amusingly, only relevant for 64-bit tests. The 32-bit build would be comparing apples to oranges.

[StvG]

Never used 32-bit x265.
Try the latest version (https://github.com/MasterNobody/avs2yuv/releases). Also I don't pipe 32-bit avs to 64-bit x265. Using avs2yuv_x64 for 64-bit avs+ to 64-bit x265.

Edit:
Avs scriptffvideosource("4K.sample.mkv")
z_convertformat(width/2, height/2, resample_filter="spline36")
pipe - avs2yuv_x64 + x265avs2yuv_x64 -depth 10 1.avs -o - | x265.exe --y4m - --ctu 32 --preset ultrafast -o nul --pools 10 --frame-threads 2 > pipe.txt 2>&1

y4m [info]: 1920x1080 fps 24000/1001 i420p10 unknown frame count
raw [info]: output file: nul
x265 [info]: HEVC encoder version 3.0_Au+25-39b35ea86283
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 10 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 16
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : dia / 57 / 0 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 0 / 5.00
x265 [info]: Lookahead / bframes / badapt : 5 / 3 / 0
x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0
x265 [info]: References / ref-limit cu / depth : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60
x265 [info]: tools: rd=2 psy-rd=2.00 early-skip rskip tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock

x265 [info]: frame I: 18, Avg QP:30.77 kb/s: 3755.34
x265 [info]: frame P: 1084, Avg QP:32.66 kb/s: 714.73
x265 [info]: frame B: 3214, Avg QP:35.33 kb/s: 158.74
x265 [info]: consecutive B-frames: 1.5% 1.2% 1.4% 95.9%

encoded 4316 frames in 45.50s (94.85 fps), 313.38 kb/s, Avg QP:34.64
no pipex265.exe 1.avs --ctu 32 --preset ultrafast -o nul --pools 10 --frame-threads 2 > no_pipe.txt 2>&1

lavf [info]:
Format : avisynth
Codec : rawvideo ( raw video )
PixFmt : yuv420p10le
Framerate : 24000/1001
Timebase : 1001/24000
Duration : 0:03:00
lavf [info]: 1920x1080 fps 24000/1001 i420p10 frames 0 - 4315 of 4316
raw [info]: output file: nul
x265 [info]: HEVC encoder version 3.0_Au+25-39b35ea86283
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 10 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 16
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : dia / 57 / 0 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 0 / 5.00
x265 [info]: Lookahead / bframes / badapt : 5 / 3 / 0
x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0
x265 [info]: References / ref-limit cu / depth : 1 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60
x265 [info]: tools: rd=2 psy-rd=2.00 early-skip rskip tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock

x265 [info]: frame I: 18, Avg QP:30.77 kb/s: 3755.34
x265 [info]: frame P: 1084, Avg QP:32.66 kb/s: 714.73
x265 [info]: frame B: 3214, Avg QP:35.33 kb/s: 158.74
x265 [info]: consecutive B-frames: 1.5% 1.2% 1.4% 95.9%

encoded 4316 frames in 52.69s (81.91 fps), 313.38 kb/s, Avg QP:34.64

It's my bad that I wrote "quite slower", I should write just "slower", but I was surprised that the difference is >10%, I expected to be marginal within statistical error (~1%).

[qyot27]

Never used 32-bit x265.
Try the latest version (https://github.com/MasterNobody/avs2yuv/releases). Also I don't pipe 32-bit avs to 64-bit x265. Using avs2yuv_x64 for 64-bit avs+ to 64-bit x265.

Edit:
Avs scriptffvideosource("4K.sample.mkv")
z_convertformat(width/2, height/2, resample_filter="spline36")
pipe - avs2yuv_x64 + x265avs2yuv_x64 -depth 10 1.avs -o - | x265.exe --y4m - --ctu 32 --preset ultrafast -o nul --pools 10 --frame-threads 2 > pipe.txt 2>&1

y4m [info]: 1920x1080 fps 24000/1001 i420p10 unknown frame count
raw [info]: output file: nul
x265 [info]: HEVC encoder version 3.0_Au+25-39b35ea86283
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

...snip...

encoded 4316 frames in 45.50s (94.85 fps), 313.38 kb/s, Avg QP:34.64
no pipex265.exe 1.avs --ctu 32 --preset ultrafast -o nul --pools 10 --frame-threads 2 > no_pipe.txt 2>&1

lavf [info]:
Format : avisynth
Codec : rawvideo ( raw video )
PixFmt : yuv420p10le
Framerate : 24000/1001
Timebase : 1001/24000
Duration : 0:03:00
lavf [info]: 1920x1080 fps 24000/1001 i420p10 frames 0 - 4315 of 4316
raw [info]: output file: nul
x265 [info]: HEVC encoder version 3.0_Au+25-39b35ea86283
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

...snip...

encoded 4316 frames in 52.69s (81.91 fps), 313.38 kb/s, Avg QP:34.64

It's my bad that I wrote "quite slower", I should write just "slower", but I was surprised that the difference is >10%, I expected to be marginal within statistical error (~1%).
Using the same options and bm5 binary of avs2yuv, the x265 binary I built a week ago (rather than one from last October), a longer chunk of frames as a representative sample, and having moved all the relevant input files and avs2yuv binaries to my SSD rather than running it from a USB 3.0 flash drive:

Script:
FFVideoSource("test.mp4").ConvertBits(10)

Piped:
E:\>avs2yuv64 -depth 10 test.avs -o - | x265.exe --y4m - --ctu 32 --preset ultrafast --output-depth 10 -o nul --pools 10 --frame-threads 2 --frames 2400
test.avs: 1920x1080, YUV420P10, 10-bits, progressive, 24000/1001 fps, 31122 frames
y4m [info]: 1920x1080 fps 24000/1001 i420p10 unknown frame count
x265 [info]: Using preset ultrafast & tune none
raw [info]: output file: nul
x265 [info]: HEVC encoder version 3.0_Au+22-feec4bdf98663ac4
x265 [info]: build info [Windows][GCC 9.1.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

...snip...

encoded 2400 frames in 164.00s (14.63 fps), 1002.53 kb/s, Avg QP:34.62
error: wrote only 6096584 of 6220800 bytes

Direct:
E:\>x265.exe test.avs --ctu 32 --preset ultrafast --output-depth 10 -o nul --pools 10 --frame-threads 2 --frames 2400
lavf [info]:
Format : avisynth
Codec : rawvideo ( raw video )
PixFmt : yuv420p10le
Framerate : 24000/1001
Timebase : 1001/24000
Duration : 0:21:38
lavf [info]: 1920x1080 fps 24000/1001 i420p10 frames 0 - 2399 of 31122
x265 [info]: Using preset ultrafast & tune none
raw [info]: output file: nul
x265 [info]: HEVC encoder version 3.0_Au+22-feec4bdf98663ac4
x265 [info]: build info [Windows][GCC 9.1.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

...snip...

encoded 2400 frames in 160.87s (14.92 fps), 1002.53 kb/s, Avg QP:34.62

Piped: 14.63 fps
Direct: 14.92 fps

I even enabled MT (Prefetch(4)).

Piped:
E:\>avs2yuv64 -depth 10 test.avs -o - | x265.exe --y4m - --ctu 32 --preset ultrafast --output-depth 10 -o nul --pools 10
--frame-threads 2 --frames 2400
test.avs: 1920x1080, YUV420P10, 10-bits, progressive, 24000/1001 fps, 31122 frames
y4m [info]: 1920x1080 fps 24000/1001 i420p10 unknown frame count
x265 [info]: Using preset ultrafast & tune none
raw [info]: output file: nul
x265 [info]: HEVC encoder version 3.0_Au+22-feec4bdf98663ac4
x265 [info]: build info [Windows][GCC 9.1.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

...snip...

encoded 2400 frames in 172.52s (13.91 fps), 1002.53 kb/s, Avg QP:34.62
error: wrote only 6096584 of 6220800 bytes

Direct:
E:\>x265.exe test.avs --ctu 32 --preset ultrafast --output-depth 10 -o nul --pools 10 --frame-threads 2 --frames 2400
lavf [info]:
Format : avisynth
Codec : rawvideo ( raw video )
PixFmt : yuv420p10le
Framerate : 24000/1001
Timebase : 1001/24000
Duration : 0:21:38
lavf [info]: 1920x1080 fps 24000/1001 i420p10 frames 0 - 2399 of 31122
x265 [info]: Using preset ultrafast & tune none
raw [info]: output file: nul
x265 [info]: HEVC encoder version 3.0_Au+22-feec4bdf98663ac4
x265 [info]: build info [Windows][GCC 9.1.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

...snip...

encoded 2400 frames in 166.78s (14.39 fps), 1002.53 kb/s, Avg QP:34.62

[StvG]

Maybe bottleneck for you is x265 so the speed difference between direct and piped is killed?
Here is x265 I built for the test above (https://www.upload.ee/files/9972743/x265.7z.html).

Edit:
tested with crf 18
pipeavs2yuv_x64 -depth 10 1.avs -o - | x265.exe --y4m - --ctu 32 --preset ultrafast -o nul --pools 10 --crf 18 --frame-threads 2 > pipe.txt 2>&1

y4m [info]: 1920x1080 fps 24000/1001 i420p10 unknown frame count
raw [info]: output file: nul
x265 [info]: HEVC encoder version 3.0_Au+25-39b35ea86283
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

encoded 4316 frames in 50.39s (85.64 fps), 1629.90 kb/s, Avg QP:24.65
directx265.exe 1.avs --ctu 32 --preset ultrafast -o nul --pools 10 --crf 18 --frame-threads 2 > direct.txt 2>&1

lavf [info]:
Format : avisynth
Codec : rawvideo ( raw video )
PixFmt : yuv420p10le
Framerate : 24000/1001
Timebase : 1001/24000
Duration : 0:03:00
lavf [info]: 1920x1080 fps 24000/1001 i420p10 frames 0 - 4315 of 4316
raw [info]: output file: nul
x265 [info]: HEVC encoder version 3.0_Au+25-39b35ea86283
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

encoded 4316 frames in 55.19s (78.21 fps), 1629.90 kb/s, Avg QP:24.65
tested with crf 18 and asm sse4.2
pipeavs2yuv_x64 -depth 10 1.avs -o - | x265.exe --y4m - --ctu 32 --preset ultrafast -o nul --pools 10 --crf 18 --frame-threads 2 > pipe.txt 2>&1 --asm sse4.2

y4m [info]: 1920x1080 fps 24000/1001 i420p10 unknown frame count
raw [info]: output file: nul
x265 [info]: HEVC encoder version 3.0_Au+25-39b35ea86283
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

encoded 4316 frames in 58.54s (73.73 fps), 1629.90 kb/s, Avg QP:24.65
directx265.exe 1.avs --ctu 32 --preset ultrafast -o nul --pools 10 --crf 18 --frame-threads 2 > direct.txt 2>&1 --asm sse4.2

lavf [info]:
Format : avisynth
Codec : rawvideo ( raw video )
PixFmt : yuv420p10le
Framerate : 24000/1001
Timebase : 1001/24000
Duration : 0:03:00
lavf [info]: 1920x1080 fps 24000/1001 i420p10 frames 0 - 4315 of 4316
raw [info]: output file: nul
x265 [info]: HEVC encoder version 3.0_Au+25-39b35ea86283
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

encoded 4316 frames in 61.19s (70.53 fps), 1629.90 kb/s, Avg QP:24.65
tested real encoding scenario where bottleneck is x265
pipeavs2yuv_x64 -depth 10 1.avs -o - | x265.exe --y4m - --ctu 32 --preset slower --crf 18 -o nul --frame-threads 2 --no-amp --no-sao --no-strong-intra-smoothing > pipe.txt 2>&1 --asm avx512

y4m [info]: 1920x1080 fps 24000/1001 i420p10 unknown frame count
raw [info]: output file: nul
x265 [info]: HEVC encoder version 3.0_Au+25-39b35ea86283
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 AVX512

encoded 501 frames in 153.32s (3.27 fps), 10340.94 kb/s, Avg QP:22.84
directx265.exe 1.avs --ctu 32 --preset slower --crf 18 -o nul --frame-threads 2 --no-amp --no-sao --no-strong-intra-smoothing > direct.txt 2>&1 --asm avx512

lavf [info]:
Format : avisynth
Codec : rawvideo ( raw video )
PixFmt : yuv420p10le
Framerate : 24000/1001
Timebase : 1001/24000
Duration : 0:00:20
lavf [info]: 1920x1080 fps 24000/1001 i420p10 frames 0 - 500 of 501
raw [info]: output file: nul
x265 [info]: HEVC encoder version 3.0_Au+25-39b35ea86283
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 AVX512

encoded 501 frames in 153.33s (3.27 fps), 10340.94 kb/s, Avg QP:22.84

[qyot27]

Maybe bottleneck for you is x265 so the speed difference between direct and piped is killed?
On a Celeron J3455? Incredibly likely. The lack of AVX2 alone probably makes the biggest difference.

If you use FFmpeg with libx265, what fps does it pull? If it's close to the same speed as the LAVF input in x265, the difference is due to the way the libavformat AviSynth demuxer is written.

[StvG]

Almost the same speed as "direct"ffmpeg.exe -i 1.avs -c:v libx265 -preset ultrafast -x265-params ctu=32:pools=10:frame-threads=2 -f rawvideo - > x265.txt 2>&1

ffmpeg version 7211e1c Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 9.1.1 (GCC) 20190517
configuration: --enable-libx265 --enable-avisynth --extra-cflags='-march=core-avx2 -mtune=native -pipe -s -O2' --cpu=core-avx2 --disable-debug --enable-gpl --cross-prefix=x86_64-w64-mingw32- --target-os=mingw32 --arch=x86_64 --pkg-config-flags=--static --enable-zlib --disable-pthreads --enable-w32threads --enable-version3
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
Input #0, avisynth, from '1.avs':
Duration: 00:03:00.01, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le, 1920x1080, 23.98 fps, 23.98 tbr, 23.98 tbn, 23.98 tbc
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> hevc (libx265))
Press [q] to stop, [?] for help
x265 [info]: HEVC encoder version 3.0_Au+25-39b35ea86283
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

Output #0, rawvideo, to 'pipe:':
Metadata:
encoder : Lavf58.20.100
Stream #0:0: Video: hevc (libx265), yuv420p10le, 1920x1080, q=2-31, 23.98 fps, 23.98 tbn, 23.98 tbc
Metadata:
encoder : Lavc58.35.100 libx265

encoded 4316 frames in 52.01s (82.98 fps), 313.44 kb/s, Avg QP:34.64

[filler56789]

x265.exe 3.0_Au+25-39b35ea86283
(x64, multilib, GCC 7.4.0)

http://www.mediafire.com/file/ezp7c7s00c6j664/x265_3.0_Au%2B25-39b35ea86283.7z

[Barough]

x265 v3.0_Au+27-3f4fb9a2ac68 (https://www.mediafire.com/file/4q6krzl1n07dqem/x265-3.0_Au+27-3f4fb9a2ac68_Win_GCC.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit-GCC v7.4.0 / 64bit-GCC v8.3.0)

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

[Barough]

x265 v3.0_Au+30-b9bef1a4c34a (https://www.mediafire.com/file/bcwgvqq5fjs35cy/x265-3.0_Au+30-b9bef1a4c34a_Win_GCC.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit-GCC v7.4.0 / 64bit-GCC v8.3.0)

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

[Barough]

x265 v3.0_Au+31-4583000db964 (https://www.mediafire.com/file/ems39bb8ct5gsjr/x265-3.0_Au+31-4583000db964_Win_GCC.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit-GCC v7.4.0 / 64bit-GCC v8.3.0)

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

[stax76]

@Barough

Thanks for the new built. Is there a change log somewhere?

[Barough]

@Barough

Thanks for the new built. Is there a change log somewhere?

YW stax76 :)

You need 2 check the commits comments on the Bitbucket URL above. There is only a changelog available for the v3.0 Stable version.

[stax76]

@Barough

Thanks, I found it now.


@Wolfberry

avs input is still not working for me:

[avs2 @ 0000000004623380] Format avs2 detected only with low score of 1, misdetection possible!
[avs2 @ 0000000004623380] Could not find codec parameters for stream 0 (Video: avs2, none): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[NULL @ 0000000004635340] No codec provided to avcodec_open2()
[NULL @ 0000000004635340] No codec provided to avcodec_open2()
lavf [error]: could not find decoder for video stream
x265 [error]: unable to open input file <C:\Users\john&janedoe\Daten\Samples\test_temp\test.avs>

[Barough]

x265 v3.0_Au+32-a46ded2c1411 (https://www.mediafire.com/file/upisl3t05o71h0g/x265-3.0_Au+32-a46ded2c1411_Win_GCC.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit-GCC v7.4.0 / 64bit-GCC v8.3.0)

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

[benwaggoner]

Some interesting checkins in the last couple of weeks, with new parameters!

Has anyone played with the --fades command? As described, it sounds like a useful always-on feature to improve quality/efficiency of fades. x265 didn't seem to have a particular issue with those, but fades are a special case where efficiency and random access can be improved via the described mode.

[Wolfberry]

avs input is still not working for me

I did not build ffmpeg with avisynth support in that build.

Try this build (https://drive.google.com/open?id=1Ouvyj85LeV2yw0mYoz8SJgTb2ognaI7z)

x265 [info]: HEVC encoder version 3.0+2-b4b1d84566d7
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 8bit+10bit+12bit
x265 [info]: (libavcodec 58.52.102)
x265 [info]: (libavformat 58.27.103)
x265 [info]: (libavutil 56.28.100)
x265 [info]: (lsmash 2.16.1)

[stax76]

@Wolfberry

Works perfectly, awesome!

@everybody

There was a built that did show the estimated output file size and people have posted positive feedback about this feature, I like it too. Sadly I don't remember from where I got that built.

[vanden]

Sorry, I may not be in the right forum ...

Here is my problem, I have 2 rip bluray 2160p and the problem is that it must miss some info.

Blade Runner 2049:
Do not pass with "madMeasureDynamicClipping", I rename the file .measurements.incomplete in .measurements and I open it with "madMeasureDynamicClipping":
https://nsa40.casimages.com/img/2019/06/01/mini_190601120901821988.jpg (https://www.casimages.com/i/190601120901821988.jpg.html)
************** Texte de l'exception **************
System.OverflowException: The arithmetic operation caused an overflow.
à madMeasureDynamicClipping.FrmMain.ImportData()
à madMeasureDynamicClipping.FrmMain.StartAnalysis()
à System.Windows.Forms.Control.OnClick(EventArgs e)
à System.Windows.Forms.Button.OnClick(EventArgs e)
à System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
à System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
à System.Windows.Forms.Control.WndProc(Message& m)
à System.Windows.Forms.ButtonBase.WndProc(Message& m)
à System.Windows.Forms.Button.WndProc(Message& m)
à System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
**************
Reading it with "madMeasureDynamicClipping" I get this :
https://nsa40.casimages.com/img/2019/06/01/mini_190601120904919036.jpg (https://www.casimages.com/i/190601120904919036.jpg.html)
By removing all the .measurements.incomplete and .measurements files, I get this :
https://nsa40.casimages.com/img/2019/06/01/mini_190601120857262445.jpg (https://www.casimages.com/i/190601120857262445.jpg.html)
Pass in "Tone map HDR MadVR" :
https://nsa40.casimages.com/img/2019/06/01/mini_190601120623189391.jpg (https://www.casimages.com/i/190601120623189391.jpg.html)

Sully:
Do not pass with "madMeasureDynamicClipping" :
https://image.noelshack.com/minis/2019/22/4/1559206661-sully2.png (https://www.noelshack.com/2019-22-4-1559206661-sully2.jpg)
Pass in "Tone map HDR MadVR" :
https://nsa40.casimages.com/img/2019/06/01/mini_190601121906235835.jpg (https://www.casimages.com/i/190601121906235835.jpg.html)


Do you have a solution ?


T2 Trainspotting everything is ok :
Ok avec "madMeasureDynamicClipping" :
https://nsa40.casimages.com/img/2019/06/01/mini_19060112302966618.jpg (https://www.casimages.com/i/19060112302966618.jpg.html)
Reading it with "madMeasureDynamicClipping" I get this :
https://nsa40.casimages.com/img/2019/06/01/mini_190601121952878821.jpg (https://www.casimages.com/i/190601121952878821.jpg.html)
By removing all the .measurements files, I get this :
https://nsa40.casimages.com/img/2019/06/01/mini_190601123401283975.jpg (https://www.casimages.com/i/190601123401283975.jpg.html)
Pass in "Tone map HDR MadVR" :
https://nsa40.casimages.com/img/2019/06/01/mini_190601123539772152.jpg (https://www.casimages.com/i/190601123539772152.jpg.html)

[Wolfberry]

There was a built that did show the estimated output file size and people have posted positive feedback about this feature, I like it too. Sadly I don't remember from where I got that built.

The feature you are referring to is probably this commit: Cosmetic: x264-r2204 style progress indicator (https://github.com/msg7086/x265-Yuuki-Asuna/commit/daa22d26c2bd6a6a93e7f5107c00f62d964d4a4a)

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

[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 (https://www.mediafire.com/file/yddwwadpx8f859p/x265-3.1_RC1+1-10decf67c077_Win_GCC910.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)

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

[Natty]

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

[MeteorRain]

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

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]

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 :thanks:

[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/default/releasenotes.html#encoder-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.

Just saw this was mentioned already :D

[katzenjoghurt]

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/x265/issues/490/x265-crash-when-using-zone

[birdie]

Different settings affect the CRF output: https://x265.readthedocs.io/en/default/releasenotes.html#encoder-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 (https://www.mediafire.com/file/2y44i8i3hhybv76/x265-3.1_RC1+3-3bdf06e3c628_Win_GCC910.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)

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

[StvG]

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/x265/issues/490/x265-crash-when-using-zone

Use VS20xx not GCC x.x build from here (http://msystem.waw.pl/x265/).

[katzenjoghurt]

Hey StvG,

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

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