search

DJATOM / x265-aMod

DJATOM's mod for x265 encoder
GNU General Public License v2.0
84 stars 10 forks source link

At the end of encoding, error is returned with exit code: -1073740940 (0xC0000374) (in StaxRip) #4

Closed JJKylee closed 3 years ago

JJKylee commented 3 years ago

[System Environment] Windows : Windows 10 Home x64 19042.746 CPU : Intel(R) Core(TM) i5-7300HQ CPU @ 2.50GHz

Hi,

I deployed the most recent release x265-x64-v3.4+55-aMod-gcc10.2.1+opt.7z(x265-x64-v3.4+55-aMod-gcc10.2.1.exe) to be called from StaxRip 2.1.7.1 Beta, and I encounter the following error message at the end of encoding.

------------------------ Error Video encoding ------------------------
Video encoding returned error exit code: -1073740940 (0xC0000374)
It's unclear what the exit code means, in case it's a COM error then it possibly means:
HRESULT where exception occurred: 0xC0000374

The command was as follows (with [...] being the abbreviation for the path):

[...]\x265.exe --crf 18 --output-depth 10 --hist-threshold 0.01 --output [...]\test_1audio_new_out.hevc [...]\test_1audio_new.vpy

(x265 took vpy as a direct input.)

And the vpy file was as follows:

import os, sys
import vapoursynth as vs
core = vs.get_core()

sys.path.append(r"[...]\VS\Scripts")
core.std.LoadPlugin(r"[...]\ffms2.dll", altsearchpath=True)
clip = core.ffms2.Source(r"[...]\test_1audio.mkv", cachefile=r"[...]\test_1audio_temp\temp.ffindex")
clip.set_output()

During the whole process, I couldn't observe any memory leak (albeit casually).

What could be the cause?

(BTW, can you please support 8-bit and 12-bit encoding as well? 😄)

ADDED:

  1. I ran the same command on CMD, but hevc itself encodes successfully.
  2. For comparison, I called @Patman86's most recent x265 build x265M-test_seek_avs_and_vpy.zip from within StaxRip 2.1.7.1 Beta, and had no problems unlike your build.

Well, is this an issue with StaxRip? Since I don't have in-depth knowledge regarding this matter, I can't figure out. Can you please take a look?

Update:

I think I figured out the cause: it was UPXing. (ver 3.96) I tried un-UPXing x265-x64-v3.4+55-aMod-gcc10.2.1.exe and the problem is gone. But if I re-UPX it, the same error occurs in StaxRip.

Is issuing different exit codes (uncompressed vs UPXed) normal usually? If so, maybe this is to taken care of by StaxRip.

But considering that StaxRip has not experienced this kind of issues so far with UPXed binaries (your previous binaries and @Patman86's many binaries including the above mentioned x265 in x265M-test_seek_avs_and_vpy.zip, ffmpeg, MP4Box, aomenc, etc.) I'm pretty much suspicious that there's something with x265-x64-v3.4+55-aMod-gcc10.2.1.exe.

DJATOM commented 3 years ago

I'll make unstripped binary soon, since it might be an issue with strip and upx (upx bug?)

DJATOM commented 3 years ago

Could you retest with this? Still stripped, and I didn't managed to trigger a bug.

x265-x64-v3.4+55-aMod-gcc10.2.1-retcode.exe.zip

DJATOM commented 3 years ago

I'll also leave unstripped UPXed build here, since I can't wait for results right now, have to do my working stuff. Please report your findings. x265-x64-v3.4+55-aMod-gcc10.2.1-retcode-nostrip.exe.zip

JJKylee commented 3 years ago

Unfortunately, both have the same error under the same condition (direct vpy input from StaxRip 2.1.7.1).

Video encoding returned error exit code: -1073740940 (0xC0000374)

Now, this time they both yield the same error even if they're un-UPXed unlike the original version x265-x64-v3.4+55-aMod-gcc10.2.1+opt.zip. 😢

Like I said before, the target hevc file is produced in any case regardless of the StaxRip error message. 😓

DJATOM commented 3 years ago

Weird enough. I'm using doodle1 branch of VS, no issues on my side. Will try master branch as portable later. If you can, make a set of staxrip and required apps to help me reproduce on my side.

DJATOM commented 3 years ago

(BTW, can you please support 8-bit and 12-bit encoding as well? 😄)

Maybe I'll build it only for no-opt... Consider me waiting near 1 hour to compile 8x3 builds of x265. Insane!

JJKylee commented 3 years ago

If you can, make a set of staxrip and required apps to help me reproduce on my side.

The StaxRip release (StaxRip-x64-2.1.7.1-Beta.7z) I used for the test is on @stax76's Dropbox archive.

The shipped x265 build(M-3.4+28 gcc10.2.0 Yuuki-Asuna/msg7086/DJATOM/Patman) does not have this issue. I just replaced the x265 binary with yours for the test and then the error pops up. (No other settings are tweaked at all. Just changed the filter type from AviSynth(default) to VapourSynth in testing.)

Like I said, the hevc file itself is output, but I cannot proceed with muxing because of the error.

Now, this time they both yield the same error even if they're un-UPXed unlike the original version x265-x64-v3.4+55-aMod-gcc10.2.1+opt.zip. 😢

I was wrong. The original version x265-x64-v3.4+55-aMod-gcc10.2.1+opt.zip also pops up the same error even if it's un-UPXed. (Maybe I was confused with another build.) Sorry about the confusion. 😓

So, as of now, only your latest builds have this exit code -1073740940 (0xC0000374) issue regardless of UPXing.

Maybe I'll build it only for no-opt... Consider me waiting near 1 hour to compile 8x3 builds of x265. Insane!

Totally agreed. 😆

Anyway, thanks for looking into this problem. 😃

DJATOM commented 3 years ago

So far managed to reproduce. Vanilla Vapoursynth causes heap corruption while doodle1 branch works fine. I'll debug that with Vanilla VS, this is definitely no good.

DJATOM commented 3 years ago

Further debugging helped to find the culprit. Heap corrupts on possible double delete. Will post a fix in few hours.

DJATOM commented 3 years ago

New binaries landed into releases section.

JJKylee commented 3 years ago

I just tested, and the error is gone now. Thanks a million. 😄