01.03.2024, 22:52
I tested vsPipe with "y4m"
Now the speed decrease to 6.24 fps.
So to speed-up the encoding is not the pipe but the "raw" format.
An increase of speed of 1.9x is worth your attention.
You should consider to abandon the "y4m" format for vsPipe and switch to "raw" format, please check if you obtain the same increase in speed.
Thanks,
Dan
D:\PProjects\vs-deoldify_dev>set NUMEXPR_MAX_THREADS=10
D:\PProjects\vs-deoldify_dev>"D:\Programs\Hybrid\64bit\Vapoursynth\vspipe.exe" "D:\PProjects\vs-deoldify_dev\encoding.vpy" - -c y4m | "D:\Programs\Hybrid\64bit\x265.exe" --preset fast --input - --fps 24000/1001 --output-depth 10 --y4m --profile main10 --b-adapt 2 --crf 21.00 --psy-rd 2.00 --deblock=-1:-1 --psnr --ssim --range limited --sar 1:1 --output "D:\PProjects\vs-deoldify_dev\VideoTest1_720p.265"
y4m [info]: 1280x692 fps 24000/1001 i420p10 sar 1:1 unknown frame count
raw [info]: output file: D:\PProjects\vs-deoldify_dev\VideoTest1_720p.265
x265 [info]: HEVC encoder version 3.5+115-88fd6d3ad
x265 [info]: build info [Windows][GCC 13.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: --psnr used with psy on: results will be invalid!
x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x265 [info]: Main 10 profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 20 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(11 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut / bias : 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 15 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-21.0 / 0.60
x265 [info]: tools: rd=2 psy-rd=2.00 rskip mode=1 signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock(tC=-1:B=-1) sao
Output 2594 frames in 415.95 seconds (6.24 fps)
x265 [info]: frame I: 14, Avg QP:19.85 kb/s: 8718.74 PSNR Mean: Y:48.786 U:51.412 V:51.627 SSIM Mean: 0.991435 (20.673dB)
x265 [info]: frame P: 663, Avg QP:20.24 kb/s: 3345.85 PSNR Mean: Y:48.327 U:50.204 V:50.376 SSIM Mean: 0.991880 (20.904dB)
x265 [info]: frame B: 1917, Avg QP:25.28 kb/s: 653.67 PSNR Mean: Y:47.784 U:48.858 V:48.975 SSIM Mean: 0.991540 (20.726dB)
x265 [info]: Weighted P-Frames: Y:11.3% UV:10.4%
encoded 2594 frames in 415.78s (6.24 fps), 1385.29 kb/s, Avg QP:23.96, Global PSNR: 48.267, SSIM Mean Y: 0.9916264 (20.771 dB)
Now the speed decrease to 6.24 fps.
So to speed-up the encoding is not the pipe but the "raw" format.
An increase of speed of 1.9x is worth your attention.
You should consider to abandon the "y4m" format for vsPipe and switch to "raw" format, please check if you obtain the same increase in speed.
Thanks,
Dan