It appears media-libs/x264's configure script simply checks for vsx support with the compiler rather than with the CPU. This results in a libx264 binary being built with VSX extensions, which aren't valid for older PPC chips. Reproducible: Always Steps to Reproduce: 1. emerge x264 Actual Results: Illegal instruction Expected Results: Properly running encoder/decoder It might just be a matter of passing --disable-vsx to the configure script my default and switching on this flag. However, there may need to be additional patches to this code, as I don't think they've sufficiently tested a vanilla altivec machine with this in a while (it's still trying to use xxpermdi instructions in spite of vsx=no). I may end up submitting a patch upstream for this.
Still a problem with current media-libs/x264-0.0.20231114-r1. When encoding a video on my PowerMac G5 11,2 with "ffmpeg -i input.mkv -c:v libx264 -preset slow -crf 22 -c:a copy output.mkv" ffmpeg crashes with following dmesg: ffmpeg[64720]: illegal instruction (4) at 3fffa0c9163c nip 3fffa0c9163c lr 3fffa0c91938 code 1 in libx264.so.164[3fffa0c00000+16d000] ffmpeg[64720]: code: 811f0290 28080002 41811fbc 83bf00a8 2f9d0000 419e000c 39200001 913f03ac ffmpeg[64720]: code: 837f008c 2f9b0000 409e1fb0 c19f02a8 <f00004d0> dbc10100 dbe10108 ff8c0000 Nowadays there is a CPU_FLAGS_PPC but that does not seem to help. [ebuild R ] media-libs/x264-0.0.20231114-r1:0/164::gentoo USE="interlaced threads (-opencl) -static-libs" CPU_FLAGS_PPC="altivec" 0 KiB
Created attachment 898474 [details] build.log (ppc64, 0.0.20231114-r1)
Created attachment 898475 [details] emerge --info
The issue has already been reported upstream by Adam: https://code.videolan.org/videolan/x264/-/issues/26 The patch attached in the upstream issue applies but unfortunately does not work out. Running x264 still crashes with illegal instruction on my G5.
(In reply to ernsteiswuerfel from comment #4) > The issue has already been reported upstream by Adam: > https://code.videolan.org/videolan/x264/-/issues/26 > > The patch attached in the upstream issue applies but unfortunately does not > work out. Running x264 still crashes with illegal instruction on my G5. I'm fairly certain the fix had worked 3 years ago as I managed to encode an h264 video on the G5. It's possible with ffmpeg you are using x264 features I wasn't or more vsx code is getting compiled in. I might boot up the G5 this weekend and try to troubleshoot.
(In reply to Adam Stylinski from comment #5) > I'm fairly certain the fix had worked 3 years ago as I managed to encode an > h264 video on the G5. It's possible with ffmpeg you are using x264 features > I wasn't or more vsx code is getting compiled in. I might boot up the G5 > this weekend and try to troubleshoot. This would be very welcomed! I din't use much parameters, only "ffmpeg -i input.mkv -c:v libx264 -preset slow -crf 22 -c:a copy output.mkv" But I can try tomorrow without parameters and see whether that makes a difference.
This problem affects PPC32 as well (testing on PowerMac G4). The issue is that the x264 build system adds -mvsx to the compiler flags by default, which enables GCC to emit VSX instructions for ordinary C code. This obviously ends badly on these machines. The damage is clearly visible in the earlier attached build log. So in addition to the patch from the upstream bugtracker, it is also essential to pass --disable-vsx to configure, but unfortunately the x264 ebuild does not respect EXTRA_ECONF so you have to patch it (or the configure script) to achieve this.
