digitalFAQ.com Forum - Avisynth rendering faster?

digitalFAQ.com Forum (https://www.digitalfaq.com/forum/)

- Restore, Filter, Improve Quality (https://www.digitalfaq.com/forum/video-restore/)

- - Avisynth rendering faster? (https://www.digitalfaq.com/forum/video-restore/13473-avisynth-rendering-faster.html)

Avisynth rendering faster?

Hello

Is it possible to speed up Avisynth rendering in some way? I am currently using Virtualdub with 5-8 fps which would make up to 12 hours with 1,5 hour home video.

My rendering workflows are based on Ryzen 7 5th gen and Intel I5 10th gen processors with 16GB ram both.

a. faster hardware
b. optimizing the script you use

Quote:

Originally Posted by Selur (Post 90440)

a. faster hardware
b. optimizing the script you use

^ This.

Some scripts allow multithreading via the MT mode, but glitches too often happen. It depends on Avisynth version, filter, filter version, etc. For example, x86 Avisynth, with QTGMC, MT modes, would create glitch and green frames. (Use x64 QTGMC, no issues, and faster even that x86 with MT.)

I was just about to ask the same thing!

The secret appears to be use of MT mode. Check out this topic:

https://forum.videohelp.com/threads/...y!#post2672397

I'm going to ask some detailed questions in relation to AVISynth versions, 32bit/64bit requirements, and how MT is set up. Hopefully the AVISynth experts will give us some guidance.

Quote:

Is it possible to speed up Avisynth rendering in some way? I am currently using Virtualdub with 5-8 fps which would make up to 12 hours

You're lucky :D :D :D.

Some of the best processing + upscale in AviSynth/VapourSynth runs at < 1fps.

The same for some of the enhaced alghorithms in Topaz VEAI (which I do not use); in addition you need to feed it with deinterlaced video (QTGMC processing), which reduces further the processed number of fps.

In addition to what already recommened, try to split the AviSynth script: often I run deinterlace in a separate script than denoising. It increase a lot the (temporary) required disk space, but the sum of the running time for the 2 processing is << than the processing time for a single script including everything. This is particularly true when using VirtualDub to create the final output, a bit less with ffmpeg direct generation.

edit: lordsmurf is right, be careful with MT mode (I never use it), it is prone to generate errors with filtering across large temporal radius because the way the information from one frame is propagated inside the processing. Others may have a good recipe in term of versions/# of bits to use...

multithreading work good for me (it would be super slow without it, i got an old phenom Ii X4 955 cpu)

Code:

SetMemoryMax(900)

SetMTMode(3,2) # higher numbers of threads for the video source produce corrupted images i've found, no idea why

AVISource()

SetMTMode(3,4)

Filters....

You may have to decrease (or increase the mode and/or numbers of threads with certain filters), or it may produce corrupted images, example:

Code:

SetMTMode(2,4) # Works ok

McDegrainSharp(last,2,bblur=0.2,csharp=0.4)

for virtualdub filters:

Code:

SetMTMode(3,2) # Works ok

ConverttoRGB32(matrix="rec601",interlaced=false)

MSUSmartSharpen(2)

Quote:

Originally Posted by lollo2 (Post 90446)

edit: lordsmurf is right, be careful with MT mode (I never use it), it is prone to generate errors with filtering across large temporal radius because the way the information from one frame is propagated inside the processing. Others may have a good recipe in term of versions/# of bits to use...

I would also add this warning: :warning:

People that claim to "never have issues with MT" are generally either

- impossibly lucky; it happens
- not paying attention, oblivious to their results
- not using Avisynth very much, ie limited experience

More than once ... many times now ... I've had others confirm MT processing glitches, including those that previously claimed "worked for me" (until it didn't).

There is a chronic issue in the video community, where people capture/process/encode video, then assume the output is fine. No. There must be auditing, via scrubbing, and spot testing. The best way, of course, is actual watching. I've put up with this for 30 years now, both in hobby and pro communities. Too many claims, lots of assumption, or just outright BS.

People too often just don't pay attention to what they're doing, or have done. And that extends far beyond the world of video.

All times are GMT -5. The time now is 08:31 AM