Speeding up Avisynth Encodings with Graphics Card & DGDecodeNV

[MrBiggles]

I'm encoding standard definition videos with McTemporalDenoise Medium and QTGMC Slower. I use DGIndex to index the files. I get around 6fps encoding speed on an 8 core 4.2Ghz CPU. I've got a crappy £30 graphics card which has VP5 which from what I understood from the DGDecodeNV documentation, is all that's needed to get the fastest encoding speed - the other aspects of the graphics card's power doesn't matter. That doesn't seem to be true as if I instead use DGDecodeNV to index the file I get a slightly slower fps encoding speed.

From what I remember someone told me that they have the same CPU as me and they encode HD videos (I think) and they got twice the speed as what I got when encoding HD videos.

So can anyone confirm if the power of the graphics card makes a difference to the encoding speed or can you just buy a cheap £30 card as long as it has VP5?

I want to encode at least 2fps faster on my standard definition videos so will a more powerful graphics card achieve that?

[newpball]

do you think the bottleneck is in the encoding?

[poisondeathray]

It won't make much of a difference in that scenario, because the bottleneck are the slow filters, not the source filter

An analogy would be if you have a car with 4 flat tires, turbo charging the engine to make 100HP more won't make much a difference because you have flat tires - the problem is the flat tires

2FPS faster from 6FPS would be 33% faster - that's huge improvement and not obtainable by merely switching out a graphics card on that script

Do you need QTGMC "slower" ? How about using a faster setting ?

[MrBiggles]

....

[Detmek]

If you plan to use graphic card only for decoding you will not get any speed improvement. Decoding SD video at 6fps does not create any load on your CPU so GPU will offload nothing.

Did you check CPU usage during encoding/filtering process?

[MrBiggles]

If you plan to use graphic card only for decoding you will not get any speed improvement. Decoding SD video at 6fps does not create any load on your CPU so GPU will offload nothing.

Did you check CPU usage during encoding/filtering process?

Don't know what you mean by decoding. Have I misunderstood what DGDecodeNV does? I thought it could use the graphics card like the CPU to encode quicker?

[poisondeathray]

Yes , you've misunderstood what it does

The DECODE in DGDecodeNV means DECODE . It uses the GPU to DEcode , not ENcode. In some cases, it might make encoding slightly faster, but in other cases it actally makes it slower

[themaster1]

If you have an nvidia card (GTx600 or higher i believe) you can use Nvenc h264 or h265 encoders to get a few more fps but the real bottleneck is mctd. Without mctd you can get ~150 fps with nvenc encoders to give you an idea (Sd content) but the quality is not the same as x264

[MrBiggles]

I only encode using x264. Has anyone here used DGDecodeNV with a good VP5 graphics card to encode SD videos using McTemporalDenoise & QTGMC. Did you get a faster encoding speed compared to using DGIndex?

[poisondeathray]

There should be no statistical difference on an SD source with that script with any supported Nvidia purevideo version

Detmek already explained it: decoding SD MPEG2 should take maybe 0.5% or less CPU usage on an average quad core . Offloading 0.5% is not going to make a huge difference. It might even be slightly slower in that situation because of increased latency transfers between GPU . If you use purevideo to deinterlace, it will make a noticable difference. Of if you had a slow/old single or dual core computer , it would make a larger % difference. Or if you had higher resolutions like UHD AVC as source material, that will make a big difference offloading the CPU decoding

You should be using avsmeter to diagnose where you can optimize your script. Chances are, you're using less than 50% in non-MT mode (script only). If you try MPEG2Source (DGIndex) vs. DGSource (DGIndexNV) , it might be <0.5% difference in the CPU usage and FPS speed. x264 can only encode as fast as the frame are fed to it. If it only gets 6 FPS from the script, it can't encode faster than 6 FPS - it can only encode as fast as frames are given to it - that is the maximum. It can encode slower (e.g. if you use very slow encoding settings like placebo) but never faster. You might be able to get 600-800FPS with NVEnc , but if you use your script, it will be 6 FPS too, because the script is the bottleneck. That's why it's important to identify bottlenecks. But I can tell you right away, your bottleneck is the slow filters.

[Detmek]

One more thing. All Nvidia cards with VP5 ASIC have the same ASIC. 30€ Nvidia VP5 card will decode video at the same speed as 300€ Nvidia VP5 card.

But, as it is already said, decoding is not your problem. You use two very complex scripts, MCTD and QTGMC with kinda slow settings. As poisondeathray said. use AVSMeter to see how fast is your AVS script and what is CPU usage.

[MrBiggles]

I don't know how to use a command line program.

[jagabo]

Open your script in VirtualDub. Select File -> Run Video Analysys Pass. That will show you how slow your scrip is.

On my quad core CPU Mpeg2Source() can decode a DVD source at 400 to 500 frames per second. Obviously, the speed of decoding the source isn't your problem. It's QTGMC and MCTD. Running those with a multithreaded build of AviSynth will speed your processing by quite a lot -- if it doesn't crash.

Running this script:

SetMemoryMax(1000)
SetMtMode(5,8) 
Mpeg2Source("VTS_01_1.d2v") 
SetMtMode(2)
McTemporalDenoise(settings="medium")
QTGMC(preset="slower")

I get about 13 fps from VirtualDub's analysis pass.

[poisondeathray]

It doesn't matter for you in this case - you already know where the problems and bottlenecks are

But you can run avsmeter in "simple" mode by drag and dropping an .avs on avsmeter.exe . It won't have any of the switches like logging or GPU analyisis, but it can give you min/max/average FPS, min/max CPU usage, and memory consumption values - which is a bit more info than vdub's analysis pass . But for full usage, including GPU analysis (e.g. if you are running GPU filters, or source filters like DGSource), you need learn how to use the commandline

If you've decided to stick with non-MT , you can probably run 2 or 3 concurrent encodes

[poisondeathray]

^ jagabo, you know this already, but you would normally run QTGMC first if the source was interlaced (or MCTD interlaced=true)



If anyone is interested, I've been testing vapoursynth 64bit, with QTGMC and various filters . MCTD isn't available natively yet, but you can still run avs scripts in vapoursynth (but you have to run the 32bit version to run 32bit scripts, which negates a lot of the benefit) .

Here are some general observations:

1) The main benefit is memory. Avisynth MT crashes are usually due to memory and 32bit. Especially with multiple fitlers on HD material, it's less of an issue with SD. I haven't had it crash yet with vapoursynth, but it's easy to induce a crash in avisynth MT. But it's still early experiences, so don't take that as a firm conclusion

2) Some filters are much faster in vapoursynth (eg. some MVTools functions are ~200% faster), but some are much slower

3) QTGMC alone is about 15-20% slower in vapoursynth at default settings than avisynth MT, and the faster the preset, the bigger the difference . I though I was doing something wrong, but this seems to be the case for everyone using vapoursynth, even on linux (which is about 2-3% faster than Windows across the board on everything vapoursynth)

4) As soon as you stack filters in avisynth MT (despite playing with different MT modes), there is a more than expected fall off in speed. For example , when QTGMC and smdegrain (since MCTD hasn't been ported yet) (ie. just 1 additional filte added), avisynth MT becomes about 20% slower now than vapoursynth. If you add a few more, it becomes 30-40% slower. It seems the more filters you add, the larger the delta. On large scripts, it can't run in avisynth MT as a single script because of memory issues and frequent crashes