AvsPmod QTGMC script janky and slow?
 

It been a while since my last post back in May, I was finally able to get to the part where you do the scripting in order to de-interlace and render a capture. I also managed to figure out how to capture my VHS footage with HuffyUV compression and it has done wonders to my file size while keeping it good.

However, I'm not sure which is the best script to use to upload onto YouTube.

At the moment, the script is currently this as per latreche34's advice from my last post:

Since the capture is in PAL format with FPS being 25fps. When I set the QTGMC filter, it increase to 50fps which makes the preview slower and janky, is this normal? Is there any alteration I could make and is there anything that I'm doing wrong?

If you're using a frameserver and running a deinterlace previews can be glacial, for an example our video work stations are overclocked, watercooled "Threadrippers" running 128GB of RAM and they don't generate a preview of any any better than our more humble i3 capture machines with 16GB of RAM.

The reason is that the software in the background can't take advantage of modern processor types in the most simple terms, it runs in such a way it can only take advantage of a fraction of the processing capability available on modern machines. It's a very deep and complicated topic, but it's normal I'm afraid.

I don't know how where or why but that'll give you 25FPS (maybe after prefetch?).

Interesting, the preview is quite smooth now, I think it fixed the janky preview, at least it now in the correct PAL format and I can proceed on to the next step, hopefully I won't run into any more obstacles. Thanks.

Be careful with single-rate output, you are throwing away half of the motion after deinterlacing, which is not optimal.

Some work-around here: http://avisynth.nl/index.php/QTGMC under "Shutter Speed Motion Blur / Frame Rate" chapter

Calling PAL video 25fps is a simplification. It's 50Hz. A lot of content uses that full motion resolution, and QTGMC without SelectEven lets you retain it by outputting 50fps.

For preview, there are 5 presets that are faster than "Fast" (and quality will also be worse). Try "Ultra Fast" or "Draft".

QTGMC has a "fpsdivisor" setting for outputting half frame rate (25fps in this case) though unless there is some good reason not to and it's standard video material I would keep it at 50fps as that's what analog PAL video is really at. Going down to 25fps throws away a lot of the data. EDIT: as others pointed out too while I was writing. I woudln't worry too much about the preview being a bit slow in whatever application you are viewing it in, it's the final output that matters.

For Youtube upload you want to scale to at least 720p (though 1080p or more will be nicer) for youtube as any lower than that doesn't support the full 50fps and it gets compressed a lot. If it's noisy vhs it can be helpful to do some denoising too as it helps with maintaining quality when it gets compressed by youtube.

EDIT2: Would also add at the end, as that's the format that will be used on youtube anyhow.

Keep in mind though, I already captured the master file in 720x576 YUY2 4:2:2 interleaved with HuffYUV compression. so would adding "converttoyv12()" to the script be necessary?

Also after I loaded the script onto VirtualDub2 what do I do next? Do I need to do further compression? One person advised to not encode it and upload file to let YouTube encode it, does that mean I should simply save (F7) the deterlaced and resized video as it is and let YouTube encode it? It is fine to save it as Avi again, MP4 (MPEG-4 Part 14) or MP4 +faststart?

P.S. I just realised I have revealed my PC username on the directory when showing my script. Is it possible for an admin to redact the name after "\Users" as well as the one quoted by the other users?

So I hit a bump again. I tried to save the .avi with script via MP4 and AVI but it keeps giving me "raw video codec not currently supported in container". I tried adding the "converttoyv12()" to the script and tried again but still get the same error.

EDIT: Never mind I managed to save it via AVI handled by FFMPEG. It said that the projected size would be 30GB but the outcome is only 26mb (The raw file was just over 1GB) and only saved the audio. I'm going to stop since I'm very confused with it now.

EDIT2: So I experimented by setting the video compression to x264 8-bit and audio compression to FFMPeg AAC and it managed to export it with both video and audio at around 109 mb, however I noticed the jittering artefact that QTGMC is said to do, it hard to describe but it makes the video look weird.

I guess my biggest question at the moment, how can I export my QTGMC/cropped/enlarged video without encoding on VirtualDub2 so that YouTube can do that job? If that even possible.

Jittering effect: Add AssumeTFF() after your AVISource line. (Just guessing.)

You could set output compression to Huffyuv, leave audio uncompressed, and output AVI. But the benefit is mostly theoretical IMO, and it will take forever to upload and for YouTube to process the "HD" version of your video. I would recommend compressing to x264 at a low CRF instead.

I'm confused. :question:

I thought Interlaced was 50 fields per sec, and that deinterlacing with say QTGMC would combine those fields into 25 frames per second. I have read that 50 frames per second looks smoother, but I thought that making the video 25 frames per second would be OK anyway using SelectEven, as that was what the original video was.

Are you guys saying if I use SelectEven I am throwing away 25 of the original fields?

Edit: less confused now. I found this on the QTGMC wiki:

Interlacing is a sort of temporal compression, working because the retinal persistence. The "ideal" frame presented every 1/50 second is reduced to half of its size to save bandwidth and becomes a field, but each filed contain unique data. When the fields are presented every 1/50 second the eyes "build" the full picture.

It was ingenious at the time.

A de-interlacer interpolates the data of the fields and builds unique frames every 1/50 second. If you remove one of them you are throwing away half of the data.

A description technically not very accurate, but I hope it helps.