View Full Version : DG NV tools
Guest
22nd May 2010, 01:16
OK, boys and girls, I have a fix. :)
My new strategy for SPS/PPS heuristics on seeking is:
1. Search in the last 5MB before the seek point for SPS and PPS nearest to the seek point. If found use them. (This does not degrade performance noticeably.)
2. If not found, search in the first 5MB of the file for the first SPS and PPS. If found use them.
3. If not found error out.
It works great on linyx's stream and some other SPS/PPS ID re-use streams I have. I need to do some heavy regression testing before releasing it, hopefully this weekend.
I have also implemented tooltips for my cryptic buttons. :)
Probably next on the agenda will be 64-bit support.
linyx
22nd May 2010, 02:22
Wow, I really wasn't expect a fix based on your previous post, thanks!:thanks:
Sorry for causing you so much trouble with this particularly tricky stream.
Guest
22nd May 2010, 02:42
Sorry for causing you so much trouble with this particularly tricky stream. Don't be sorry. Be happy that you are contributing to improving the program! Anyway, I enjoy such challenges.
Guest
22nd May 2010, 20:43
Ouch, it's not so easy when you have multiple files loaded! But fear not, I have that working too. :)
That's why one should always go heavy on regression testing for a major change like this.
Guest
25th May 2010, 00:55
* Redesigned the SPS/PPS heuristics for AVC streams in DGIndexNV. This fixes cases of bad decoding when navigating on the timeline for streams that: 1) Have SPS/PPS's remote from the seek point. 2) Re-use SPS/PPS IDs for NALUs with different content. The fix dramatically improves things for such streams, but it may not be perfect because it is, after all, a heuristic. Note that this problem did not affect serving video through the Avisynth script; it affected only navigating the timeline in DGIndexNV (but see below).
* The SPS/PPS heuristics fix also fixes bad video demuxing for the same cases described above.
* Added tooltips for the navigation buttons and navigation bar in DGIndexNV.
* Fixed a problem that caused the DGIndexNV GUI and the DGI file to disagree about the frame size in some rare cases.
* The Detect PIDs dialog now shows the PIDs in both decimal and hexadecimal.
* The Quick Start guide was revised to use DGMultiSource() by default. A second Quick Start guide is provided for DGSource()/CUVID Server usage.
http://neuron2.net/dgdecnv/dgdecnv.html
@linyx
While your stream issue is fixed, your test file will still show macroblocks at the start because it was demuxed using the previous version. The macroblocks later in the stream no longer appear.
kebulek
25th May 2010, 13:26
Thank you neuron2 for new version, but the "Cannot find audio data" error is still present. I just tested .ts, which was cutted with DVR-Studio HD 1 this time, so I guess, it's not TSPE or any other ts editor issue...
Guest
25th May 2010, 13:30
I had it fixed in my local build but it came back due to a later fix I made for another stream. Thinking about it now I see a way to fix it so both will be OK. I'll make a 2009 with that and release it ASAP.
XadoX
25th May 2010, 13:34
@neuron2: :thanks:
Is the commandline cropping bug still in this build?
Guest
25th May 2010, 13:53
Is the commandline cropping bug still in this build? The values are correctly read as decimal rather than hex. Is that what you refer to? That was already fixed in 2007.
XadoX
25th May 2010, 13:59
The values are correctly read as decimal rather than hex. Is that what you refer to? That was already fixed in 2007.
Oh. I think I miss this fact :o
kebulek
25th May 2010, 17:25
I had it fixed in my local build but it came back due to a later fix I made for another stream. Thinking about it now I see a way to fix it so both will be OK. I'll make a 2009 with that and release it ASAP.
Thank you! It will be perfect then! For me, at least... ;)
Guest
25th May 2010, 19:23
Thank you! It will be perfect then! For me, at least... ;) It's done and will be released when I get home tonight. Thanks for reminding me about it.
Clumpco
25th May 2010, 22:50
Thanks for your continuing work neuron2!
Guest
25th May 2010, 23:07
Thanks for your continuing work neuron2! You're welcome.
And BTW I haven't forgotten your trouble report on stream type detection (teletext detected as audio). I'm sketching out in my head an option to configure the "stream profile", which will allow the software to differentiate ambiguous indications more reliably. For example, you could set your profile as:
bluray disk
ATSC terrestrial
DVB-S
etc.
Then the software would reliably know how to interpret the descriptors and stream IDs.
Guest
25th May 2010, 23:25
For those of you waiting for 64-bit support, be advised that I placed my order today for the new rig. I went for the i7-980 Extreme together with the ASUS Rampage III Extreme mobo.
Thank you for your donations.
Audionut
26th May 2010, 00:14
Oh nice. Patiently waits for 64bit. Thanks Don.
Guest
26th May 2010, 01:11
* Fix problem that caused some audio streams to not be detected.
* Fix problem that caused some MPEG program streams to be detected as elementary streams.
http://neuron2.net/dgdecnv/dgdecnv.html
tormento
26th May 2010, 07:00
Is it better to recreate a 2007 dgi project with 2008 or not?
tormento
26th May 2010, 07:16
I went for the i7-980 Extreme together with the ASUS Rampage III Extreme mobo.
Why not a dual Xeon? ;)
P.S: Believe me or not I was waiting for you to jump on the x64 encoding wagon.
Guest
26th May 2010, 14:02
Is it better to recreate a 2007 dgi project with 2008 or not? There's no need for that because the DGI file format is unchanged and the problem that was fixed does not affect the source filters.
Why not a dual Xeon? Not enough donations. :rolleyes:
Clumpco
26th May 2010, 17:25
You're welcome.
And BTW I haven't forgotten your trouble report on stream type detection (teletext detected as audio). ... Then the software would reliably know how to interpret the descriptors and stream IDs.
Yay!
Thanks heaps. :thanks:
Hi,
neuron2, I wanted to thank you for the continued work on this very useful tool, and to report an issue I encountered recently: to suit my modest processor, I use x264's --seek/--frames to have short intervals of full CPU usage (instead of a straight 20 hours go, which I can't afford), and more than three times, on first and second pass runs, x264 went crazy and produced either over sized stats or output video files.
I'm not sure, but I seem to remember I tried to use DGIndexNV, or play the .avs file (which resulted in the expected error message) when this happened.
Could be an issue with my system, or x264 (even though it behaved normally, the second time), but is there any possibility a first instance of DG NV would be "disturbed" by a second one the user tries to launch?
Regards.
WasF
Guest
26th May 2010, 19:30
I'm not sure, but I seem to remember I tried to use DGIndexNV, or play the .avs file (which resulted in the expected error message) when this happened. Please try to remeber better, because without a proper trouble report it's very hard to help you. What is the "expected error message"?
Could be an issue with my system, or x264 (even though it behaved normally, the second time), but is there any possibility a first instance of DG NV would be "disturbed" by a second one the user tries to launch?
It depends on which source filter you used. DGMultiSource() supports mutliple instances while DGSource() does not.
tormento
26th May 2010, 20:17
DGMultiSource() supports mutliple instances while DGSource() does not.
Neuron, please, tell me a gui to use as StaxRip is on vacancy...
Sorry for the lousy "report", I know how unhelpful that is, but I can't actually reproduce the error at will. 'Rather hoping to "ring some bells" maybe..
But wait; you mean with DGMultiSource() I can start two instances?! I'm missing something then, cause I use DGMultiSource() exclusively, and I always get this on second instances: Failed to create video decoder (100).
I'm admin on an XP SP3 with the latest patches, Comodo FW, Antivir Premium using a GeForce 8600 GT, Driver version 6.14.11.9621.
Guest
26th May 2010, 20:43
You still haven't even told me the "expected error message" mentioned in your first post, even after I asked for it.
The number of instances possible is determined by the amount of memory on your Nvidia card, as stated in the release notes:
"The DGMultiSOurce() source filter supports multiple instantiation, however, the number of
instantiations is limited by available memory on the Nvidia card. As always, more is better!"
If you have a really low-end card, it may be that only one instance is possible.
Guest
26th May 2010, 20:44
Neuron, please, tell me a gui to use as StaxRip is on vacancy... Zathor's MEGUI build works for me. I don't use GUIs typically but I have tested it.
Sharc
26th May 2010, 21:13
HDConvertToX also supports DGNV tools nicely.
neuron2, the error message is in my previous post: Failed to create video decoder (100). :confused:
Thanks for the tip about memory, the message does seem to fit with the hint. I guess 256MB is too "optimistic" for a couple 1080p sources, anyway!
Guest
26th May 2010, 22:43
It also depends on if you have D3D mode enabled. That will require more memory, I am told.
I have tons of system RAM though, I wish I could tell the driver to help itself..
With use_D3D=true I get an explicit message: "DGMultiSource: Multiple instances not supported with use_D3D=true!" as if use_D3D=true & multiple instances were complete opposites (!)
My limited means, I can live with that, only if my first and only instance was not "corrupted" by attempts to start new ones. I couldn't reproduced it tonight, so its not like I get a failure every other run of x264..
Maybe use_D3D=true will solve the problem, whatever it is, as the error message from DGMultiSource() at least shows the exception, whatever it is, is handled properly and the program is aborted in an orderly manner before new decoder creation. Or so I hope :)
Guest
27th May 2010, 02:44
My limited means, I can live with that, only if my first and only instance was not "corrupted" by attempts to start new ones. There is no evidence that that is happening. Anyway, why would you try to start a second one if you know it is going to fail?
I couldn't reproduced it tonight, so its not like I get a failure every other run of x264.. See above.
Maybe use_D3D=true will solve the problem, whatever it is, as the error message from DGMultiSource() at least shows the exception, whatever it is, is handled properly and the program is aborted in an orderly manner before new decoder creation. Or so I hope :) You're just groping in the dark. You should try to duplicate the problem so we can find the real cause. D3D operation is not recommended. Read the manual.
You are not running the recommended driver version. Can't you do that?
I'm sorry, I looked into all html and txt files from dgdecnv2009.zip, but found no mention of a recommended driver version. The Quick Start Guide only says it should be >= 191.07. I have 196.21.
What is the recommended driver version?
Guest
27th May 2010, 04:06
Sorry, I confused you with someone else. That version is fine.
Please stick to one instance due to your low GPU memory. Is there still a problem?
I was trying to index/edit a second movie when another one was being encoded..
With one instance, no problem at all. I just need to be conscious about it now, when I used to be careless before :)
Guest
27th May 2010, 05:03
It shouldn't be a problem because the second one should just error out. Can you duplicate this?
Guest
27th May 2010, 05:10
Hi there,
I've found a MPEG-2 Program stream which DGIndexNV cannot decode. (I see a green video window with a few randomly colored macroblocks in it).
I had a copy of DGIndex 1.5.2 here, so I tried that. It shows video in the window properly.
The video is MPEG2 Program, profile esc (0@5), 720 x 512 px, 4:3 [2], 29.97fps, NTSC, Interlaced, BT.470-2 B,G, Frame, Top Field.
That's 4:2:2 video, which I'm pretty sure CUVID does not support. I have written Nvidia to verify that and ask if it might be supported.
It shouldn't be a problem because the second one should just error out. Can you duplicate this?
Yes, second instance always fails. With use_D3D=true I get the AviSynth error message from DGMultiSource(), without it, I get a message box with: Failed to create video decoder (100).
Guest
27th May 2010, 05:19
Yes, thanks, I know it will fail but it should not interfere with an ongoing encode. Can you reproduce that? With and without D3D?
No, not that one. I tried many times to "corrupt" an x264 1st pass, but I couldn't.
It happened at least 4 times yesterday and the day before, though! And I didn't restart my computer.
I know, if it cannot be duplicated, ..
Maybe my video card was getting too hot or something (after a 48h workout!).
tormento
27th May 2010, 06:51
Zathor's MEGUI build works for me. I don't use GUIs typically but I have tested it.
Do you mean the x64 version? Will it digest dgnv x86?
As a matter of fact, my problem is with guis and multisource, not with the older way.
tormento
27th May 2010, 06:52
HDConvertToX also supports DGNV tools nicely.
Does it work with multisource?
buzzqw
27th May 2010, 07:02
it support only DGMultiSource
BHH
Guest
27th May 2010, 13:53
Do you mean the x64 version? I currently do not have a 64-bit system so have never used any 64-bit software.
MrScientist
28th May 2010, 19:58
first off, thanks for a good product, it works exactly as advertised. i noticed that when the cuvid server is running, my video card (Gigabyte GT240 512mb gddr5) runs at its highest power 3d clock settings, but has a gpu load of 2% or less, memory controller load of 3% or less and video engine load of 7% or less. shouldn't the card be able to run at its lowest 2d power settings and still be able to accomplish this task? i'm assuming there's a specific reason for this and am not trying to find fault with the program, i'd just like to know why it is how it is. it would be nice, from a power efficiency standpoint, if the cuvid server could run with the gpu card in its lowest power settings. thanks.
Guest
28th May 2010, 20:02
I don't know anything about GPU power settings nor does my code do anything in that area. Whatever the Nvidia driver chooses to do is what will happen. If you have any advice about it I am all ears.
Video Dude
29th May 2010, 05:25
My source is DVD MPEG-2.
In terms of decoded video quality, how does DG NV tools compare with DGMPGDec? I'm considering donating to the DG NV tools project and was wondering if switching from DGMPGDec to DG NV tools will give an improved quality MPEG-2 decode.
I apologize if this has been discussed before, but I have been away from the forum and have not been keeping up with the project and couldn’t find the info when I searched.
Guest
29th May 2010, 12:25
Signifcant differences for MPEG2 are:
1. DGMPGDec and do 4:2:2 and 4:4:4 decoding. DGDecNV cannot. These streams are uncommon.
2. DGMPGDec has built-in postprocessing, such as deblocking.
3. DGDecNV had PureVideo deinterlacing and GPU resizing.
Unless you really need 3, there is no compelling reason to use DGDecNV *for MPEG2*.
Blue_MiSfit
30th May 2010, 10:48
Neuron2,
How many instances of ~50mbps H.264 w/CABAC @ 1080p24 can I expect to comfortably decode on a 1GB Quadro, without running out of video RAM? Roughly, of course :p I'll do some testing when I get a chance.
Derek
Guest
30th May 2010, 13:32
I don't know and will appreciate your test results.
I could say anywhere from 3 to 10 but that wouldn't be very helpful.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.