[RESOLVED] Is NVIDIA NVS 5400M Supported?

[LouieChuckyMerry]

Hello and thanks in advance for your help . I bought a license (thanks!) and have been running tests, but I'm experiencing zero improvement in encoding speed between DGDecNV.dll-DGSource-based scripts and DGDecode.dll-DGDecode_mpeg2source-based scripts, with AVSMeter (thanks Anon17!) showing 0% GPU usage for the DGIndexNV-created scripts. I'm running Windows 7 64 bit with an NVIDIA NVS 5400M card (http://www.nvidia.com/object/nvs_techspecs.html). Perhaps I'm missing something (wouldn't be the first time ) with DGIndexNV or I'm mistaken thinking that my GPU qualifies? I've tested with version 2049 and version 2041, and the (lack of) results are the same. Any answers are greatly appreciated, thanks for your time.

[admin]

If DGDecNV produces video on that adapter, then it is working.

DGDecNV does not use the GPU, it uses the VP engine. So low GPU usage is expected.

Whether or not you get a speedup for your transcode depends on several factors. Most important is the intensity of the scripting and encoding load. If it is very high then the decode time becomes insignificant and you will see little to no speedup. I have never touted DGDecNV for speedup in such use cases, even though it is significant in some use cases. I tout other things, such as frame accuracy, proper handling of pulldown, interlacing, etc., and consistent handling for AVC, MPEG2, and VC1.

If you want to tell us more about your use case (scripts, streams, etc.), we can comment further. One thing to do is use AVS meter to compare the CPU usage when just decoding (use a minimal script). Any reduction in CPU usage will be available for your processing and encoding.

Looking at the script you posted I have to say that you appear to suffer from major filteritis (over-use of filters to the point of pathology). For example, three different TFM invocations in a row is just, forgive me, insane! Your intense filtering together with your encoding will make decoding gains insignificant. I would advise you to reduce your filtering to a reasonable amount. Processing and time are a tradeoff and you must decide how much you like to pay in time for the gains you get from filtering. Make sure you are really getting gains from all that filtering; don't apply a filter just because it exists and you think it would be cool to use it.

[LouieChuckyMerry]

If DGDecNV produces video on that adapter, then it is working.

D'oh!

DGDecNV does not use the GPU, it uses the VP engine. So low GPU usage is expected.

Whether or not you get a speedup for your transcode depends on several factors. Most important is the intensity of the scripting and encoding load. If it is very high then the decode time becomes insignificant and you will see little to no speedup. I have never touted DGDecNV for speedup in such use cases, even though it is significant in some use cases. I tout other things, such as frame accuracy, proper handling of pulldown, interlacing, etc., and consistent handling for AVC, MPEG2, and VC1.

If you want to tell us more about your use case (scripts, streams, etc.), we can comment further. One thing to do is use AVS meter to compare the CPU usage when just decoding (use a minimal script). Any reduction in CPU usage will be available for your processing and encoding.

Thanks for the clarification and suggestion. It seems that my very limited understanding of DGDecodeNV was even more limited than I'd thought . Have you ever tried using DGDecodeNV with SEt's AviSynth MT? If so, were you able to succeed? I ask because, after much testing, I'm able to stably use FFMS2 and LSMASHSource with MT AviSynth, but stable settings for DGDecode have thus far eluded me (I haven't tried with DGDecodeNV yet).

Looking at the script you posted on Doom9 I have to say that you appear to suffer from major filteritis (over-use of filters to the point of pathology). For example, three different TFM invocations in a row is just, forgive me, insane! Your intense filtering together with your encoding will make decoding gains insignificant. I would advise you to reduce your filtering to a reasonable amount. Processing and time are a tradeoff and you must decide how much you like to pay in time for the gains you get from filtering. Make sure you are really getting gains from all that filtering; don't apply a filter just because it exists and you think it would be cool to use it.

The three different TFM invocations were originally for the occasional case where my source suffers from field blending. Since this change to the script doesn't seem to change the encoding speed from the original "TFM(Order=0 or 1,Slow=2,PP=0).TDecimate(Mode=1)", I decided to use it for every episode so as to avoid potential reencoding of botched episodes.

As for the rest of the script, I wish that I could take full credit but that's not the case. When it comes to AviSynth I'm still in primary school (but hoping to graduate and enter middle school soonish). The core of that script came from some patient help here, based on this Test Clip. As of now my script is:

Code: Select all

# Set DAR in encoder to 6480 : 4739. The following line is for automatic signalling
global MeGUI_darx = 6480
global MeGUI_dary = 4739
SetMemoryMax(256)
SetMTMode(3,3)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\ffms\ffms2.dll")
FFVideoSource("SourcePath", fpsnum=30000, fpsden=1001, threads=1)
### Deinterlace ###
SetMTMode(5)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\avisynth_plugin\TIVTC.dll")
TFM(Field=0,Mode=5,PP=1,Slow=2,CThresh=4)
TFM(Field=1,Mode=5,PP=1,Slow=2,CThresh=4)
TFM(Order=-1,Slow=2,CThresh=4)
TDecimate(Mode=1,Cycle=15,CycleR=3)
SetMTMode(2)
Vinverse()
### Deshaker ###
Stab(Mirror=15)
### Crop ###
Crop(8,0,-8,0)
### Resize ###
RatioResize(10/11.0,"PAR")
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",thY1=20,thY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor")
MT_Merge(dfttest(),Mask,Luma=True)
### Overall Temporal Denoise, Could Probably Be Optimized ###
SMDegrain(tr=2,thSAD=600,ContraSharp=True,RefineMotion=True,Plane=0,Lsb=True,Lsb_Out=True,PreFilter=2)
### Debanding ###
GradFun3(thR=0.55,Radius=12,Mask=2,SMode=1,Lsb=True,Lsb_In=True, StaticNoise=True,Y=3,U=3,V=3)
DitherPost(Stacked=True,Prot=False,Mode=0)
### Line Darkener And Thinner ###
FastLineDarkenMod(Strength=20,Prot=6,Thinning=0)
aWarpSharp2(Blur=4,Type=1,Depth=3,Chroma=2)

which peaks at ~2.40 fps (a little under four hours per episode) on my i5 3320M-8GB RAM setup and to my eyes produces excellent results, relative to the source quality, using 10-bit x264 at CRF 13.0. As I typed above my knowledge of AviSynth is quite limited. If you're so inclined then, please, make suggestions for improvement. All well-intentioned ideas are always welcome and much appreciated. Ahhh, and thank you very much for straightening me out with regards to DGDecodeNV .

[admin]

Sorry to say, but your justification for the multiple TFMs is still incoherent to me. First, that is not a good approach for dealing with blending, and second, doing it unconditionally for all videos is just plain wrong. If you are cooking a dish for someone are you going to use all possible spices because you're not sure which ones your guest will like? Your filtering load is extremely high; you won't find a magic bullet to significantly speed it up. You have to decide which of all that filtering you really need if you want to significantly speed things up.

DGDecNV uses HW for decoding so you will not be able to profitably multithread it; there is only one VPU. In any case, the single threaded decode rate is hundreds of frames per second, so multithreading it won't significantly speed things up, given your processing load. You can multithread the rest of your script, however. Multithreading a source filter requires robust frame accuracy (especially when you have a lot of nonlinear access), so watch out when you try to multithread SW source filters, they are not all frame accurate. Disclaimer: I do not use multithreading so you may get better advice about it at Videohelp. In my view, rather than multithreading, it's better and more robust to cut your source into segments and launch a separate process for each segment. But that is controversial.

[LouieChuckyMerry]

Sorry to say, but your justification for the multiple TFMs is still incoherent to me. First, that is not a good approach for dealing with blending, and second, doing it unconditionally for all videos is just plain wrong. If you are cooking a dish for someone are you going to use all possible spices because you're not sure which ones your guest will like? I suggest Doom9 for discussions about optimizing your scripts, as I prefer to limit my forum specifically to support of my tools. I see you already have a post there about it (you'd probably get better responses with a separate thread, however). Your filtering load is extremely high; you won't find a magic bullet to significantly speed it up. You have to decide which of all that filtering you really need if you want to significantly speed things up.

I purchased a license hoping for an increase in encoding speed because I misunderstood how DGIndexNV-DGIndexDecode worked (next time I'll do more research ); no worries, by all accounts I've read it's great and I'm sure it'll utilize it at some point. As for the script, I'll happily take your advice and start a new thread on Doom9, thanks. I honestly don't care so much about speeding things up, but I trust your judgement that it's redundant and can be streamlined. Please contribute your two (or four or six) cents worth .

DGDecNV uses HW for decoding so you will not be able to profitably multithread it; there is only one VPU. In any case, the single threaded decode rate is hundreds of frames per second, so multithreading it won't significantly speed things up, given your processing load. You can multithread the rest of your script, however. Multithreading a source filter requires robust frame accuracy (especially when you have a lot of nonlinear access), so watch out when you try to multithread SW source filters, they are not all frame accurate. Disclaimer: I do not use multithreading so you may get better advice about it at Doom9. In my view, rather than multithreading, it's better and more robust to cut your source into segments and launch a separate process for each segment. But that is controversial.

Thanks for the information about hardware and software decoding. Before I figured out how to use MT AviSynth stably with FFMSIndex and L-SMASH Works I would run two episodes simultaneously to up production. Given that there's only one VPU, would you recommend using DGDecodeNV to process multiple segments simultaneously or would DGDecode be a better option for this? I still haven't figured out how to multithread DGDecode...

[admin]

Given that there's only one VPU, would you recommend using DGDecodeNV to process multiple segments simultaneously or would DGDecode be a better option for this? I still haven't figured out how to multithread DGDecode...

It won't make any difference. The decode rate is so high compared to your processing that multithreading the source filter will not bring significant gains. On the other hand, I'm pretty sure you can multithread DGDecode9.

[LouieChuckyMerry]

Given that there's only one VPU, would you recommend using DGDecodeNV to process multiple segments simultaneously or would DGDecode be a better option for this? I still haven't figured out how to multithread DGDecode...

It won't make any difference. The decode rate is so high compared to your processing that multithreading the source filter will not bring significant gains. On the other hand, I'm pretty sure you can multithread DGDecode; best to ask about that at Doom9.

Thanks. And thanks for taking the time to answer all my questions, I really appreciate it . Ahhh, if you've any interest: MyThread