DG NV tools

[Guest]

I just downloaded 2012 from this page and ran dgindex.

If dgindex is not supposed to work without a license, then I am not sure whats going on. LOL.

Does Output trimmed TS work OK on large files? Sure. And if you were to run into any issue I would fix it straight away, as you can see from my responsiveness in this thread.

[Guest]

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+. I've duplicated this and am investigating. A temporary workaround is to trim the end because they are only black frames anyway.

[Guest]

...bug occurs only with DGSource(...) and CUVIDserver. With DGMultiSource is everything OK. Just out of curiosity, is there a reason you can't use DGMultiSource()? I'd really like to deep-six the CUVID server if possible.

[nixo]

There is no trial version.

I'm probably overlooking something here but say someone were to index some publicly available stream, would it not be possible to use that as a sort of a trial stream?

Perhaps if people knew for a fact how dgindexnv would function with their specific GPU, they would be more inclined to donate. Also, it would make benchmarking different cards very easy.

Of course, this is assuming that the license file is only required for the indexer and not for the avisynth plugin.

Note: I already donated a long time ago, so I'm not really looking for a trial. Just a thought, I guess.

--
Nikolaj

EDIT: Understood, Don.

[Guest]

That is indeed possible. But I'm just not interested in supporting trial usage. It's pretty clear that the tools do what they claim to do and I've never had a request for a refund due to non-performance, which I would happily grant in any case.

And I'd prefer not to clutter the thread further discussing it. :)

[kebulek]

Just out of curiosity, is there a reason you can't use DGMultiSource()? I'd really like to deep-six the CUVID server if possible.
No it's not, but from my experiences I have more BSODs with MultiSource than with DGSource... (I really have to try newer drivers...) ;)

And yes, I can trim the end out, but I was not sure, if the green frames are only at the end or they're not. I would like to watch this movie (after encode) without spoiling things out with seeking through and looking for the bad frames... :)

[Guest]

It happens only at end of file so don't worry.

Anyway, use DGMultiSource(). It doesn't do anything differently that would cause more BSOD. And anyway, why have you not reported it? It's highly likely to be a driver issue as you say.

I am seriously considering dropping the CUVID Server, so as they say in church, if anyone objects please step forward.

[rack04]

I am seriously considering dropping the CUVID Server, so as they say in church, if anyone objects please step forward.

I don't object since all I use is DGMultiSource() but don't some GUI's still only work with CUVID Server, i.e. MeGUI, RipBot264?

[Guest]

It was once true but I don't know of any current problems. That's why I am asking.

Anyway, it's not my responsibility to work around bugs in third-party tools. :)

[kebulek]

And anyway, why have you not reported it? It's highly likely to be a driver issue as you say.
I've already wrote you PM... last week or so about BSOD. YouTube video vs DGMultiSource encoding... :) But nevermind, I'll have to find some time to change the drivers.

Which one is current best option for WinXP?

[Alf Bundy]

I am seriously considering dropping the CUVID Server, so as they say in church, if anyone objects please step forward.

Well, Cuvid and DGsource() is the only one working for me.

When I use DGmultiSource(), half the time I get

http://img155.imageshack.us/img155/3516/cuctxcreate.png

or

http://img203.imageshack.us/img203/3033/faileddecoder100.png

It happens when my script is closed by an application and quickly re-opened.

Exemple in VirtualDub : drag& drop the script in VD and redoing it. Normally it should close the script and reload it, but it crashes instead.
Since closing -> reloading is typically what VD does when 2pass or multiple jobs encodes, it's quite problematic.

Exemple in MeGUI : at the end of 1st pass (when second pass should start), the error occurs and MeGUI crashes.
If I restart MeGui & restart 2nd pass, it works but crash again when beginning the next job in queue.

So I can't configure an automated 2pass encode, or multiple jobs in queue to be encoded overnight if I use DGmultiSource().


With Cuvid and DGsource(), it always works fine. :)




I have two machines, and both shows the same problem since I bought a license (01-20-2010)

machine 1 : Win7 x64, intel q9400, nvidia 9800GTX 512Mb (drivers up-to-date - failed also with previous 3 drivers)

machine 2 : Win 7 x64, intel e7400, Nvidia 9400GT 512Mb (drivers up-to-date - ...)



So I would be very annoyed if you drop Cuvid, because I wouldn't be able to do multi-pass or multi encodes anymore
(at least without me in front of my computer waiting for the next crash :p).

[Guest]

Jeez, I wish you people would report this stuff when you run into it, instead of using stupid workarounds when if I know it is happening I can do something about.

Exemple in VirtualDub : drag& drop the script in VD and redoing it. What do you mean by "redoing it"? Specifically, what actions do I have to take to make it happen? I have never seen any issue in VirtualDub with DGMultiSource().

[Alf Bundy]

Sorry for my poor english.
Here a picture showing what I mean :

- First, load the script
http://img294.imageshack.us/img294/4269/dragdrop.jpg
- Then drag & drop the same script on VD's window
- Then drag & drop it again. If you don't wait long enough between two drag & drops, you'll get that :


http://img641.imageshack.us/img641/2705/dragdropfailed.jpg

To be fair, I had to do 3 successives drag & drops to get the error dialog.


Of course there's no reason of doing quick successives drag & drops manually,
but it forces the application to close and immediately reload the script.
And this is exactly what VirtualDub and MeGUI do in case of multi-pass or multi-jobs.


By the way, my script is very simple :

DGmultiSource("E:\Backup Bluray\Ep5\00277.track_4113.dgi",resize_w=1280, resize_h=720)
DegrainMedian(limitY=2,limitUV=3,mode=1)
ConvertToYV12()


Maybe is it related to my Graphic Cards ?
I guess the video memory must be flushed before it can load the next instance of my script,
but the flushing is slower than the attempt of reloading made by MeGUI and VD ???

Graphic cards memory is 512Mb GDDR3

But then, I don't understand why I don't have this problem when using Cuvid and DGsource() ?
And only half the time with DGmultiSource ?


Utimately this is why I didn't complain before.
Cuvid is working for me, DGmultiSource is working for everyone else. Fine. :)

[Guest]

Thank you. Being able to reproduce this outside MEGUI makes it a whole new ball game.

Just to be clear, you don't do play in VirtualDub before dropping again?

[Alf Bundy]

No, just successives drag & drops.

For the first capture I just moved the position cursor to avoid the first black frame of the script (to show that the script was correctly loaded).

[Guest]

I reproduced it using the F2 key (reopen video). For me it is always exactly 11 hits of the F2 key and then failure to create decoder. That suggests that the re-open is not really dismissing the previous instances and GPU memory is being exhausted (although 11 instances seems unlikely). I will investigate further what the re-open is really doing, and what can be done if the previous instances are being kept alive.

How much memory do you have on your GPU?

[Alf Bundy]

512 Mb GDDR3 (on my 9800GTX)

512 Mb GDDR2 (on my GT9400)

[Guest]

I've just extensively checked all my alloc/free stuff and all my CUVID object creation/deletion and it is all AOK. I did some further experiments that strongly suggest a memory leak in CUVID decoder creation/destruction within CUVID. So I have contacted Nvidia about it. This will be really nice to get fixed, as CUVID Server can be retired and DGMultiSource() made bulletproof.

[um3k]

Just thought I'd mention, I have the same "Failed to create video decoder" problem in AvsPmod. Likewise, I have 512 MB memory. Definitely a leak of some sort.

[Sharktooth]

i have a 9500GT video card with 1GB of video memory and did not experience the problem but i also didnt re-open any video 11 times. if it's a memory leak with 512MB cards it obviously happens more often.

[adiabatic]

i have a 9500GT video card with 1GB of video memory and did not experience the problem but i also didnt re-open any video 11 times. if it's a memory leak with 512MB cards it obviously happens more often.

Happens consistently for me on the 8th drag-and-drop of an AVS file involving a 1920x1080i clip with my 896 MB GTX 275.

[Great Dragon]

It happens to me from time to time only if I hit F5 in VDmod or refresh video in AvS.
I have 2 PCs with 8800GTS 512Mb and 8400GS.

[tormento]

I was about posting the same VirtualDub_x64 issue.

If I import an avs with DGMultiDecode_x64, close with CTRL-W, open another, close with CTRL-W, open another -> CRASH of DGMultiSource.

Tested with Quadro FX3300 512MB, Geforce 275 1GB.

The same happens in MEGui_x64, after the third import of AVS.

"Three is the magic number" ;)

[diimaan]

sorry for asking this here!
is there any such DVD2AVI / DGIndex implementation for ATI/AMD cards exist?

[Guest]

sorry for asking this here!
is there any such DVD2AVI / DGIndex implementation for ATI/AMD cards exist? If you are talking about DGDecNV, then refer to the first post of this thread. If you are indeed talking about DVD2AVI/DGIndex, neither of those two run on the GPU, so the question makes no sense.

[diimaan]

ohh, sorry abt the confusion there!

my question was that DGDecNV is for nvidia gpu's!
is there similar tools exist fot ATI gpu's?

[Guest]

Your term "similar" is quite vague, which makes it hard to answer you. I'm not aware of any other Avisynth source filters that use GPU decoding, but I have not looked. I don't know offhand whether CoreAVC can be used with DirectShowSource() in DXVA mode; you would have to ask about that in the CoreAVC thread. In any case, further discussion about tools other than DGDecNV is off topic here, so please take it elsewhere. Finally, you always have the option of running an Nvidia card alongside your ATI card, and using it just for decoding.

[Renzz]

GPU-Z (http://www.techpowerup.com/downloads/) is quite interesting when opening the AVS multiple times in Vdub. Using an indexed MPG2 file, If I look at the GPU memory usage, it starts around 98, and for every press of F2 it increments by between 35 and 45 - but never goes down. I get to around 420MB before I get the error. Using an indexed H264 source, the increments are around 120MB and it fails after it reached 920. This is on a 9800GT with 1GB.

[Guest]

GPU-Z (http://www.techpowerup.com/downloads/) is quite interesting when opening the AVS multiple times in Vdub. Using an indexed MPG2 file, If I look at the GPU memory usage, it starts around 98, and for every press of F2 it increments by between 35 and 45 - but never goes down. I get to around 420MB before I get the error. Using an indexed H264 source, the increments are around 120MB and it fails after it reached 920. This is on a 9800GT with 1GB. Ah, thanks for reporting that! It's the definitive proof I need that CUVID is leaking memory.

[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

[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]

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]

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]

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? :devil:

[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... :confused:

MKV Sample (http://www.mediafire.com/file/r2m2zwo0niy/sample.mkv) (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]

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]

I can't get a string of audio path by using "__aud__". Duplicated. Will fix for next release. Thanks for your report.

[Guest]

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]

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]

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