x264 error code 139

[MrVideo]

x264 core: 148 r2762 90a61ec
Win7-64

Anyone know what causes error code 139?

[LoRd_MuldeR]

https://forum.gleitz.info/images/smilies/seer_b.gif

Are you referring the x264 command-line program or the x264 encoder library? If you are referring to the command-line program, is "error code 139" the program's exit code?

Please post your log and/or tell use how exactly you got that number...

[MrVideo]

And where might the log file be? I see nothing in the full help where I can set a file name or location. I see where I'll have to change the log level. What level do you want?

The error is captured in my cygwin Z-shell script. The return x264 status code is checked. If not 0, then it spits out the value. I'm beginning to suspect that the AVS script that is feeding it is causing the issue. Most of the time I'll see errors like "cannot open AVS file." But this a first where I only get the exit status code.

[LoRd_MuldeR]

The x264 command-line encoder writes it logging outputs to the stderr stream.

Consequently, if you run x264.exe from the console (or via script), the log will appear directly in the console window – unless, of course, the output was redirected to a file via 2> operator.

If you run x264 via some GUI front-end, there should be a way to access the x264 log too. But it totally depends on the individual GUI...

BTW: The exit code is available via environment variable %ERRORLEVEL% in a Windows-style console or Batch script. And via $? in a Unix-style (Linux, MSYS, etc.) console or Shell script.

(Still it is not clear to me where exactly the number "139" came from)

[MrVideo]

OK. That makes sense with what I have seen in the past. It is all being run in a cygwin terminal.

I added --log-level "debug" to the x264 line and nothing. If I feed the video file directly to x264, no errors. I'm beginning to believe the LWLibavVideoSource function (LSMASHSource.dll) is not liking the video file. Normally when avisynth has an issue, x264 reports a problem with the script.

I normally see an "avs [info]" line show up as well as "x264 [info]" lines. Not this time around. Just the error status code of 139 being returned after x264 is started.

This is really strange.

[LoRd_MuldeR]

I normally see an "avs [info]" line show up as well as "x264 [info]" lines. Not this time around. Just the error status code of 139 being returned after x264 is started.

Please post your full x264 command-line that was used to trigger the problem. And the full x264 outputs (log) that results, or a screenshot of what you see...

[MrVideo]

Here ya go:

AVS Script:
LWLibavVideoSource("E:\\CW-H264-promos-170828-422-trim.ts")
ConvertToYV12(interlaced=true)
AssumeFPS(30000, 1001)
assumetff()
telecide(guide=1)
decimate()
Z-shell output (I manually line wrapped the x264 line):
+/home/Brown/bin/encodeH264.zsh:714> x264 --pass 1 --profile high --level 4.0 --bitrate 4000
--ref 4 --deblock 1:-1:-1 --me umh --subme 10 --psy-rd 1.00:0.15 --merange 24 --trellis 2
--deadzone-inter 21 --deadzone-intra 11 --fast-pskip --threads 12 --slices 4 --nr 0 --bframes 3
--b-pyramid strict --b-adapt 2 --b-bias 0 --direct auto --weightp 0 --keyint 24 --min-keyint 1 --scenecut 40
--rc-lookahead 60 --ratetol 1.0 --qcomp 0.60 --qpmin 10 --qpmax 51 --qpstep 4 --cplxblur 20.0 --qblur 0.5
--vbv-maxrate 8000 --vbv-bufsize 8000 --ipratio 1.40 --bluray-compat --open-gop --sar 1:1 --log-level debug
--qpfile 'E:\\CW-H264-promos-170828-422-trim_qpfile.txt' --stats 'E:\\CW-H264-promos-170828-422-trim.stats'
--output NUL 'E:\\CW-H264-promos-170828-422-trim.avs'
+/home/Brown/bin/encodeH264.zsh:728> STATUS=139
+/home/Brown/bin/encodeH264.zsh:729> [[ 139 -ne 0 ]]
+/home/Brown/bin/encodeH264.zsh:730> echo 'x264 pass 1 exited with error code 139.'
x264 pass 1 exited with error code 139.
+/home/Brown/bin/encodeH264.zsh:731> exit 1
I noticed that the two stat files are created, but are empty.

The LSMASH lwi file is also created and appears to contain the necessary info. At least the content is similar to one that is created with a file that it runs complete. That kinda means to me that the LWLibavVideoSource function worked, to a point anyway.

[LoRd_MuldeR]

So, even though you make it unnecessary difficult for us to guess, I'm going to assume that line 728 of your script actually reads something like STATUS=$? and therefore "139" simply is the exit code of the x264 process.

I don't think x264 CLI itself ever returns any other exit codes than either "0" (indicates success) or "-1" (indicates an error condition).

Therefore, if you ever get "strange" exit codes from the x264 process, this almost always means that x264 just has crashed and the exit code is actually an NTSTATUS (https://msdn.microsoft.com/en-us/library/cc704588.aspx) code from the Windows operating system, not from application code!

A very "popular" candidate is exit code -1073741819, which, when interpreted as an unsigned 32-Bit number, gives 0xC0000005, otherwise known as STATUS_ACCESS_VIOLATION ;)

Since you are using Avisynth input, your best bet is that Avisynth, or more likely one of the Avisynth plug-in's involved, has crashed. I suggest you try loading your AVS script in a separate "avs2yuv.exe" process and pipe that to x264...

[LoRd_MuldeR]

[Update]

Just realized/remembered that Unix-like systems will usually return 128 + signal_value as the exit code when a process terminates abnormally. Also note that 139 = 128 + 11 :sly:

And, furthermore, 11 is the numerical value of SIGSEV, otherwise known as Segmentation Violation. This eliminates any doubt that your x264 process has crashed, probably for the reasons pointed out in my previous post.

[MrVideo]

So, even though you make it unnecessary difficult for us to guess, I'm going to assume that line 728 of your script actually reads something like STATUS=$? and therefore "139" simply is the exit code of the x264 process.
Sorry, I figured it was easier to supply the actual output of the Z-shell script. If I had only supplied the actual code of that section, you would have seen several variables in the x264 line. This way all of the variable's values were shown.

But, you are correct about the STATUS line.

[MrVideo]

Just realized that Unix-like systems will usually return 128 + signal_value as the exit code when a process terminates abnormally. Also note that 139 = 128 + 11 :sly:
Ah. Thanks. I will have to remember that. I'm used to the actual signal value.
And, furthermore, 11 is the numerical value of SIGSEV, otherwise known as Segmentation Violation. This eliminates any doubt that your x264 process has crashed, probably for the reasons pointed out in my previous post.
Ya, SIGSEVs are not good.

Thanks for figuring this out. Time to investigate the cause.

[kypec]

Are you running this on AMD Ryzen CPU? Perhaps the infamous SEGFAULT issue kicked in then... Just a wild guess, I'm not a Linux expert.

[LoRd_MuldeR]

Well, in my experience, x264 crashes are caused by Avisynth (more specifically: by Avisynth plug-ins or certain Avisynth plug-in combinations) in 10 out of 10 cases. Provided you are using Avisynth input, of course ;)

And, indeed, I had cases where some old plugin DLL's lingering in the Avisynth "plugin" directory where causing mayhem, even when not referenced in the current AVS script at all...

[MrVideo]

Are you running this on AMD Ryzen CPU? Perhaps the infamous SEGFAULT issue kicked in then... Just a wild guess, I'm not a Linux expert.
AMD, but not that CPU. Actually running on Win7-64, but using cygwin in order to get the Linux tools I'm used to. Specifically being able to write scripts.

[MrVideo]

And, indeed, I had cases where some old plugin DLL's lingering in the Avisynth "plugin" directory where causing mayhem, even when not referenced in the current AVS script at all...
Using AVSMeter, I went thru my plugins directory and weeded out all of the DLL files that caused AVSMeter to crash. didn't fix this issue.

[LoRd_MuldeR]

Using AVSMeter, I went thru my plugins directory and weeded out all of the DLL files that caused AVSMeter to crash. didn't fix this issue.

As suggested before, you can try to replace:

x264.exe [options] --output output.mkv input.avs

...with something like this:

avs2yuv_x86.exe input.avs - | x264.exe [options] --output output.mkv --stdin y4m -

This will keep the Avisynth stuff completely outside of the x264 process.


Also, the conclusion "my (broken) Avisynth plug-in does not happen to crash when used in application A, but it does crash when used in application B, so it must be application B's fault" is wrong and misleading.

I suggest you completely remove everything from your Avisynth "plugin" directory, use a minimal script containing only the XYZSource() command, and load the plug-in DLL, if you need any, explicitly via LoadPlugin() and a full path.

Should this still crash, it is time to use another source filter! And, just to be sure, you should be using the latest official "stable" Avisynth (http://sourceforge.net/projects/avisynth2/), not one of the various mods, forks, unofficial builds or whatsoever...

[MrVideo]

See the following post: http://forum.doom9.org/showthread.php?p=1821045#post1821045

It explains what I've done in the end to get things going. The AVISynth is the official release. A posting further up shows the AVISynth info on both systems.

As a test, the only two plugins installed are Decode.dll (telecide and decimate functions) and LSMASHSource.dll. The crash still happens. I think I've hit a LSMASHSource bug with the video file I am using. Especially since the same file works perfectly with the older version of LSMASHSource for XP.

At this point in time I am considering this issue closed. I will consider the avs2yuv program when investigating the LSMASHSource issue further.

[Groucho2004]

See the following post: http://forum.doom9.org/showthread.php?p=1821045#post1821045

It explains what I've done in the end to get things going. The AVISynth is the official release. A posting further up shows the AVISynth info on both systems.The Avisynth info shows that you're using an older (Alpha or Beta, not sure) version of Avisynth on your XP64 box. However, it should not matter.