QTGMC Multi-thread Mode and HD

[SameSelf]

I have great success with QTGMC MT and SD video. Therefore, I always deinterlace my SD video. IOW, I have a lot experience using QTGMC MT with SD video.

I recently received some AVCHD 1920x1080i29.97 video that I am trying to de-interlace. I have read through this post and played around with the settings quite a bit, but the farthest I can get into the video is about 4 seconds before crashing. Here is the QTGMC MT script I am using:

SetMemoryMax(400)
SetMTMode(3, 8)
DirectShowSource("E:\video.MTS", audio=false)
AssumeTFF()
SetMTMode(2)
QTGMC( Preset="slow", EdiThreads=1 )
Distributor()

I can "scrub" through the video in vdub, but when I try to encode using ffmpeg it crashes about 4 seconds in.

ffmpeg -i in.avs -vcodec mpeg2video -pix_fmt yuv422p -q:v 1 -qmin 1 -intra -an out.m2v

I am wondering if anyone has had any success with QTGMC MT with HD video and what settings work for you. Thanks.

[jagabo]

Reduce the number of threads. AviSynth is running out of memory. I don't know if mode 3 works for DirectShowSource(). Try mode 5.

[Selur]

a. use a higher SetMemoryMax value
b. try removing the 'distributor()' call at the end
c. check the over all memory usage
d. don't use DirectShowSource

[sneaker]

e. use a pipe to separate the AviSynth/QTGMC and encoding processes
f. switch to VapourSynth (x64) altogether - multi-threaded QTGMC should be more stable there

[poisondeathray]

Crashing in this scenario is usually due to memory issues with HD and avisynth x86

Vapoursynth x64 is indeed more stable as suggested in (f) and doesn't crash (at least it hasn't for me when I can repeatedly induce crashes with avisynth x86 in similar HD scenarios), but it's slower with a single instance of QTGMC compared to avisynth MT (about 10-20% slower). But when stacking multiple filters, it's actually faster. The more operations, the larger the delta. There seems to be some threading issues with avisynth MT and especially QTGMC when performing more than 1 operation.

[SameSelf]

Thanks, jagabo, Selur, and sneaker. You guys rock!

From what I can see, the main culprit was DirectShowSource. I switch to FFmpegSource, and the crashing went away. Hurrah!

In my frustration last night, I rolled back to ST mode just to make sure my problem wasn't something non-MT related. It worked fine averaging about 6.3 fps.

This morning, after getting it to work in MT mode, my speed was slower than ST mode. So I started increasing parameters. No luck, I maxxed out at the exact same speed as ST mode and a paltry 18% cpu usage. After scratching my head some more, I added back in the Distributor() line and voila! I was now maxing out my cpu. I was able to get about 5 minutes into a video before it crashed. So I tweaked back the thread count and was able to finish. My frame rate was about 16 fps, so a nearly 3x bump over ST mode! Here is my final script:

V = "E:\video.m2ts"
Y = 7
M = 900

SetMTMode(5, Y)
SetMemoryMax(M)
FFVideoSource(V)
AssumeTFF

SetMTMode(2)
QTGMC( Preset="slow", EdiThreads=Y )

Distributor()

[SameSelf]

Crashing in this scenario is usually due to memory issues with HD and avisynth x86

Vapoursynth x64 is indeed more stable as suggested in (f) and doesn't crash (at least it hasn't for me when I can repeatedly induce crashes with avisynth x86 in similar HD scenarios), but it's slower with a single instance of QTGMC compared to avisynth MT (about 10-20% slower). But when stacking multiple filters, it's actually faster. The more operations, the larger the delta. There seems to be some threading issues with avisynth MT and especially QTGMC when performing more than 1 operation.

Hmm, I have never used Vapoursynth before. Even though I seem to be up and running, I will have to give it a shot since since it looks like stability problems are still lurking.

[SameSelf]

Well, after looking at the Vapoursynth developer's page, it looks like it will require some investment since I don't know the first thing about Python. But it looks like it is worth it given that Avisynth is old and Vapoursynth looks closer to a state of the art.

The real reason I am posting back here though is after running my video through QTGMC, I am getting a rather odd result. The file is 29.97i but QTGMC produced a 120 fps file. When I bring it into PP the file length is all messed up as a result. So something went wrong. But I don't know where. I know for certain the video is interlaced because when I inspect it in vdub I see jaggies.

Here is the MediaInfo:

General
ID                          : 0 (0x0)
Complete name               : E:\video.m2ts
Format                      : BDAV
Format/Info                 : Blu-ray Video
File size                   : 540 MiB
Duration                    : 11mn 17s
Overall bit rate mode       : Variable
Overall bit rate            : 6 678 Kbps
Maximum Overall bit rate    : 18.0 Mbps

Video
ID                          : 4113 (0x1011)
Menu ID                     : 1 (0x1)
Format                      : AVC
Format/Info                 : Advanced Video Codec
Format profile              : Main@L4
Format settings, CABAC      : Yes
Format settings, ReFrames   : 2 frames
Format settings, GOP        : M=2, N=15
Codec ID                    : 27
Duration                    : 11mn 17s
Bit rate mode               : Variable
Bit rate                    : 5 955 Kbps
Maximum bit rate            : 16.0 Mbps
Width                       : 1 440 pixels
Height                      : 1 080 pixels
Display aspect ratio        : 16:9
Frame rate                  : 29.970 fps
Color space                 : YUV
Chroma subsampling          : 4:2:0
Bit depth                   : 8 bits
Scan type                   : Interlaced
Scan order                  : Top Field First
Bits/(Pixel*Frame)          : 0.128
Stream size                 : 481 MiB (89%)

[jagabo]

ffmpegsource often gets the frame rate wrong with interlaced transport streams, using the field rate rather than the frame rate. Specifying the frame rate should work:

ffVideoSource("filename.ext", fpsnum=30000, fpsden=1001)

[sneaker]

If it only gets the framerate wrong doing that may throw away frames. If that is the case AssumeFPS() should be used instead.

[SameSelf]

ffmpegsource often gets the frame rate wrong with interlaced transport streams, using the field rate rather than the frame rate. Specifying the frame rate should work:

ffVideoSource("filename.ext", fpsnum=30000, fpsden=1001)

Thanks for that. I tried using SelectEven. Do you think that would be the same result? Or did I throw away some temporal info?

[jagabo]

ffmpegsource often gets the frame rate wrong with interlaced transport streams, using the field rate rather than the frame rate. Specifying the frame rate should work:

ffVideoSource("filename.ext", fpsnum=30000, fpsden=1001)

Thanks for that. I tried using SelectEven. Do you think that would be the same result? Or did I throw away some temporal info?

ffVideoSource duplicates each frame so SelectEven() will give the same 30i result.

[jagabo]

If it only gets the framerate wrong doing that may throw away frames. If that is the case AssumeFPS() should be used instead.

No, it interprets the field rate as the frame rate, and since there are only 30 frame per second it duplicates duplicates each frame to make 60 frame per second. Using AssumeFPS will double the running time. And after QTGMC you will have lots of back and forth motion. Ie, instead of fields 1, 2, 3, 4... you get 1, 2, 1, 2, 3, 4, 3, 4...

[SameSelf]

Well, after lots of trial and error and with the help of everyone here, I think I finally got my QTGMC script correct. I inserted the fpsnum and fpsden arguments and the encode speed doubled! So, it was obviously screwing up even with SelectEven. FWIW, I am getting 15 fps for a 1440x1080i29.97 anamorphic video. Here is my final QTGMC script, and it seems quite stable with cpu usage ~90%:

V = "video.m2ts"
Path = "E:\"
Y = 7
M = 900

SetMTMode(5, Y)
SetMemoryMax(M)

FFVideoSource(V, fpsnum=30000, fpsden=1001)
AssumeTFF
SetMTMode(2)
QTGMC( Preset="slow", EdiThreads=Y )
Distributor()

[jagabo]

I inserted the fpsnum and fpsden arguments and the encode speed doubled! So, it was obviously screwing up even with SelectEven.

Did you put SelectEven() before or after QTGMC()? If after, QTGMC is processing twice as many frames so you would expect it to take twice as long.

[sneaker]

No, it interprets the field rate as the frame rate, and since there are only 30 frame per second it duplicates duplicates each frame to make 60 frame per second. Using AssumeFPS will double the running time. And after QTGMC you will have lots of back and forth motion. Ie, instead of fields 1, 2, 3, 4... you get 1, 2, 1, 2, 3, 4, 3, 4...

That's why I used lots of "ifs".
I had to wonder because he said his output was 120 fps and having a wrong duration. If he started at 30 fps and both ffms2 and qtgmc doubled the framerates he should have gotten the correct duration at 120 fps but with duplicated frames.

Either way problems like these could easily be avoided if people would simply take a look at their scripts in e.g. VirtualDub before encoding. Identifying duplicated frames isn't exactly rocket science.

[SameSelf]

Did you put SelectEven() before or after QTGMC()? If after, QTGMC is processing twice as many frames so you would expect it to take twice as long.

I put it after QTGMC() as it is recommended on the Avisynth wiki, but only because I was trying to find a fix to the 120 fps problem. I didn't realize FFmpegSource was getting it wrong. It is my first time using it as a loader, so I was not aware of the other arguments. As a rule I like to be explicit about the fps, interlace, etc. So it looks like FFmpegSource read the video as 59.94 fps and that is what was served to QTGMC which is why the encode speed was twice as long. While SelectEven() got me back to the proper number of frames and duration it was still not right, amiright?

Anyway, thanks for all the help.

[poisondeathray]

You should use LSmash for AVC transport streams. FFMS2 has known problems with interlaced AVC in transport streams, including the framerate and field as frame bug. Long standing known issues that still to this day haven't been fixed. (Most reliable is DGDecNV, but not free, and requires a compatible nvidia card)

[SameSelf]

Yikes, I guess lessoned learned. I have a Radeon right now, but just purchased a K2000 so maybe my life will get easier soon. I haven't tried LSmash yet. Guess that is next on my list of things to do.

[jagabo]

I put it (SelectEven()) after QTGMC()... While SelectEven() got me back to the proper number of frames and duration it was still not right, amiright?

It was the right number of frames but rather than having fields 1,2,3,4... you had 1,1,3,3... If you had put SelectEven() before QTGMC() you would have had the correct sequence and it would encode faster.

[SameSelf]

It was the right number of frames but rather than having fields 1,2,3,4... you had 1,1,3,3... If you had put SelectEven() before QTGMC() you would have had the correct sequence and it would encode faster.

I had to think a little to understand what was going on. But, you are right. More than one way to skin the cat, which is good to know.

Option 1: Explicitly specify the frame rate in the FFVideoSource arguments
Option 2: Insert SelectEven() before the QTGMC() call

Because this is just a hobby, I don't have the bandwidth to keep all this straight.