I do not understand your script, and why you apply a lossless deinterlace if at the end you deinterlace for the final version, but maybe I am missing something.
In addition, a color matrix change should be done before upscaling.
I would experiment the following, reducing also the computation effort.

You can solve the "memory" problem by splitting the operations in 2 steps, generating an intermediate file (unfortunatly, the disk occupation will be twice while processing).

The denoise and QTGMC processing probably changes your (whatever) input levels to output levels 0-255. You can use Levels() functions before changing the color matrix to adapt them at your own taste. Better to use a Levels() version which only acts on Luma and leaves Chroma unaffected.

Sorry--I left that de-interlacer there because if I did not divide by two with QTGMC in the beginning, all of my frames that I trimmed later on would be screwed up, so I want to fix that issue first.

It seems that there is a slight color banding on the bottom of each other frame if I don't choose FPSDivisor=2. I would obviously rather keep the 59.97, but I do not know what is the problem. Below I have attached two consecutive frames to show the difference, with another picture highlighting the extra banding. Is this common?

Attachment 14436

Attachment 14437

Attachment 14438

Also, you were right about the resizer and QTGMC affecting the color. I didn't know this could happen. ColorMatrix brought the colors into 16-235 territory but the nnedi3 resizer brought them back out of the safe zone. I guess I will have to apply another ColorYUV() at the end. I am surprised that is not more documented.

Lastly, do you think my issue in VirtualDub was because my script was too intensive (despite having 16gb of RAM)? Was my resize correct? I have read that if the resize is not done correctly VirtualDub could throw an error, but 1920 by 1440 is 4:3 and mod-2, so I don't know what else could be the issue.

If it is simply a RAM issue then I won't have a problem resizing in a second script--I just want to make sure that I am not doing something else wrong. I am using only 32-bit Avisynth, so that can't help, either.

Thank you again for all your help--I'll make sure to not bother you until after the holiday!:laugh:

Not really. Try to play with QTGMC parameters and to crop before QTGMC. I always do that.
same frame-rate QTGMC is not a good idea, except if no motion is present. Some details here: http://www.digitalfaq.com/forum/vide...mc-script.html

Difficult to be accurate with ColorYUV. Better use a Levels() function acting only on Luma:
No. Analog video once captured in SD is 720x576 (or 720x480) at 4:3 DAR. Upscaling to HD the height is 1080, then the width must be 1040x4/3 = 1440.
You then leave the frame at 1440x1080 or you add 240 black borders on each side to build the standard fullHD frame size.

Don't worry, I am learning as well. Each video is unique and has its specific issues, so is rare that a standard processing is applied. Looking different samples is always instructive ;-)

then the width must be 1080x4/3 = 1440 (typo correction)

Thank you again. Just to clarify something (before your break!), isn't 1440x1080 only 4:3 with 1:1 (square) pixels and this SD video (in NTSC land of 720x480) is based off non-square pixels?

From what I read, 720x480p is 4:3 DAR but 10:11 PAR and an aspect ratio of 3:2 (1.5). My 1920x1080 is wrong because that is 16:9, so I should upscale to another 3:2 format, like 2160 x 1440, no?

I would rather not crop the 720x480, and the only purpose of this deinterlaced version is for YT to get a better bitrate. Since 2160x 1440 is not an acceptable format, they will add pillarboxes to it, but I am okay with that.

Feel free to suggest any reading material if you know a good source. This area is a bit confusing. :blink:

P.S. I did crop before QTGMC but I will play with the settings like ChromaMotion

I generally use this semplified approach for PAL:

720x576 SD, DAR (display aspect ratio)=4:3, SAR (storage aspect ratio)=720/576=5/4, PAR (pixel aspect ratio)=DAR/SAR=4/3*4/5=16/15
non square pixel, because PAR is not 1

in your NTSC land will be:

720x480 SD, DAR (display aspect ratio)=4:3, SAR (storage aspect ratio)=720/480=3/2, PAR (pixel aspect ratio)=DAR/SAR=4/3*2/3=8/9
non square pixel, because PAR is not 1

convert to HD:
1- height of HD = 1080
2- width of HD = height of HD * DAR SD = 1080 * 4/3 = 1440

1440x1080 HD, DAR (display aspect ratio)=4:3, SAR (storage aspect ratio)=1440/1080=4/3, PAR (pixel aspect ratio)=DAR/SAR=4/3*3/4=1
square pixel, because PAR= 1

To be more accurate, it should be considered the ITU-R BT.601-4 (formerly "CCIR-601" or "Rec.601") spefication for Analog SD is 702(704)x480 pixel inside the 720x480 frame, the rest should be black.
So you can crop to 702(704)x480 before upscaling.

Some references:

http://www.arachnotron.nl/videocap/d..._cap_v1_en.pdf

http://web.archive.org/web/200606211...eo/conversion/

If you prefere to build the fullHD frame:

convert to HD:
1- height of HD = 1080
2- width of HD = height of HD * DAR SD = 1080 * 4/3 = 1440
3- add 240 black pixels on the left and on the right --> 1920x1080

1920x1080 HD, DAR (display aspect ratio)=16:9, SAR (storage aspect ratio)=1920/1080=16/9, PAR (pixel aspect ratio)=DAR/SAR=16/9*9/16=1
square pixel, because PAR=1

Thank you for the explanation. I hope you are having a good start to the new year. I have tried to read up on this area but it still seems too complicated for me. But my understanding is that when we upscale, the PAR must be 1:1 square pixel because that is the only PAR for computers, right? A Doom9 poster wrote ""Converting to square pixels" is just another word for resize."

In that case, I could also do 1920 x 1440?
Height of 1440p HD = 1440
Width = 1440 x DAR SD = 1440 * 4/3 = 1920.

The SAR is 1920/1440 = 4/3. If we intend for it to be shown on a 4:3 screen, DAR =4/3, correct? So (4/3)/(4/3) = 1 PAR.

If I am right, you upload your videos on YT as 1440 x 1080 and not 1920 x 1440, and I do see a quality difference over SD. Would it be worth upscaling to 1440p 4:3 or 1080p 4:3 should be fine?

On another note, I am a bit confused about converting to square pixels that is on Lurkertech's guide. It says at the below link that the 480i signal NTSC signal starts at 720x486 and we can convert this to 640x486 square pixels. But if we upscale to 1440x1080 without first converting to 640x486, we are basing it off the 720x480 (minus the 6 lines lost in overscan). What would be the difference if we first converted to 640x480 and then to 1440x1080?

https://lurkertech.com/lg/pixelaspect/

And, if I wish to keep an interlaced version as well of the original 720x480 video, I would prefer to save it as AVI or MPEG-2. From what I have read, AVIs always display in 1:1 PAR, so if I save the 720x480 video will it be distorted since it uses a PAR of 8/9.

Using your formula above, is this correct:

I would rather add letterbox than crop the image and remove data. We know the PAR we want (1:1) and the DAR (4/3). This, SAR = DAR/PAR = (4/3)/(1/1) = 1.33333. If the width is 720 does that mean to keep it as 4:3 I must have a height of 540? 720/540 = 1.333 :question:

But I can't resize interlaced video, so I would first have to de-interlace it with something like needi3, resize, and then re-interlace?:unsure:

If I have been doing it wrong previously, why have I never seen any distortions when playing 720x480i AVIs on my computer, if AVIs don't support a DAR?
https://forum.videohelp.com/threads/...nd-Resolutions

1440 is not a HD or fullHD vertical resolution, which is 1080

You can set horizontal resolution to 1920 (fullHD) with DAR 16:9 or 1440 (HD) with DAR 4:3. Starting from SD frame, if you want the first, you preliminary generate the 1440x1080 frame and then add 240 black borders on each side.

Why do you want to resize several times? Each processing can be lossy (we only do when we want to sharpen a bit between intermediate steps). And why do you want to convert between square and not square pixels? Any PC player or modern TV handle DAR info whatever the PAR is.

An avi container for analog captures does not contain the DAR info or flag. You must set your player (i.e. in VLC -> Video -> Aspect Ratio -> 4:3, or add the flag manually with ffmpeg or add the apsct ratio while encoding. We were just discussing it: http://www.digitalfaq.com/forum/vide...s-capture.html

I wish the same, all the best to you and to the other users for 2022!!!

Sorry to resurrect this thread, but I finally had time to get back to this query (after going crazy for a few days). It seems that there are some issues with VirtualDub when I run this script. I am unable to run the x264vfw codec on this file in VirtualDub1 or VirtualDub2 (both 32-bit, because of all the different plugins) without getting the error "Video compression error: An unknown error occurred (may be corrupt data). (error code -100)"

When I try to encode it with FFV1 8-bit 4:2:0 I get the error "Video compression error: Not enough memory. (error code -3)". I realize that this might be due to using 32-bit due to the 4gb limitation, but is there a way to still process the video more slowly without going over the limit?

For some reason, the encoding works fine in FFMPEG x265 and x265 lossless.



Here is the code I have been using

Thanks for any suggestions.

I ignore why VirtualDub and VirtualDub2 have problems, but for a basic x264 compression they are useless and you do not need at all.
Just run a simply ffmpeg command line instead, as you apparently do for x265:

Thanks for the quick reply--it is always appreciated. While I would have no issue exporting FFV1 or x264 or x265 in FFMPEG (since I am not using VD filters), when I try to run a command like the one you wrote, it says Unknown error occurred. It seems there is some issue with opening .avs files (opening non-avs files works).

I spent about 10 hours straight trying to figure out the FFMPEG problem before posting. From what I read, I had to install Avisynth headers from the source code, build just the headers, then make and install avisynth.h under an include folder where FFMPEG is installed (which I added). I finally was able to do that after asking ChatGPT for instructions :o. While it was a success, the error didn't go away. When I try to pipe it through avs2yuv it actually works but the quality does not look that good.

Any ideas?

No idea of what you are talking about, sorry.

Just install AviSynth as usual (I suppose VirtualDub was able to read and display your AviSynth script, so this should be ok), and place downloaded FFMpeg binary somewhere, no need to install anything here.

Upload a portion of your source (we already have the AviSynth script), so we can try to reproduce your problem.

Thank you, but this problem occurs even though Avisynth+ and FFMPEG are already installed (I used it to make this segment from the complete .avi, so it would seem that the issue is not with FFMPEG. It just cannot open avs files. Should I reinstall Avisynth+? I have attached a segment.

I tried your script on your old video (not the right source, but just to try all the filters you use; all trims removed) and it works fine here when feeding a ffmpeg command line as above.

If you experience "Unknown error occurred" it may be related to ffmpeg not finding some of the plugins. Try to specify an absolute path instead of a relative path in your avs script.

My (working) script attached as reference (change the path with yours):

Thanks for the tip. Sadly, I still get the same Unknown error occurred. This is my script:

Maybe it has something to do with the errors I get when opening Avisynth+? Every time I open a script I get something like this, which I read may have to do with Registry order of reading the plugins:

I am using x32 version.

I do not know, sorry, I do not use AviSynth+.

Maybe you can try first with AviSynth, and then if everything works switch to AviSynth+ debugging step by step (one filter at the time)

Do you think it matters if it does not open any .avs file, regardless of the filters? I tried it on the authors.avs file that comes with Avisynth and the same error occurs.

I also see that my FFMPEG is 64 bit while I have installed only 32bit Avisynth+. Could that be an issue?

It does matter. It's not normal.

Probably yes. Be consistent with 32bit / 64 bit versions