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

It took some time to install 64-bit Avisynth+ and change all of the filters, but now everything is working, so thank you for the help!

I am trying to archive a version of the restored video but FFV1 takes up too much space. I have read that mpeg2 is a good codec for analog from experts like Lordsmurf, so I exported clips at 10, 20, and 30 MBs. It is hard to tell when the video is playing but when paused the effect is noticeable, mainly in how the grain is preserved, which I want.

FFV1 Lossless
Attachment 16356

mpeg2 20 Mbps
Attachment 16357

mpeg2 30 Mbps
Attachment 16358

To me, there is a significant improvement in the grain preserved between the 20mbps and 30mbps mpeg2 video, but it still doesn't match the FFV1. Do you think going to 40Mbps is extreme or is there a better codec that can preserve this grain while not exploding the file size? I have no problem taking time in the encoding stage, since this is for archiving (I will still keep the original .avi).

I should note that, while the grain is artificial, it helps to give the psychological effect of more detail, which is why I add luma noise at the end.

P.S. For some reason the FFV1 lossless inline attachment is not coming out right, so I have attached it as well. I uploaded a .png but for some reason it is being automatically converted to .jpg, so the grain is blurred. The easiest place to see a difference (at least on my PC) is on his left cheek.

P.S. P.S. Imgur was able to preserve the grain detail:
https://i.imgur.com/fa2oS4r.png

There is not a single reason today to archive in obsolete MPEG2 format. Nowdays is only used for DVD. Broadcasted TV switched to AVC codec since longtime for good reasons, even for SD interlaced material. Same for Blue Ray.

The preferred choice for archival is the original capture, large HD drives are not expensive today.

If you really want to compress your captures use h264 at low crf, slow preset, YUV 4:2:2 and interlaced options if required. Someting like:

Thank you. From what I have read on this site, H.264 does not handle interlaced well, so MPEG2 should be used instead because it was designed with analog formats in mind. Is this your view?

For progressive formats, what bitrate would you suggest is archival quality for a typical deinterlaced 1080p video? 15mbps? I know there are calculators out there, but I care more about the quality than determining file size.

What you read is false; there were some (useless) GUIs like Handbrake or similar having problems 10 years ago, but not the codec. And no, it is not my view.

https://forum.videohelp.com/threads/...H-264-encoding

Use crf, a parameter for determining quality rather than calculate bitrate and then final size. :wink2:

If you search the forum there should be a comparison I made between a huffyuv capture and its h264 encoding at low crf. Not really distinguishable at normal view, need a 4x magnification to find artifacts. And you can repeat the experiment by yourself on your own material.

Thanks--it turns out that FFMPEG has an option with libx264 called -tune grain, which can preserve the grain in video. At crf 17, the file size is about 30% that of FFV1.

I don't know much about MPEG-2 vs h.264 debate for analog, but why do you think LordSmurf recommended the former is this post, if you say MPEG-2 is obsolete: https://www.digitalfaq.com/forum/vid...html#post38025

No idea. Better ask him directly.

I disagree with him more than I agree on many points, but he's a resource for the community, that's for sure.

I would never capture to MPEG2, even if no restoration is needed.

But all this is not really important, what is important is that you found your way of capturing and restoring your video with good quality, and did significant progress since you started.

Good luck with your captures/restoration!

Yes, in part due to your help. Thank you for all of the tips along the way!

Hi again,

Happy holidays, if you celebrate. I have a clip where the color seems to spill over in some areas, like in this frame off the top of the woman's right arm. (ChromaShiftSP was applied to the extent possible without affecting other parts of the video).

Attachment 16409

Chroma was fixed through
If I apply the same function but replace MergeChroma with MergeLuma, the problem is fixed but of course the rest of the clip is smoothed. In another NLE I would apply an edge mask so that aWarpSharp2 and MergeLuma only work on the edges, but I am not too familiar with how to do this in Avisynth with its syntax. Do you have any suggestions?

This didn't work:

Well, that's a disturbing image. :sick:

It's a woman lying down during an interpretative dance sequence. She's very much alive and well (except for her shoulder shadow)...Tape is over 40 years old.....

I would work differently on Y and UV planes, but is difficult to asses with an image.

Have a look here https://forum.videohelp.com/threads/...on#post2640813, and ask there; poisondeathray and jagabo are the masters of masking ;)

Thanks again--I'll keep everyone posted on what I find out!

I uploaded a video segment this time. Is this ghosting? It turns out that MergeLuma with aWarpSharp2 only took part of the effect away, so the masking wasn't necessary and something else might be needed. (This was after MergeChroma/aWarpSharp2 was used, plus ChromaShiftSP). Thanks for any suggestions.

Attachment 16415