x264 encoding crashed by QTGMC?

[drumlikemason]

Hello everyone,

I'm ripping and re-encoding my BD collection to store it on NAS HDD. I'm struggling with one clip. The file is a standard BD M2TS file, although with SD MPEG-2 video (it's a bonus concert from 1997 added to main gig from 2007, so I guess BD authors just ripped this film from DVD).
My workflow is:
1. file indexer from MEgui (FFMPEG, L-Smash-Works or DGMPEGDEC)
2. avisynth script with QTGMC for deinterlacing and DeRainbow (there are some visual rainbow errors in the film)
3. x264 encoding with MEgui.

All the time I keep getting the same error when encoding, MEgui stops at random points and outputs error - "number of frames does not match the source". I'm completely lost. I tried everything. I used different file indexers, I created indexes from mkv file extracted from m2ts file by eac3to, I created index from m2ts file with dgmpegdec. I even used some ancient soft like ProjectX, to correct demuxed video, nothing worked. Changing from MEgui to ffmpeg doesn't work either. I tried to just create temporary QTGMC deinterlaced video in huffyuv in ffmpeg, but it didn't work either.

After many tries I dumped QTGMC and used yadif2mod for test aaaaand the encoding started! Until now it haven't crashed. However I prefer to use QTGMC instead of yadif2mod for obvious reasons. I've thought it may be a memory overflow problem, but System Monitor doesn't report that. QTGMC perfecly worked in MEgui with HD video (from the same BD), so why wouldn't it work with SD video?

Of course I'm using 32-bit MEgui version, because of QTGMC.

Does anyone have any idea why QTGMC crashes encoding? I'm sending the script that I used. It's with DGDecode, but no matter what file indexer I used, nothing changed.

SetFilterMTMode("QTGMC", 2)
LoadPlugin("D:\encoders\MeGUI-2808-32\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\xxxxxxxxxxxx\00002.d2v", info=3)
LoadPlugin("D:\encoders\MeGUI-2808-32\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
QTGMC(preset="Fast", EdiThreads=2)
DeRainbow(thresh=8, interlaced=false)
Prefetch(3)

Thanks in advance.

[LigH.de]

Interesting error: "number of frames does not match the source" ... that usually means that the second pass returns more frames than the first pass in a 2-pass encoding, exceeding the statistics file from the first pass.

You should know that QTGMC per default works like a bobber, means, it interpolates all fields to frames, so you will have twice the number of your original frames at twice the frame rate. If you did not use the same script in the first as in the second pass, this kind of error should reliably appear at half the playing time. But appearing at random points is ... crazy. Maybe someone else is smarter than me and can imagine a reason.

[drumlikemason]

Thanks for answer! I'm using CRF mode w x264, so the reason of this error is somewhere else, but maybe I'll go with 2-pass. Maybe in this randomness it'll work

[LigH.de]

In my imagination, this error message doesn't make sense in a one-pass encoding mode like CRF. Except, maybe, the index file for this specific source is interpreted wrong, so there might be an issue with the source.

It may help to provide the complete MeGUI log.

[Groucho]

Except, maybe, the index file for this specific source is interpreted wrong, so there might be an issue with the source.

That makes more sense since the error does not come from x264.

[poisondeathray]

Of course I'm using 32-bit MEgui version, because of QTGMC.

Why? It works in x64

Does anyone have any idea why QTGMC crashes encoding? I'm sending the script that I used. It's with DGDecode, but no matter what file indexer I used, nothing changed.

Probably colormatrix ; people have reported crashing , corruption and threading issues , despite setting it as MT_NICE_FILTER

(and you're probably not using colormatrix for the HD conversions that worked, so it's likely the culprit here)

#note2: tried multiple files, seems to corrupt video even when it is the only filter in a script.
#tried mode 1, 2, and 3, none worked. however it works fine if MT isn't enabled.

https://forum.doom9.org/showthread.php?p=1865279#post1865279

ColorMatrix is running absolutely fine in MT-Mode within AVS+ (x64), but only it it's placed within a bubble of sequential frame order. So, to ensure that, RequestLinear has to be used and to be defined as MT_SERIALIZED. It makes no sense to use RequestLinear as MT_MULTI_INSTANCE. Therefore the following sript is working totally fine for me (I tested it multiple times with ST and MT encodings of the same clip) - no differences within the x264 logfiles. I did encounter differences when not using RequestLinear as MT_SERIALIZED of course.

Or you can use alternate methods like dither tools, z_ConvertFormat .

[poisondeathray]

Since it's SD, why do you even need colormatrix ?

It's something that has plagued megui since the beginning and they still haven't taken it out.

Try commenting it out

[drumlikemason]

Eureka! It was colormatrix that crashed the script. Without it everything runs smoothly.

Why? It works in x64

I completely forgot about it! I've used it now in x64 and wow, 2x more fps. That is a one valuable information. However I still have to go with x32, because of DeRainbow.

Probably colormatrix ; people have reported crashing , corruption and threading issues , despite setting it as MT_NICE_FILTER

(and you're probably not using colormatrix for the HD conversions that worked, so it's likely the culprit here)

I haven't thought about, but yeah, I don't need colormatrix in here. It was in the script just because megui added it there.

Now everything works, thanks a lot!