x265 pipe problem

[n808]

On macOS and Windows, if I pipe y4m from ffmpeg to x265, x265 runs around 4-5x slower than on Linux on the same system. If I instead use ffmpeg to decode to y4m and then run x265 as two separate steps, it runs at "full speed".

example command:
ffmpeg -loglevel verbose -y -i input.mp4 -r 30/1 -threads 4 -t 20.000000 -pix_fmt yuv420p -f yuv4mpegpipe - 2> "ffmpeg.log" | x265 --input - --y4m --input-depth=8 --keyint=60 --ref=3 --bframes=4 --profile=main --preset faster --crf 26 -o "video.hevc"

Windows and macOS on Intel Core i5:
piped: ~4-5fps (top shows ~130% x265 cpu usage)
Linux VM on same system:
+20fps

Run as separate ffmpeg, then x265 on same macOS:
+20fps (top shows ~+350% x265 cpu usage)

Separate commands:
ffmpeg -loglevel verbose -y -i input.mp4 -r 30/1 -threads 4 -t 20.000000 -pix_fmt yuv420p -f yuv4mpegpipe out.y4m
x265 --input out.y4m --y4m --input-depth=8 --keyint=60 --ref=3 --bframes=4 --profile=main --preset faster --crf 26 -o "video.hevc"

Other examples that run way too slow (4-5fps) :
cat out.y4m | x265 --input - --y4m --input-depth=8 --keyint=60 --ref=3 --bframes=4 --profile=main --preset faster --crf 26 -o "video.mkv"
cat out.yuv | x265 --input - --input-res 1920x1080 --fps 30 --input-depth=8 --keyint=60 --ref=3 --bframes=4 --profile=main --preset faster --crf 26 -o "video.mkv"

Any ideas what I should be doing differently to get the piped version to run at full speed?

EDIT: problem solved - bug in x265, patch found on this page (https://bitbucket.org/multicoreware/x265/issues/341).

[Weyoun]

Looks like a core/thread usage issue.

[Weyoun]

Where did your binaries come from?

[n808]

@Weyoun: tried both self-built and pre-built from MacPorts, but in any case, that was not the problem. I have run into a similar problem with x264 in the past, but it was fixed sometime around 1.5 years ago. It turns out x265 must still have the same(?) bug. A colleague found this patch from almost a year ago that apparently has not made it into the x265 code base. It completely resolves the problem, both for raw YUV and Y4M piped inputs to x265. Highly recommended for anyone needing piped input to work for macOS and Windows.
https://bitbucket.org/multicoreware/x265/issues/341

[Ma]

[...] A colleague found this patch from almost a year ago that apparently has not made it into the x265 code base. It completely resolves the problem, both for raw YUV and Y4M piped inputs to x265.

It's my fault that it is so long, sorry for that.

New patch that applies cleanly to current tip and should resolve the problem -- 19379 (https://patches.videolan.org/patch/19379/).

There is one difference from previous patch -- in y4m input there was 3 reads per frame (fread 'FRAME', fgetc '\n', fread 'raw data'), now there are only 2 (fread 'FRAME\n', fread 'raw data').

Could you check if it works on your system and report back?

[n808]

Sorry for the delay - I will test this out tomorrow local time.

[n808]

Updated patch verified working as well as the previous. Looking forward to this getting into the main codebase, if that is indeed the plan..?

[Ma]

It's already committed as ver. 2.6+31 3712d13 (https://bitbucket.org/multicoreware/x265/commits/3712d13c09bf3b9db105c7f97188bcc11b8f83cd)
Thanks for confirmation!