Support forum for DG Tools

Nice, thank you, aceado.

I had a lot higher GPU utilization because I used a 4K stream.

You can see from the video that you get a very high frame rate, despite the relatively low GPU use, which illustrates the point I made about it. All that remaining GPU is available for your encoding, if you have a workflow that can use it.

aceado wrote:the first thing you need to understand is the first picture is showing that its using the NVENC which is the builtin hardware encoder so yes it will be faster....
best way to find out if it is using gpu to the fullist is to load up a video directly into dgnv itself goto video > disable display then click play if your fps is around ~700 fps then its all fine since this is showing you how fast and able your 1070 is at decoding however in the pictures above its showing your only encoding at 32 fps which is why you would be seeing ~6% video useage

1257 fps is awesome for 720p video. I get 338 fps for 720p on my GT 620.

I ask that you do not discuss torrent files here. Please use public-domain files or files from legitimately owned sources. You put my forum at risk otherwise. Full HD or 4K will give you better insight into performance. Thank you.

admin wrote:1257 fps is a pretty decent frame rate for 720 video. I get 338 fps for 720p on my GT 620.

I prefer that you do not discuss torrent files here. Please use files you rip from legitimately owned sources. Full HD or 4K will give you better insight into performance. Thank you.

ok sorry ,


It would not be possible to use or add NVENC to DGIndexNV, or something imposible¿?

as you can see from both the video that i posted and the picture you have shown there is some sort of bottleneck
the decoding the video isn't your issue here nor is it the bottleneck the main issue is normally down to how fast the cpu is able encode it at which for alot of users this would be the case since we can't encode at since a high rate same as the decoding speed nevermind 200 fps lol (maybe for really low res video)

aceado wrote:as you can see from both the video that i posted and the picture you have shown there is some sort of bottleneck
the decoding the video isn't your issue here nor is it the bottleneck the main issue is normally down to how fast the cpu is able encode it at which for alot of users this would be the case since we can't encode at since a high rate same as the decoding speed nevermind 200 fps lol (maybe for really low res video)

aceado, that processor and motherboard you have?

pacoor wrote:It would not be possible to use or add NVENC to DGIndexNV, or something impossible?

DGDecNV is a decoding application. I am not interested in making a full transcoding application.

What you should do is see if BDRebuilder can use NVENC for the encoding part of the process. I emphasize this because you do not seem to have realized the importance of this point about decoding versus encoding.

aceado is quite correct that decoding is almost always a small part of the overall load. Quite often I get emails expressing disappointment that DGDecNV has not significantly accelerated transcodes (transcoding means decoding plus encoding together). But I have always claimed that it can do so only when the encoding load is small, such as for low-resolution videos and minimal filtering. The desirable advantages of DGDecNV lie in other areas, such as robust random frame access, access to HW post-processing, consistent handling of different video types, diverse container support, etc.

pacoor wrote: aceado, that processor and motherboard you have?

the cpu and the motherboard wouldn't matter for encoding as for encoding videos even if its 6, 8 or even 10 cores there's still gonna be the same result of the bottleneck being the cpu not being able to keep up with the decoding speed of the gpu i'm 100% sure admin will fully agree on this

Can't fully agree with that, perhaps because you did not express yourself clearly. If the encode is done in the CPU, then obviously a better CPU/more cores can increase transcoding performance. Maybe you meant it can't increase specifically the GPU decoding performance (or perhaps only trivially), which I do agree with.

The error is that he tries to use 64-bit meter with 32-bit Avisynth installed. I add that because it is only implicit in your post, and perhaps he doesn't realize the two have to match, even though I have previously told him that everything must be in 64-bit for a 64-bit workflow.

Of course everything you say about getting the right Avisynth installed is spot on.

Ah, yes, I missed that.

If I have avs+ 32-bit installed and run AVSMeter64, I get the same error messages the OP posted. What did you do to get what you showed?

Groucho2004 wrote:

admin wrote:If I have avs+ 32-bit installed and run AVSMeter64, I get the same error messages the OP posted. What did you do to get what you showed?

1. Cleanup*
2. Installed r2085 32 bit

Maybe you have a stray avisynth.dll somewhere in a directory to which your PATH environment variable points?

*"Cleanup" means:
- delete every instance of avisynth.dll and devil.dll from directories to which the PATH environment variable points
- clean the registry from everything related to Avisynth

There is however something wonky about that installer. If you install 32 bit and 64 bit in one go, everything is fine. If you install 32 bit and 64 one after another, the auto-load pointers are screwed.
I much prefer using my Avisynth switcher which gives me full control over the install and uninstall and has never failed.

hello god

It would not be possible for you to create a autoinstaller with everything needed by default?

Nope, no stray DLLs in PATH paths. I use my own switcher that doesn't touch the registry (I never use plugins dir). I just copy the needed DLL as needed to the one directory that I made and which is given in the PATH. Perhaps that is the cause. I don't know what is in the registry (probably left over from an install of the past) but obviously there is enough for things to be working fine. Kinda kludgy I'm sure but it lets me switch between 32 and 64 bit Avs+ DLLs.

EDIT: My registry has stuff for Avs+ r1576 32-bit.

Anyway, let's not worry about it. Let's help pacoor.

Anon17 wrote:

pacoor wrote:It would not be possible for you to create a autoinstaller with everything needed by default?

Have you tried what I suggested?

yes Anon17 but ,if it does not work I do not know if will be a thing of Windows 10 x64, but I can not run, and if I change files avisynth, bdrebuilder stops working properly.

https://www.doom9.org/showthread.php?t=143716

no no Anon17, not work, also if I install avisynth+ 2085 stops working bdrebuilder running avisynth 2.60

Anon17 wrote:

admin wrote:I just copy the needed DLL as needed to the one directory that I made and which is given in the PATH. Perhaps that is the cause.

Yes, it is. You would not get the error message if you had the DLL in SysWOW64 (where it should be, at least if you want to use both, 32 and 64 bit).

I don't use the system directories at all. I just have a user folder that PATH points to.

To be clear, I expect that error message when I have the 32-bit DLL in the folder and I then try to run AVSMeter64. But I thought you said I should get a different error like you did. Maybe we discuss different scenarios.

Sure, but you gave a different error message and expressed surprise. I suppose we discuss different scenarios. Let's let it go.

Anon17 wrote:

pacoor wrote:https://www.doom9.org/showthread.php?t=143716

no no Anon17, not work, also if I install avisynth+ 2085 stops working bdrebuilder running avisynth 2.60

Hm, this could take a while. Let's see if I get it right this time:

1. You had BD Rebuilder working with Avisynth 2.6
2. You installed Avisynth+ and BD Rebuilder stopped working

Are any of these statements correct? Both?

hello

1 bdrebuilder with Avisynth 2.6 and avsmeter, it does not work

2 Avisynth+ and BD Rebuilder stopped working and avsmeter it does not work

You're still being unclear. You haven't told us what *was* working, only what doesn't work now. Just to be clear in case you are confused, talking about BDRebuilder working or not working with AVSMeter makes no sense.

I recommend you to contact jdobbs for support of BDRebuilder, as I do not support third-party tools here. I can tell you that hundreds or thousands of people use BDRebuilder successfully with Avs+/DGDecNV. Yes, my user base is that large.

admin wrote:You're still being unclear. You haven't told us what *was* working, only what doesn't work now. Just to be clear in case you are confused, talking about BDRebuilder working or not working with AVSMeter makes no sense.

I recommend you to contact jdobbs for support of BDRebuilder, as I do not support third-party tools here. I can tell you that hundreds or thousands of people use BDRebuilder successfully with Avs+/DGDecNV. Yes, my user base is that large.

after instalation Avisynth + r2085 , bd rebuilder no It doesn't work Donald.

I don't think that is true. I will install BDRebuilder myself to test it with Avs+.

OK, BDRebuilder requires 32-bit tools.

I only just found out that BDRebuilder is made for 32-bit stuff.

Apparently there is a 64-bit BDRebuilder but support for 64-bit filters appears to be spotty. You'll have to ask jdobbs about it. At least you are not alone. I don't see the reason for this limitation.