Possible typo Crashing Temporal filter.

[Wisperer]

Memory isn't the issue. I have 32 gb if RAM and hybrid/Vapoursynth was only using about 16gb if it. I had a good 10 gb left to spare.
I know it's the debug build though. I dropped back to the latest normal release and tried it without the Temporal filter and it worked like it should.
I'll drop the full log later.

And the script works fine. As does preview.

[Selur]

Create the debug output with the dev build not the old build.

Cu Selur

[Wisperer]

Alright sorry about the response time. Had some thins Come up I had to do.

Here is a fresh log. From start up to crash. Same settings I've been using this entire time. Had to Zip it since it was too large to upload as a txt file.

I will say something I noticed. The encode quality with the same settings in the dev build is noticeably better and averages about 30% faster. if we can get this figured out I'll be really happy. 
I was able to pull the RAW encode stream from my /tmp/ drive. on Arch Linux by default that is a RAM Drive.

[Selur]

okay source is 47052 frames according to MediaInfo, decoder seems to always crash after frame 37551.
The Vapoursynth script  /tmp/encodingTempSynthSkript_2020-12-26@15_35_04_8710.vpy

# Imports
import os
import sys
import functools
import vapoursynth as vs
core = vs.get_core()
# Import scripts folder
scriptPath = '/home/fletcher/Downloads/hybrid-dev/vsscripts'
sys.path.append(os.path.abspath(scriptPath))
# Loading Plugins
core.std.LoadPlugin(path="/home/fletcher/.hybrid/vsplugins/libaddgrain.so")
core.std.LoadPlugin(path="/home/fletcher/.hybrid/vsplugins/libneofft3d.so")
core.std.LoadPlugin(path="/home/fletcher/.hybrid/vsplugins/libdfttest.so")
core.std.LoadPlugin(path="/home/fletcher/.hybrid/vsplugins/libeedi3m.so")
core.std.LoadPlugin(path="/home/fletcher/.hybrid/vsplugins/vsznedi3.so")
core.std.LoadPlugin(path="/home/fletcher/.hybrid/vsplugins/libmvtools.so")
core.std.LoadPlugin(path="/home/fletcher/.hybrid/vsplugins/libtemporalsoften.so")
core.std.LoadPlugin(path="/home/fletcher/.hybrid/vsplugins/libscenechange.so")
core.std.LoadPlugin(path="/home/fletcher/.hybrid/vsplugins/libfmtconv.so")
core.std.LoadPlugin(path="/home/fletcher/.hybrid/vsplugins/libvslsmashsource.so")
# Import scripts
import havsfunc
# source: '/home/fletcher/Documents/Kanokon BD 1/Kanokon 2.mkv'
# current color space: YUV420P8, bit depth: 8, resolution: 1920x1080, fps: 29.97, color matrix: 709, yuv luminance scale: limited, scanorder: top field first
# Loading /home/fletcher/Documents/Kanokon BD 1/Kanokon 2.mkv using LWLibavSource
clip = core.lsmas.LWLibavSource(source="/home/fletcher/Documents/Kanokon BD 1/Kanokon 2.mkv", format="YUV420P8", cache=0, prefer_hw=0)
# making sure input color matrix is set as 709
clip = core.resize.Point(clip, matrix_in_s="709",range_s="limited")
# making sure frame rate is set to 29.970
clip = core.std.AssumeFPS(clip=clip, fpsnum=30000, fpsden=1001)
# Setting color range to TV (limited) range.
clip = core.std.SetFrameProp(clip=clip, prop="_ColorRange", intval=1)
clip2clip = clip
clip2clip = havsfunc.QTGMC(Input=clip2clip, Preset="Very Slow", TFF=False,FPSDivisor=2)
clip = core.vivtc.VFM(clip=clip, order=0, mode=1)
# VDecimate helper function
def postprocess(n, f, clip, deinterlaced):
  if f.props['_Combed'] > 0:
    return deinterlaced
  else:
    return clip
postprocessed_clip = core.std.FrameEval(clip=clip, eval=functools.partial(postprocess, clip=clip, deinterlaced=clip2clip), prop_src=clip)
clip = core.vivtc.VDecimate(clip=clip, scthresh=12)# new fps: 23.976
clip = havsfunc.Vinverse(clp=clip)
# adjusting output color from: YUV420P8 to YUV420P10 for x264Model (i420@8)
clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P10, range_s="limited")
# set output frame rate to 23.976fps
clip = core.std.AssumeFPS(clip=clip, fpsnum=24000, fpsden=1001)
# Output
clip.set_output()

looks fine.
The quant file "/tmp/Kanokon 2_new_new_2020-12-26@15_35_04_8710_03.qp"

1 I -1
312 I -1
2615 I -1
13596 I -1
35365 I -1
37618 I -1

looks fine too.

The encoding call:

"/usr/bin/vspipe" "/tmp/encodingTempSynthSkript_2020-12-26@15_35_04_8710.vpy" - --y4m | "/usr/bin/x264" --crf 16.00 --profile high10 --level 4.1 --ref 4 --bframes 5 --b-adapt 2 --sync-lookahead 17 --qpmax 63 --me umh --vbv-maxrate 150000 --vbv-bufsize 187500 --sar 1:1 --qpfile "/tmp/Kanokon 2_new_new_2020-12-26@15_35_04_8710_03.qp" --non-deterministic --range tv --colormatrix bt709 --demuxer y4m  --input-range tv --fps 24000/1001 --output-depth 10 --output "/tmp/2020-12-26@15_35_04_8710_04.264" -

also seems to be fine too and does start without a problem.

Since the decoding seems to always crash after the same frame I guess there might be an issue with:
a. the source -> check if the Vapoursynth Preview properly works around frame 37551
b. the decoding -> try whether calling:

"/usr/bin/vspipe" -p "/tmp/encodingTempSynthSkript_2020-12-26@15_35_04_8710.vpy" /dev/null --y4m

runs through the whole file or whether it too crashes after frame 37551. (output should be 37618 frames so the clip shouldn't be finished)
I suspect it crashes since Hybrid reports that the decoder and not the encoder crashed.

If the Vapoursynth Preview also crashes, try whether it still crashes if:
a. you use enable hardware decoding, in case your system supports it (set "Filtering->Vapoursynth->Misc->Source->Libav hardware decoding mode" to 3)
b. if you disable "Filtering->Vapoursynth->Misc->Source->Prefer LWLibAVSource over FFMpegSource"

If neither the Vapoursynth Preview nor the decoding of the script fails, try whether calling the encoding call in a terminal does throw an error the debug output didn't get.

Had to Zip it since it was too large to upload as a txt file.

Man, no offense, but I really don't get why folks want to attach huge txt files, when the 'sticky' clearly states:
[quote]5. compress (zip/7z/rar/..) the HybridDebugOutput.txt before you post it[/code]

Cu Selur

Ps.: RAM Drive doesn't really help much in regard to encoding, it usually only helps when muxing and extracting content from and to it.

[Wisperer]

So yeah the decoder crashes with a seg fault. But oddly it reports all frames processed.
VS preview played through the entire clip with no issue.
And using a VPY created by the last stable release it doesn't segfault.

fletcher@fletcher-desktop: ~ $ /usr/bin/vspipe -p "/tmp/encodingTempSynthSkript_2020-12-26@15_35_04_8710.vpy" /dev/null --y4m

Output 37642 frames in 503.22 seconds (74.80 fps)
Segmentation fault (core dumped)

[Selur]

So yeah the decoder crashes with a seg fault.

which is why Hybrid aborts

And using a VPY created by the last stable release it doesn't segfault.

With the same source?
Does the script differ? (don't think I changed anything related to Vapoursynth that should change the script I saw)

-> Try to
a. you use enable hardware decoding, in case your system supports it (set "Filtering->Vapoursynth->Misc->Source->Libav hardware decoding mode" to 3)
if that doesn't help try to
b. disable "Filtering->Vapoursynth->Misc->Source->Prefer LWLibAVSource over FFMpegSource"

Cu Selur

[Wisperer]

Here is a image illustrating some of the differences.....

and changing the Hardware decoding to 3 changed nothing. Disabling LWLibAVSource just crashes the decoder immedeatly.

I attached the two generated temp Scripts. t1 is the old stable build. t2 is the test dev build. ! created both using the same settings.

[Selur]

Okay, what really confuses me is that as I understood it so far is that the preview of both of these worked.

About the differences:
t2: has 'import functools' which is needed for a change in how ivtc is done (http://www.vapoursynth.com/doc/plugins/vivtc.html). Hybrid did it incorrectly before which caused the output to sometimes still have combing.
t1 vs t2: changed the libneo-fft3d.so calls according to your complain to libneofft3d
t1 vs t2: "scriptPath" changed due different location of the versions
t1 vs t2: I don't see the difference in the loading source loading line -> okay looking at the scripts its the prefer_hw value
t1 vs t2: I don't see the difference in the AssumeFPS-line -> okay, I see it's clip vs. clip=clip (both should work fine)
t1 vs t2: I don't see the difference in the 'clip2clip = clip'-line (okay the spacing)
I understand the different IVTC handling, but that code should not cause a problem.

Only real difference that is the is the scthresh-value in the VDecimate line.

-> Main thing that bugs me is that how can both scripts have a working preview?

Cu Selur

[Wisperer]

Okay I've stabbed at it some more. I went back through and re did my script comparisons. I made sure exactly EVERYTHING was the same.

This line at the end of the debug .VPY caught my attention. 

stacked = core.std.StackHorizontal([original,clip])
# set output frame rate to 23.976fps
stacked = core.std.AssumeFPS(clip=stacked, fpsnum=24000, fpsden=1001)
# Output
stacked.set_output()

it's not in the older 2020.12.13.1 stable build.

in that it looks like 

clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P10, range_s="limited")
# set output frame rate to 23.976fps
clip = core.std.AssumeFPS(clip=clip, fpsnum=24000, fpsden=1001)
# Output
clip.set_output()

 I added the  scripts as attachments again.

[Selur]

The stacked-part should only be there if:
a. Filter View is used
b. the Vapoursynth Preview is used
it should not be inside a script used for encoding.
-> Without a proper debug output which shows that this script was used for encoding, which I highly doubt, that difference means nothing.

Cu Selur