hevc/x265 encode broken on freebsd 13

[mueslo 17]

Unfortunately the experimental HEVC encode is not working properly. This results in the "no compatible streams" error when emby attempts to use HEVC. As far as I can tell there are no errors, but the issue is that the playlist files are not written fast enough and after 10s emby force-aborts ffmpeg.

During playback attempts (observed with multiple playback devices trying to use HEVC), Emby repeatedly starts short-lived HLS transcode sessions for the same item. Each session:

• Initializes a new ffmpeg transcode job
• Begins segment generation successfully (HLS .ts segments are created and written and files grow)
• Processes are then terminated externally by Emby (Stopping ffmpeg process with q command)
• and replaced by another identical ffmpeg process a few seconds later

x265 itself reports

x265 [info]: HEVC encoder version 4.1+1-1d117be
x265 [info]: build info [Unk-OS][clang 14.0.5][64 bit][noasm] 8bit
x265 [info]: using cpu capabilities: none!

So that explains why the transcoding is so slow (it's a 13 year old CPU). But there are no errors, the first stream just gives

[... SETUP ...]
23:37:46.224     Side data:
23:37:46.224       cpb: bitrate max/min/avg: 3872000/0/3872000 buffer size: 7744000 vbv_delay: N/A
23:37:46.224   Stream #0:1(kor): Audio: aac (LC), 48000 Hz, stereo, fltp, 128 kb/s (default)
23:37:46.224     Metadata:
23:37:46.224       encoder         : Lavc59.37.100 aac
23:37:46.225 subtitle input filter: decoding size 384x288
23:37:46.226 subtitle_kickoff: resend - pts: 292
23:37:46.226 subtitle_kickoff: call subtitle_resend_current 302 frame->format: 3
[... END OF SETUP ...]
>> ThrottleBySegmentRequest: Latest request position unknown
>> ThrottleBySegmentRequest: Latest request position unknown
>> ThrottleBySegmentRequest: Latest request position unknown
>> ThrottleBySegmentRequest: Latest request position unknown

When I disable experimental HEVC encode support, it switches back to x264, and everything works, and x264 reports:

23:43:11.257 [libx264 @ 0x850806400] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

So could it be that the main issue is that the x265 that is statically linked in emby's shipped ffmpeg is compiled with no optimizations causing timeouts?

Edited 59 minutes ago by mueslo