I think the issue might be that the version of FFmpeg Tools in the CoreELEC nightly addons Repo just hasn’t been built with the --enable-libx265 flag, or even the --enable-libx264 flag as that encoder also does not work.
This thread may be dead, but let me have some comments.
For me (someone who doesn’t really speak makefile and coreelec, and who just dropped in here seeking answers) #5 and #6 are better confusing than being an actual help. #5 suggests “libx264 disabled, x265 flag not present” and #6 says none of them is achievable for ARM… which conclusion may be true and also false.
So my point is that the replies don’t clearly answer the original question - if x264 and x265 are present, however a short and clear answer would have taken similar effort. Ah, and neither attempts answering “How do I go about fixing this.” either.
So, my best bets to resolve my problem (re-encoding Easter recordings) are these:
keep doing re-encoding on my ubuntu (which is of course a waste of my coreelec box)
try ffmpeg for entware (no x264/x265 support either)
experiment with docker + ubuntu + ffmpeg (has a learning curve for docker)
experiment with tailoring all the above configs to natively support x265 on ARM (most probably involves coreelec-builder, so pretty much an endless project)
Most ARM processors will simply choke when asked to transcode and this is why little attention has been applied to getting it working. You answered your own question - keep doing it with your ubuntu machine which presumably has an x86 chip.
@Shoog Thank you for your answer - x86 is indeed the solution. I’ll leave here some additional info for others walking in my shoes, and with that this case is closed from my side.
For the experiment, I’ve searched for docker images with ARM support; the first working match was linuxserver/ffmpeg:arm64v8-latest for my Amlogic S905x3 based box. It transcodes a short H.264 video to H.265 really really slow: 0.1fps, system load constantly beyond 4. I assume ffmpeg can’t show less than 0.1fps so the actual figures are even worse.
Amlogic devices have HW-based Decoder OR Encoder, but for transcoding you need both. Therefore it can only processed via SW, which gives poor results (even on x86 w/o GPU HW-support)