DG NV tools

[RedDwarf1]

I've noticed that when using DGMultiSource in both AvsP and MeGUI, GPU memory never gets released until the application is closed. Selecting release all videos from memory in AvsP doesn't free GPU memory, only closing the tab or AvsP releases the memory.

If I open a video using AvsP and resize the window to x2, it uses more memory, if I then resize it again either up to x3 or back to x1, more memory is used and so on and so on until the only option is to close AvsP or the tab (script) to release the memory. That's very inconvenient when looking through a video file.

I wasn't certain whether this was purely an AvsP problem but the fact I experienced similar things with MeGUI suggests it's not.

My Video card has 1GB of memory so I have more room for such memory leaks than some but it still gets very severe.

[Guest]

Originally Posted by dgeise

Is there any chance you could support other vendors' GPU products, either by a separate decoder stack or bu using platform-neutral CUDA coding techniques?

If and when the other vendors expose an API for video decoding, it becomes a possibility. That is not the case at this time.

Consider running a secondary Nvidia card only for decoding alongside your main ATI card (if that is what you decide upon).

[Sharktooth]

Originally Posted by dgeise

Hi Don,

I was wondering- the changes to your API function naming scheme seem to be opening a window for supporting 'other' <whisper> non-nvidia </whisper> video cards in the future.

The reason I ask is that I'm starting to look into buying a new computer, and the ATI video cards look to be a better deal from a price/performance/power perspective.

I'm pretty well hooked on your video processing tools, which makes it difficult to switch to different hardware. Your answer may somewhat influence my purchasing decisions, so I'll ask it right out.

Is there any chance you could support other vendors' GPU products, either by a separate decoder stack or bu using platform-neutral CUDA coding techniques?

Since this may be of general interest, I'm asking here on the forum.

Thanks & as always keep up the fantastic work-
- a big fan

CUDA is proprietary, hence supported by nvidia only.
The most probable and logical change would be moving toward OpenCL (that is also very similar to CUDA), but im not Donald, so i dont know what he wants to do and if it is doable.
That said, you should wait for an "official" answer from Donald.

Edit: he was faster than me... so you have your answer.

[dgeise]

thanks for the responses.

maybe I'll stick with nvidia GPUs for the next iteration after all.

[tormento]

Originally Posted by neuron2

Consider running a secondary Nvidia card only for decoding alongside your main ATI card (if that is what you decide upon).

How far is your card selection feature going?

[kebulek]

Originally Posted by kebulek

I've done some testing today and that bug occurs only with DGSource(...) and CUVIDserver. With DGMultiSource is everything OK.

Green frames show up after frame 744+.

Looks like I was wrong. I've encoded whole movie with DGMultiSource and at the end there are 2 bad repeating frames. But before encoding, I didn't see them in VDub...

MKV Sample (2MB)

[OK]

Hello,neuron2

I can't get a string of audio path by using "__aud__".

This situation have been continuing since dgdecnv2015.

I couldn't get dgdecnv2014, so I still use dgdecnv2013.

Dgdecnv2013 is fine, about the situation.

Please check it.

I attached an avs file about the situation.

[Guest]

Originally Posted by kebulek

Looks like I was wrong. I've encoded whole movie with DGMultiSource and at the end there are 2 bad repeating frames.

I'm aware of it because I saw it with your previous sample, even though you said it didn't happen!

Investigating. Use trim until I release a fix. It only happens in some cases at end of file.

[Guest]

Originally Posted by OK

I can't get a string of audio path by using "__aud__".

Duplicated. Will fix for next release. Thanks for your report.

[Guest]

Originally Posted by tormento

How far is your card selection feature going?

It's written on a piece of paper called my "to-do list".

@all

We have good news on the memory leak problem. Nvidia came through yet again in a fabulous manner. My secret contact O told me how to use "floating contexts" to dissociate the CUVID object creation/deletion from the invoking threads. Without that it didn't work because the creation and deletion was done from different threads, which was virtually forced upon me by the Avisynth architecture.

Now I can hit F2 in VirtualDub until the cows come home.

Say your goodbyes to the CUVID Server. He has served us well but must now move on to the quantum vacuum. May he serve in peace.

A test version is imminent.

@OK

Your bug is fixed.

@kebulek

You're up next.

[Lyle_JP]

WooHoo! This memory leak was my biggest complaint as well, though I never brought it up neuron2 because I was never sure if it wasn't Avisynth x64's fault.

[tormento]

If there will be no more MEGUI/VDub errors I think there should be another imminent donation

[kebulek]

I've got another mystery - just made some testing with XviD and picture resizing directly with DGTools.

LoadPlugin("C:\Program Files\DGTools\DGMultiDecodeNV.dll")
DGMultiSource("E:\video.dgi", deinterlace=1, resize_w=624, resize_h=352).Trim(0,153290)

With this script, I'm able to open the .AVS only once in VD. Another try (with proper close and re-open) failed and VD freezed.

LoadPlugin("C:\Program Files\DGTools\DGMultiDecodeNV.dll")
DGMultiSource("E:\video.dgi", deinterlace=1).LanczosResize(624,352).Trim(0,153290)

With this script works everything fine.

So is there something wrong with internal resize or it's a VD bug?

[mikeyakame]

@Neuron2

That is awesome news about the memory leak being fixed! It definitely means no more need to use DGSource to prepare a video!

[meatwad]

Can someone using StaxRip 1.1.6 confirm that build 2019 is working fine with it? I'm having some problems getting it to work with it, but I'm pretty sure it's an error on my part somewhere.

[tormento]

Originally Posted by meatwad

Can someone using StaxRip 1.1.6 confirm that build 2019 is working fine with it?

I jumped on MeGui wagon. I suggest you to do the same as it is much more complete and you can train to use it as in near future I suggest you to use the x64 version too. It is much faster and stable.

[Groucho2004]

I'm a bit at a loss here. Why do people use these buggy "GUIs" when the DG tools do (almost) everything for them already? All that has to be done in most cases is to feed the script into the encoder.

I'll try to keep my opinion about the "GUI designers" to myself, many of them don't know squat about programming that goes beyond putting some fancy dialogs together in Visual Basic.

So, what am I missing? Is it really so hard to create a batch file (considering the countless examples that can be found here on Doom9)?
Or is it about calculating the bitrate? Multiplexing?

Just curious.

[tormento]

Originally Posted by Groucho2004

I'm a bit at a loss here.

Personally I edit the avs by hand BUT I can't remember every x264 switch I need AND I can't stay at home to manually wait to launch the next job.

To sum things up: create x264 command line and batch it. Stop.

[Guest]

General discussion of GUIs is off topic here. Thank you.

[MOS-Marauder]

Well if i prepare my Cue with MeGui (latest Dev Build and DGTools NV 2019) and DONT use Cuvid Server it crashes badly on after adding to cue and trying to create the 2nd AVS with the AVS Script Generator. DGMultiSource isnt yet working good. if i check "use Cuvid Server" all is working as expected.
Also.. if one AVS using DGMultisource is playing in Mediaplayer i cannot open another one (Cuvid Deode error, no video...crashing BOTH then)..


Edit: Ahem sorry for mentioning "the GUI".. but in fact it also happens w/o it...


Chris