View Full Version : DG NV tools
Guest
11th July 2010, 13:17
@kebulek and MOS-Marauder
With my current floating context build, I cannot duplicate your multiple instantiation issues. Please wait for a test version that I plan to release today.
Chefkoch_ico
11th July 2010, 13:40
I can't get a string of audio path by using "__aud__".
Duplicated. Will fix for next release. Thanks for your report.
Hi,
I just switched from DGAVCDec to the NV Suite and noticed the same.
DGAVCDec gave me block artefacts and the NV Suite makes the picture perfect, so I am looking forward for the new version so I can use my scripts again.
Thanks for your great software.
Best regards
rajs
11th July 2010, 14:24
Couple of feature requests:
1. Add a debug option (like 'info=1' in DGMPGDec).
2. Have an option to auto-resize pixels based on the aspect ratio info in the video stream (if present), i.e.
aspect_ratio_information in a MPEG2 stream
apect_ratio_idc parameter in a H.264 stream
ASPECT_RATIO syntax element in VC-1.
I'd like to add another one - Show the frame number of the frame currently being displayed in the DGIndexNV viewer. (I.e. display some text like "Frame nnnn of mmmm".)
rajs
11th July 2010, 14:32
Just want to point out a minor bug - when outputting a trimmed TS, the tool does not add the extension ".ts" to the name given in the save dialog box.
(v2019 running under Win7)
Guest
11th July 2010, 14:51
Just want to point out a minor bug - when outputting a trimmed TS, the tool does not add the extension ".ts" to the name given in the save dialog box.
(v2019 running under Win7) It's not a bug and has already been discussed.
Regarding your other requests:
1. Info overlay. It's on my to-do list.
2. Resizing. I won't do that. Do it in your script.
3. Not possible as DGIndexNV does not have an index. Only the source filters know the frame numbers, because DGIndexNV creates the index that they use.
Guest
11th July 2010, 15:15
Here is a test version for the floating context version. Please advise of your test results.
This also fixes the __aud__ bug.
http://neuron2.net/misc/DGDecNVfloating.zip
MOS-Marauder
11th July 2010, 15:51
Here is a test version for the floating context version. Please advise of your test results.
This also fixes the __aud__ bug.
http://neuron2.net/misc/DGDecNVfloating.zip
Looks good.. first tests with "the Gui" dont result in a crash.
Chris
kebulek
11th July 2010, 16:07
Here is a test version for the floating context version. Please advise of your test results.
http://neuron2.net/misc/DGDecNVfloating.zip
Well first 3 re-opens were good, but at 4th VDub freezed again. :(
EDIT: 2nd try freezed at 6th re-open.
It's better :) - but not perfect.
Guest
11th July 2010, 16:45
@kebulek
I don't see any such problems. If you want support, you'll have to provide everything I need to duplicate it. Stream, scripts, detailed steps to reproduce.
Guest
11th July 2010, 16:53
Looks good.. first tests with "the Gui" dont result in a crash. You can mention GUIs by name and discuss their compatibility with DG tools. I just don't want general discussion like "GUIs suck, no they don't".
stax76
11th July 2010, 17:05
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.
I'm using NV tools regularly so yes I can confirm 1.1.6 works with 2019. Please first try to open the source file manually in DGIndexNV, if it's working then examine the command line executing it manually, GUIs write executed scripts and command lines to log files.
That should open the source:
-i "D:\aaa.h264"
That should open the source and start indexing:
-i "D:\aaa.h264" -o "D:\aaa.dgi"
Easy! :)
MOS-Marauder
11th July 2010, 17:19
You can mention GUIs by name and discuss their compatibility with DG tools. I just don't want general discussion like "GUIs suck, no they don't".
Ok. It would make no sense to Discuss about something not related to the DGToolsNV ;)
Chris
kebulek
11th July 2010, 17:19
@kebulek
I don't see any such problems. If you want support, you'll have to provide everything I need to duplicate it. Stream, scripts, detailed steps to reproduce.
Try that with my old sample:
http://www.mediafire.com/file/fomnzzyykmw/sample.ts
And with this .AVS:
LoadPlugin("C:\Program Files\DGTools\DGMultiDecodeNV.dll")
DGMultiSource("E:\video.dgi", deinterlace=1, resize_w=624, resize_h=352)
At home, I've got currently 6GB .ts with this script:
LoadPlugin("C:\Program Files\DGTools\DGMultiDecodeNV.dll")
DGMultiSource("E:\video.dgi", deinterlace=1, resize_w=640, resize_h=480)
Action: VDub -> open .avs, seek somewhere, close .avs -> open .avs, seek somewhere, close .avs etc... :)
Sometimes VDub freezes after 2nd-4th try and sometimes after 10th or more - I don't understand it. :(
When I close freezed VD and open new one, everything is alright again until Xth try...
Guest
11th July 2010, 17:27
I cannot duplicate it.
Have you monitored the GPU memory use using GPU-Z?
My driver version is 257.21. What is yours?
Hi,neuron2
I verified the bug was fixed.
Thanks a lot.
I honor you every time.:)
Alf Bundy
11th July 2010, 18:50
Hi,
My result with the test build :
- Sample file used : 50Mb (30sec) .mts from my Lumix FZ35/38
http://dl.dropbox.com/u/2137721/00001.MTS
- Script used :
DGmultiSource("C:\Users\Alf\Downloads\DGNV testbuild\test 00001.dgi",deinterlace=1)
AssumeFPS(25)
ConvertToYV12()
- Here's my GPU specs : Driver is WHQL 257.21, Memory = 512Mb
http://img341.imageshack.us/img341/3943/gpuspecs.png
After a reboot, video memory is 91Mb.
And here's what happen when I load my script in VD :
Initial load = 189Mb
1st reload (F2) = 262Mb
2nd reload = 334Mb
3rd reload = 406Mb
4th reload = 478Mb
5th reload -> code (100) error in VD -> crash
After VD's crash, video memory goes back to 91Mb
http://img718.imageshack.us/img718/5192/driver257load.png
Hope it helps.
Don't hesitate to ask if you need other tests/precisions.
kebulek
11th July 2010, 19:13
I cannot duplicate it.
Have you monitored the GPU memory use using GPU-Z?
My driver version is 257.21. What is yours?
Still the same: WinXP SP3, GF 9600GT 512MB with 191.07.
Weird is, that when I do the same with F2, I can reload the whole movie X times and everything works fine. :)
GPU-Z: 47MB before load, 187MB after load, when I hit F2, it goes to 205MB shortly and then again 187MB. After close it's again 47MB. And when it freeze, it goes to 92MB.
I can send you a Dr. Watson report after VDub crash, if you want. "ErrorText=The program is not responding. etc..." :)
Guest
11th July 2010, 19:14
@Alf Bundy
I cannot duplicate it with your stream and script.
Are you ABSOLUTELY sure you load the correct DLL? You have no loadplugin in your script so...
What versions of Avisynth and VirtualDub?
@kebulek
A VirtualDub crash is not a memory leak issue. Yes, give me the dump and tell me the Avisynth and VirtualDub versions.
Also, if possible, upgrade your driver to 257.21 and try again.
tormento
11th July 2010, 19:18
@neuron2
Do you mind compiling a x64 version? Would like to test even in "my" environment.
Thanks ;)
Alf Bundy
11th July 2010, 19:19
Well, all files were within the same folder.
The sample video, DGNV testbuild (with it's dll), the dgi created and the avs script generated from my template.avs.
I test it again with the loadplugin() .....
Guest
11th July 2010, 19:22
Avisynth and VirtualDub versions needed please.
Alf Bundy
11th July 2010, 19:28
My bad neuron2 :o
after adding LoadPlugin(path\DGmultisource.dll)
Errors are gone !
I did 32 reloads (F2), and video memory remained at 192Mb. Juste like it was with the initial load of the script.
I'm sorry, I tought I didn't need the loadplugin() since everything was in the same folder.
Now it's working flawlessly.
You're a genius. :thanks:
Guest
11th July 2010, 19:29
Thanks for the update and positive test results.
Now we need to figure out what is happening for kebulek. I don't think it is the memory issue.
@tormento
2020 is imminent. Patience is a virtue. :)
tormento
11th July 2010, 20:09
Torment can be a pleasure ;)
Thanks pal.
kebulek
11th July 2010, 20:54
A VirtualDub crash is not a memory leak issue. Yes, give me the dump and tell me the Avisynth and VirtualDub versions.
Also, if possible, upgrade your driver to 257.21 and try again.
Avisynth: 2.58, build: Dec 22 2008 [08:46:51]
VirtualDub 1.9.4
And right now, I can't duplicate the freezing, so I can't give you the dump... Weird. :( Let it go for now, I'll do some testing tomorrow.
Guest
11th July 2010, 21:28
OK, thanks. It's probably not related to the memory leak issue so I will go ahead and release 2020 and we'll revisit your issue as needed.
Regarding your bad EOF case, I am thinking you have an incomplete picture at the end, but I'm still investigating. I haven't seen it on any other streams. Have you?
Chefkoch_ico
11th July 2010, 21:56
Just before you release the next version, not only "__aud__" is only substituated with empty string, "__del__" is not substituated at all.
Best regards
Alf Bundy
11th July 2010, 22:13
It's working for me with the testbuild.
My template :
video=DGSource("__vid__") ## ,fieldop=0,deinterlace=1,resize_w=1280, resize_h=720
audio=WavSource("__aud__")
AudioDub(video,audio)
DelayAudio(__del__)# in seconds -> for ms -> (0.000)ms
ConvertToYV12()
Generated script :
video=DGSource("C:\Users\Alf\Downloads\DGNV testbuild\00001.dgi") ## ,fieldop=0,deinterlace=1,resize_w=1280, resize_h=720
audio=WavSource("C:\Users\Alf\Downloads\DGNV testbuild\00001 PID 1100 2_0ch 48KHz 192Kbps DELAY 0ms.ac3")
AudioDub(video,audio)
DelayAudio(0.000)# in seconds -> for ms -> (0.000)ms
ConvertToYV12()
:confused:
kebulek
11th July 2010, 22:24
OK, thanks. It's probably not related to the memory leak issue so I will go ahead and release 2020 and we'll revisit your issue as needed.
Regarding your bad EOF case, I am thinking you have an incomplete picture at the end, but I'm still investigating. I haven't seen it on any other streams. Have you?
No, but time will tell... :)
And maybe I found something. I know, you always telling people not to play another video, while encoding with DGNV. ;) But when I open in MPC some .mkv x264 hd video (using CoreAVC 2.0 without CUDA support & AC3filter), pause it and then open dgmultisouce .avs in VDub -> it freezes everytime... :(
Chefkoch_ico
11th July 2010, 22:55
It's working for me with the testbuild
:confused:
Sry, I have only looked on the website for a new version, not in the thread.
Thx for the fast bugfix.
Guest
11th July 2010, 23:10
And maybe I found something. I know, you always telling people not to play another video, while encoding with DGNV. ;) But when I open in MPC some .mkv x264 hd video (using CoreAVC 2.0 without CUDA support & AC3filter), pause it and then open dgmultisouce .avs in VDub -> it freezes everytime. I can't duplicate it. Given your other problems it sounds like there is something goofy with your system.
Guest
11th July 2010, 23:43
* Revised DGMultiSource() to use floating CUVID contexts so that it no longer leaks GPU memory.
This should enable use in all GUIs without the dreaded decoder creation failure or crashes.
* Due to the fix above, CUVID Server and DGSource() are no longer necessary
and are therefore retired and omitted from the distribution.
* Added an error popup for VC1 streams that erroneously contain sequence headers
not followed by an I frame (as required by spec). If you run into this please let me
know.
* Fixed a regression in pulldown detection for VC1.
* For AVC, POCs are now stored in the DGI file as they appear in the stream, i.e., they
are not divided by two.
* Fixed a regression in expansion of the __aud__ and __del__ macros for script generation.
http://neuron2.net/dgdecnv/dgdecnv.html
RedDwarf1
12th July 2010, 01:18
Thank you. The new version is working much better with none of the GPU memory problems which makes it far more usable for me.
I can refresh the script and resize the preview without having to keep one eye on GPU-z for memory usage and keep closing AvsP all the time.
Guest
12th July 2010, 01:30
Good to hear, RedDwarf1, and thank you for your test results.
I cannot say enough good things about Nvidia support.
RedDwarf1
12th July 2010, 02:19
Good to hear, RedDwarf1, and thank you for your test results.
I cannot say enough good things about Nvidia support.
nVidia do offer good support, I have read through your development notes on your site and the support is exceptional.
It's a pity ATI don't offer such support because no matter how good their GPU's are, without developers writing the software for their GPU chipsets, they are a poor choice compared to nVidia for anyone who wants to do anything serious.
meatwad
12th July 2010, 04:27
I'm using NV tools regularly so yes I can confirm 1.1.6 works with 2019. Please first try to open the source file manually in DGIndexNV, if it's working then examine the command line executing it manually, GUIs write executed scripts and command lines to log files.
That should open the source:
-i "D:\aaa.h264"
That should open the source and start indexing:
-i "D:\aaa.h264" -o "D:\aaa.dgi"
Easy! :)
Thanks Stax! That was the problem. The default setting needs to have the -y 1 removed. Here's what StaxRip 1.1.6 has:
-i %source_files_comma% -y 1 -o "%working_dir%\%source_name%.dgi" -a -e.
I knew it had to be something simple.
tormento
12th July 2010, 06:31
Today I'll feed some memory intensive jobs to your newer version.
I cannot say enough good things about Nvidia support.
Yep, just waiting for a less hungry Fermi.
Sulik
12th July 2010, 07:06
Yep, just waiting for a less hungry Fermi.
I think I just found a replacement for my 8800GT
http://www.anandtech.com/show/3809/nvidias-geforce-gtx-460-the-200-king/4
rack04
12th July 2010, 13:13
I can't get DGDecNV to ignore the vc1 pulldown from the following file.
Here is a sample (http://www.mediafire.com/?yghnmlj01mo)
It is a vc1 stream extracted from HD DVD using eac3to with -keepPulldown option.
I have tried 2019 and 2020 and both are unsuccessful.
Here is my script:
LoadPlugin("C:\Program Files\DGDecNV\DGMultiDecodeNV.dll")
DGMultiSource("C:\Personal\Videos\sample_pulldown.dgi", fieldop=2)
Guest
12th July 2010, 13:33
You chose ignore pulldown. That will cause the pulldown to not be honored (you can see that because there are no combed frames with fieldop=2) but the frame rate will not be changed. What you should use is force film (fieldop=1). It's all explained in the manual.
If the pulldown is constant pure 3:2 then it is the case that you can get the same result as force film by using ignore and AssumeFPS(23.976) in your script.
RedDwarf1
12th July 2010, 17:52
Today I'll feed some memory intensive jobs to your newer version.
Yep, just waiting for a less hungry Fermi.
Why not just get a GT240 GDDR5 1GB? I have a Zotac GT240 GDDR5 1GB card with 4GHz Samsung memory chips which overclock quite well, 3400MHz default and overclock to 4GHz quite easily using Zotac Firestorm. But memory bandwidth has never been an issue as it has never gone over 20% so far.
The Zotac card is a single slot card so leaves more expansion slots free than dual slot designs.
Fermi and GT 240 are meant to share the same VP engine, it's only Gaming or GPU encoding that Fermi would benefit and GPU encoding has been a waste of time so far, plus the improved audio output if that was needed on a PC. So why spend large sums on cards that are largely unnecessary?
I think a comparison of cards decoding capabilities and speeds would be beneficial. If suitable clip(s) could be found to be used for comparing cards.
I wonder whether there has been any speed improvement in the VP engine in recent nVidia cards like has been suggested.
How about it? Are you up for it?
Guest
12th July 2010, 19:36
How about it? Are you up for it? Who, me? I can't afford to buy all those different cards. :)
VP engine clock rate and memory bandwidth are the specs to compare. We could all post our card and what the Nvidia control panel shows for those specs.
My card at work (my home card is better, a 9600GT):
NVIDIA System Information report created on: 07/12/2010 13:42:58
System name: SCHDTLABPC1
[Display]
Processor: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2004 MHz)
Operating System: Microsoft Windows XP, 32-bit (Service Pack 3)
DirectX version: 9.0c
GPU processor: GeForce 8500 GT
Driver version: 190.38
Stream processors: 16
Core clock: 500 MHz
Shader clock: 1020 MHz
Memory clock: 400 MHz (800 MHz data rate)
Memory interface: 128-bit
Memory: 1024 MB
Video BIOS version: 60.86.41.00.23
IRQ: 16
Bus: PCI Express x16
I have a GT9500, it gives the same speed as my GTX 260 I have somewhere and only put in when I want to play.... Not very offen. :)
Here are the spec om my 9500 GT card (passiv cooled card at a price around 350 dkr ~ 70$) - Max Power use ~ 50 watt
[Display]
Processor: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (3200 MHz)
Operating System: Windows 7 Ultimate, 64-bit
DirectX version: 11.0
GPU processor: GeForce 9500 GT
Driver version: 197.45
CUDA Cores: 32
Core clock: 550 MHz
Shader clock: 1400 MHz
Memory clock: 400 MHz (800 MHz data rate)
Memory interface: 128-bit
Total available graphics memory: 2815 MB
Dedicated video memory: 1024 MB
System video memory: 0 MB
Shared system memory: 1791 MB
Video BIOS version: 62.94.3C.00.00
IRQ: 16
Bus: PCI Express x16 Gen2
Guest
12th July 2010, 20:19
You have 2GB? I hate you.
OK, I wanna see the most kick-ass specs. Bring it on! :devil:
P.S. I believe the VP is clocked off the core clock.
Sharktooth
12th July 2010, 20:54
i can post my ATI card specs... those rox... but i think they wont be usefull LOL :D
cweb
12th July 2010, 21:38
This is my main system, with a GTX 285 card.
[Display]
Processor: AMD Athlon(tm) 64 FX-62 Dual Core Processor (2800 MHz)
Operating System: Windows 7 Professional, 32-bit
DirectX version: 11.0
GPU processor: GeForce GTX 285
Driver version: 196.21
CUDA Cores: 240
Memory interface: 512-bit
Total available graphics memory: 2303 MB
Dedicated video memory: 1024 MB
System video memory: 0 MB
Shared system memory: 1279 MB
Video BIOS version: 62.00.45.00.00
IRQ: 16
Bus: PCI Express x16
RedDwarf1
12th July 2010, 21:50
Who, me? I can't afford to buy all those different cards. :)
No, I was referring to tormento. You have already said you don't have the time to do it.
Different systems, such as CPU, Windows version and GPU might influence the decoding speed but how big a difference the GPU makes is the question that has never been discovered. Do we really need the latest, fastest, highest electrically powered card to provide fast video decoding or will a very basic card be sufficient? For H264 transcoding the card probably doesn't make much difference as the encoding is the slow part and the decoding speed is unlikely to be the bottleneck. It's only when encoding from HD to SD that decoding speed becomes an issue as encoding is very fast and often faster than the decoding speed. That's a big issue for anyone doing such things.
If I was to encode an XVid from HD video, I can decode@ about 100fps for 1440x1088i@25fps but I can encode at around 140+ fps from an SD Mpeg2 source. So the bottleneck would be decoding HD video using a GPU.
VP engine clock rate and memory bandwidth are the specs to compare. We could all post our card and what the Nvidia control panel shows for those specs.
You nVidia contact said that the VP engine is usually clocked the same right across the nVidia chipset range. It usually clocks at 250MHz but in some cases can be clocked lower for lower end cards. That is what was show in your development notes. ;)
My card at work (my home card is better, a 9600GT):
NVIDIA System Information report created on: 07/12/2010 13:42:58
System name: SCHDTLABPC1
[Display]
Processor: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2004 MHz)
Operating System: Microsoft Windows XP, 32-bit (Service Pack 3)
DirectX version: 9.0c
GPU processor: GeForce 8500 GT
Driver version: 190.38
Stream processors: 16
Core clock: 500 MHz
Shader clock: 1020 MHz
Memory clock: 400 MHz (800 MHz data rate)
Memory interface: 128-bit
Memory: 1024 MB
Video BIOS version: 60.86.41.00.23
IRQ: 16
Bus: PCI Express x16
I don't think the Core clock has anything to do with the VP engine clock. I think that they are totally separate and don't influence one another. It's the VP engine which is used to decode the video as you have mentioned before and is shown by GPU-z. The GPU load is usually fairly low when decoding video but the Video engine hits 99% on mine.
What might be helpful would be to have some test videos which people could use to preview using DGIndexNV and then post the average decode speed as a graphic showing the window. Post a GPU-z image of the graphics card details and maybe some shots from CPU-z. Then see whether the Graphics card makes any difference.
The only HD video I have is HD broadcast video from BBC HD & ITV HD TV channels which is 1440x1088i@25fps.
Movie trailers might be useful if those are permitted by forum rules.
@neuron2
They are all 1GB cards, note the Dedicated video memory: 1024 MB. I don't think they have 2GB of memory. ;) His looks like it might have onboard AMD video so that might be why his is showing as being over 2GB. The video memory is the total of shared and dedicated video memory.
Processor: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (2666 MHz)
Operating System: Microsoft Windows XP, 32-bit (Service Pack 3)
DirectX version: 9.0
GPU processor: GeForce GT 240
Driver version: 197.45
CUDA Cores: 96
Core clock: 550 MHz
Shader clock: 1340 MHz
Memory clock: 1700 MHz (3400 MHz data rate)
Memory interface: 128-bit
Memory: 1024 MB
Video BIOS version: 70.15.38.00.01
IRQ: 16
Bus: PCI Express x16 Gen2
or
Processor: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (2666 MHz)
Operating System: Microsoft Windows XP, 32-bit (Service Pack 3)
DirectX version: 9.0
GPU processor: GeForce GT 240
Driver version: 197.45
CUDA Cores: 96
Core clock: 550 MHz
Shader clock: 1340 MHz
Memory clock: 2000 MHz (4000 MHz data rate) A bit more memory bandwidth if needed ;)
Memory interface: 128-bit
Memory: 1024 MB
Video BIOS version: 70.15.38.00.01
IRQ: 16
Bus: PCI Express x16 Gen2
Guest
12th July 2010, 21:56
650 not 250.
I know the card makes a difference. On one poor system with 8500 at work I get 15 fps decoding on a stream for which I get 68 fps at home.
RedDwarf1
12th July 2010, 22:09
650 not 250.
I think we both got the wrong numbers.
The notes say 450MHz with some running at 400MHz. Search the notes for MHz ;)
I know the card makes a difference. On one poor system with 8500 at work I get 15 fps decoding on a stream for which I get 68 fps at home.
Different video, bitrate, resolution, framerate can be decoded at different speeds. These are factors and the VP engine/GPU might also play a part.
As I said I get around 100fps for 1440x1088i@25fps low bitrate HDTV. I don't have any sources to check Blu Ray or high bitrate video so don't know what mine is capable of.
It would be interesting to know whether a badass high end card provides any benefit for such uses or whether a more power efficient low end card is just as good.
Does the updated VP engine make any difference to decoding speed? Is a VP4 beneficial? In what way? Speed? Quality? The video it can decode? Some are known because of information from various sources but other things are not. These things can only really be found through testing.
Guest
12th July 2010, 22:16
It would be interesting to know whether a badass high end card provides any benefit for such uses or whether a more power efficient low end card is just as good. I just got done saying I know it makes a difference. Are you doubting that or just missed my statement?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.