0

While using ffmpeg 4.2 to transcode some files into h265 I get the below error repeatedly. I've tried two different operating systems with the same result.

[84364.574137] ffmpeg[2257282]: segfault at 0 ip 00007f4f0629d440 sp 00007f4e0f7fd020 error 4 in libx265.so.179[7f4f0623b000+116f000]
[84364.593586] Code: 85 75 0c 00 00 85 c0 0f 85 7b 03 00 00 48 8b 43 08 f2 0f 10 83 58 01 00 00 4c 8b 80 98 00 00 00 4c 8b 48 10 8b 80 e8 08 00 00 <49> 8b 08 49 8b 31 48 8b 39 48 8b 16 f2 0f 10 9e c0 05 00 00 f2 0f
[89693.205703] ffmpeg[2349621]: segfault at 0 ip 00007fdc4116b440 sp 00007fdbd1d6f020 error 4 in libx265.so.179[7fdc41109000+116f000]
[89693.225147] Code: 85 75 0c 00 00 85 c0 0f 85 7b 03 00 00 48 8b 43 08 f2 0f 10 83 58 01 00 00 4c 8b 80 98 00 00 00 4c 8b 48 10 8b 80 e8 08 00 00 <49> 8b 08 49 8b 31 48 8b 39 48 8b 16 f2 0f 10 9e c0 05 00 00 f2 0f
[90604.112280] ffmpeg[2388193]: segfault at 0 ip 00007f41326b3440 sp 00007f40a15a6020 error 4 in libx265.so.179[7f4132651000+116f000]
[90604.131793] Code: 85 75 0c 00 00 85 c0 0f 85 7b 03 00 00 48 8b 43 08 f2 0f 10 83 58 01 00 00 4c 8b 80 98 00 00 00 4c 8b 48 10 8b 80 e8 08 00 00 <49> 8b 08 49 8b 31 48 8b 39 48 8b 16 f2 0f 10 9e c0 05 00 00 f2 0f
[95462.996431] ffmpeg[2477426]: segfault at 0 ip 00007f43d7eef440 sp 00007f430fffe020 error 4 in libx265.so.179[7f43d7e8d000+116f000]
[95463.015906] Code: 85 75 0c 00 00 85 c0 0f 85 7b 03 00 00 48 8b 43 08 f2 0f 10 83 58 01 00 00 4c 8b 80 98 00 00 00 4c 8b 48 10 8b 80 e8 08 00 00 <49> 8b 08 49 8b 31 48 8b 39 48 8b 16 f2 0f 10 9e c0 05 00 00 f2 0f

It may be related to the hardware I'm running (threadripper 1950x) as it doesn't seem to be happening on my xeon however reading online most answers suggest it's a software related issue to do with unreferenced pointers, memory leaks or similar.

The memory I've got has passed multiple hours of memory tests also.

Can anyone suggest how I might get to the bottom of this?

5
  • 1
    Show your command and the complete log. If a certain input is needed to duplicate this issue provide a link if possible.
    – llogan
    May 16, 2021 at 18:42
  • ffmpeg -i input.mp4 output.mkv -map 0:a -c:v libx265 -x265-params crf=23:bframes=8 -preset medium -metadata:s:v:0 -c:a copy -c:s copy
    – Marshalleq
    May 26, 2021 at 9:27
  • Figuring out how to get the logs because this is ffmpeg inside an application - haven't managed yet.
    – Marshalleq
    May 26, 2021 at 9:31
  • ffmpeg -i input.mp4 output.mkv 2> ff.log or ffmpeg -report -i input.mp4 output.mkv and look for a file like ffmpeg-20210526-075601.log.
    – llogan
    May 26, 2021 at 15:56
  • Your command should be giving you an error: Unable to find a suitable output format for 'copy'. copy: Invalid argument. Option placement matters: ffmpeg [input options] input [output options] output
    – llogan
    May 26, 2021 at 15:58

1 Answer 1

0

Not a great solution maybe, but I boot my system now with "nosmt" (there's several ways to use files in /sys/ to turn SMT on and off too, if you prefer to do that.). Without this, I got intermittent crashes almost identical to yours, with nosmt no crashes, and a small increase in ffmpeg performance to boot.

(One of the crashes from a few months ago:)

[24432.479772] ffmpeg[93060]: segfault at 0 ip 00007f9ab50763a0 sp 00007f9a6e7fafa0 error 4 in libx265.so.179[7f9ab4b80000+e98000]
[24432.479792] Code: 85 8d 0c 00 00 85 c0 0f 85 7b 03 00 00 48 8b 43 08 f2 0f 10 83 58 01 00 00 4c 8b 80 98 00 00 00 4c 8b 48 10 8b 80 e8 08 00 00 <49> 8b 08 49 8b 31 48 8b 39 48 8b 16 f2 0f 10 9e c0 05 00 00 f2 0f

(I'm now running some newer ffmpeg version with libx265.so.199 and still had the same crashes last time I tested smt out about a week ago.)

So I suspect either some CPU flaw (which I doubt since when I've had SMT on I haven't had other stuff including stress tests crash). Or, that libx265 has some race condition (in other words, the smt threads run too unevenly, the thread that's crashing finishes "too early" and doesn't wait for whatever data it's trying to use to be ready.)

4
  • HI thanks very much for this, I've lately confirmed that this is happening quite a lot - in that many of the queued encodes in the vicinity of 10-20% fail with little explanation part way through, but re-queueing them they work, along with a different set of 10-20% failure. I'd love to leave SMT on - is there anything else you tried and ruled out as ineffective? Like e.g aspm=off? Thanks.
    – Marshalleq
    Nov 25, 2021 at 17:34
  • So I disabled SMT (in the BIOS) for a bit, but it lost 25% performance. Interestingly forcing it to enabled crashes the system and leaving at auto is fine. Sometimes I really wonder what goes on with the quality control on these motherboards. I did also see this happening on my Xeon also which seems to point to software related issue rather than hardware. What's your CPU?
    – Marshalleq
    Nov 25, 2021 at 19:28
  • Yeah, I'd say my failure rate was roughly 10-20% too. I wonder what SMT "auto' does, how it can decide whether to enable it or not? Weird. Well, the one thing I didn't look into but could be useful is to use taskset, you could leave SMT on but use taskset to force ffmpeg to only use "real" cores (this sets what's called CPU affinity. Some people in WIndows use CPU affinity utilities to keep each copy of ffmpeg within the same CCX (CPU Core complex) on the theory it helps with on-chip caching and memory traffic.).
    – hwertz
    Nov 26, 2021 at 20:36
  • Yeah, I'm now just starting to wonder - I used to do something similar. I used to run ffmpeg in Unraid and limit each one to 4 cores / 8 threads (I have AMD 1950X so that means 4 of those). I'm trying to remember if there was these errors then. Perhaps I'll spin up unraid again. Certainly there is a fair amount of evidence to show that ffmpeg produces a better quality result with less cores - so this could be good too. I'll give that a spin we I get some time and report back.
    – Marshalleq
    Nov 27, 2021 at 23:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .