DG NV tools

[crusher497]

neuron2,

Any plans to be able to index h264 FLV files?

[linyx]

Originally Posted by neuron2

@linyx
Need your stream and your diff results, please.

As for timing, I got:
DGIndexNV 2018
15:17
12:22

then with DGIndexNV 2018 Perftest
14:15
11:50

on the same files (Windows 7 x64 here).

With the corrupted video, it only appears in the DGIndexNV window, the actual decoded video appears to be fine (albeit, it cannot demux it properly from a few tests). It appears to only happen with MKVs, too.

Here are three clips which each produce the issue.
http://www.mediafire.com/download.php?n403xuvkaqy
BTW-Thanks for the work on speeding up indexing!

[RedDwarf1]

I use Win XP Pro x86 and would help test but I don't have a Blu Ray drive so I could only do testing from either DVD or hard drive.

I only have BBC and ITV HD broadcasts which are 1440x1088i@around 9Mbits. So unless there is a source to test with, I cannot really help.

I do have a GT 240 1GB which gives around 100fps, typically 95 to 105fps, while previewing BBC HD TS's.

Core 2 Q9450@2.66GHz
Win XP x86
4GB DDR2
5 SATA hard drives

[Guest]

You can test on anything as long as it takes a reasonable amount of time to index. If the stream indexes in 1 second, it's hard to discern any change.

Load the same file 10 times, whatever it takes to make indexing take minutes.

[Guest]

Originally Posted by linyx

With the corrupted video, it only appears in the DGIndexNV window, the actual decoded video appears to be fine (albeit, it cannot demux it properly from a few tests). It appears to only happen with MKVs, too.

Very strange MKVs. Please tell me what the source material was and how you generated these MKVs, in detail. Thank you.

EDIT: It appears that the stream has multiple different PPSs but only one is stored in the MKV's CodecPrivate. Here's what would help me to figure this out. Post a link to the source material used to make the MKV and explain exactly how you create the MKV from the that source material.

[laserfan]

Originally Posted by neuron2

My results on my i7-980X Win7 64bit with VelociRaptor (same project as my WinXP results).

2018 - 3:16
2018 perf - 3:12

This supports my WinXP versus Vista/Win7 theory. I'm tending towards going with the perf version due to the big gains it gives XP users. I don't know why some of you see drops on Vista/Win7; could it be the RAID 0?

I tried DGIndexNVperf for grins, following 2016 and then 2018 (32-bit versions, but I'm a W7 x64 quadcore PC). All three were around 6 1/2 minutes, with the "performance" version actually a few seconds slower. FWIW.

BTW because you always write-out the log as "inputfilename.log" each run will overwrite the previous. Seems to me you should name the .log file with the Save as Project/Output file e.g. then I'd have 3 easy logs: videoIN2016.log, videoIN2018.log, videoINperf.log to go along w/my 3 .dgis?

[Guest]

Originally Posted by laserfan

I tried DGIndexNVperf for grins, following 2016 and then 2018 (32-bit versions, but I'm a W7 x64 quadcore PC). All three were around 6 1/2 minutes, with the "performance" version actually a few seconds slower. FWIW.

Further support for the WinXP vs. Vista/Win7 theory. Thank you.

[RedDwarf1]

I've just had an error with 2018. A TS was open which I attempted to move to another folder to use for testing. Unlocker opened so I unlocked it and moved the file. I then closed the file in DGIndexNV but when I attempted to open the file in the new folder I got the message GPU decoder: failed to create video decoder[1]. Closing DGIndex and re-opening and it worked fine.

This is what happened with an invalid license file after I moved from 2013 first version to 2018. Not really a big issue, more about error handling.

Indexing tests done with a 1 hour 4 minute BBC HD Transport stream

Indexed to the same folder:
2018 took 3 mins 21 secs
The test version indexing the same file took 2 mins 15 secs

Indexed to a different Drive:

2018=3 mins 20 secs
Test version=2 mins 51 secs

Strangely, the 2018 version took the same amount of time whereas the test version took quite a bit longer than when indexing to the same drive.

I've moved to driver 197.45 after getting a BSOD specifying a nVidia driver file with the latest driver.

You could provide an option so that people could use whichever provides the best performance for them rather than optimizing it for one version of windows or one type of hardware.

[Guest]

Originally Posted by RedDwarf1

You could provide an option so that people could use whichever provides the best performance for them rather than optimizing it for one version of windows or one type of hardware.

That's easy to do for buffer size but it's a nightmare to select low-level IO versus C runtime IO.

[woah!]

Originally Posted by neuron2

Looks like it might be a Win7 versus WinXP issue.

@woah!

Please give your system details.

amd thuban x6 1055T
winxp sp3 32bit
mech hard drives for files encoding, except the OS drive is ssd.

[linyx]

Originally Posted by neuron2

Very strange MKVs. Please tell me what the source material was and how you generated these MKVs, in detail. Thank you.

EDIT: It appears that the stream has multiple different PPSs but only one is stored in the MKV's CodecPrivate. Here's what would help me to figure this out. Post a link to the source material used to make the MKV and explain exactly how you create the MKV from the that source material.

The source material was the respective Blu-Ray disc for each title. I used eac3to like this for each:

eac3to.exe "Source" 1) 2: B:\Paycheck\Video.mkv

I assume it is Haali's Matroska Muxer (2009-11-14) that was used by eac3to, then those I remuxed (to cut down on the size) with MKVMerge GUI (4.0.0.0), and finally split them to 50 meg pieces (uploaded the first piece) with DGSplit.

What do you need from the source material? Seeing as it is a full Blu-ray, uploading the whole thing could take a few months and would probably be considered... less than legal.

[Guest]

Never mind. I used mkvextract to get the ES. I think I know what's wrong. Stay tuned.

[hydra3333]

I don't understand ... just copied 2018 over and set the license to #2 (it could have been the wrong one), and used commandline

"C:\software\DGindex\DGIndexNV.exe" -i "G:\HDTV\Q1.mpg" -a -o "G:\HDTV\Q1.dgi" -e

a few times. From a non-priv account (the .ini is in a read-only folder). And it popped up with could not create decoder. Logged into a priv account, set the license to #3 and it didn't throw that error. Logged back into user account and ran the command line and it just sits there not opening the file. Same interactively.

Now doesn't open any pal HD .mpg from either account. Can swap amongst the account and licenses but nothing opens at all. Rebooted same issue stays. What should I do ?

edit: XP-sp3 32bit latest nvidia driver 8600GT q6600
edit2: no, I think license 2 was the right one

[Guest]

I don't know anything about "priv" and "non-priv" accounts. You have to be able to read the INI file and it must be set to the right license before opening your file.

If it pops up "could not create decoder" then you are pointing to an old obsolete license. You need to use the regenerated one.

[Guest]

Regarding linyx's issue...

There are two things going on.

1. My support for MKV works by reading an entire timecode's worth of data into the buffer. That may include an SPS, PPS, SEIs and the slices of the frame at that timecode. If it is an IDR, it can be quite large. So when I reduced the buffer it became insufficient to hold the MKV data for one timecode. I can fix that by setting a large buffer when an MKV file is loaded. That explains the bad demux and general crappiness.

2. The earlier issue I fixed by revising the strategy for PPS injection needs to be carried over to MKV. But that is broken even in vanilla 2018, as you can see by loading Paycheck.mkv and GOP stepping forward.

I can fix 1 easily. For 2 I am putting on my thinking cap. In the meanwhile, do not use 2018 perf test version for MKV.

[hydra3333]

Had just installed a brand-new fresh squeaky clean XP-sp3 with latest drivers, q9450, 8800GT, fully patched, dual-nic gigabyte motherboard on a different machine (same motherboard type).

Checked the right license file and license content (correctly pasted) into license.txt in the same folder as the .exe.

Ran it from an admin account, so no likely issues there. Tried to open a .mpg, it threw the error

GPU decoder: failed to create video decoder [1]

Still at a loss.


edit: ugh, just went back to the license generator and it gave me different long strings than last time. Works now Must have missed reading some posts on re-doing the licenses.


EDIT2: What ?? ? I just did 4 of these by dragging and dropping the .mpgs onto a .bat file which had that command line and they all worked. Then I tried a 5th and no it only sits there with a blank black area. So I rebooted and re-tried one of those that did work and now same result again no matter what. Help !!!

EDIT3: Oh. One of my NICs is connected to another box which I use for other things, and when that box is down the NIC loses connectivity and DGindexNV doesn't work. When it's up then the NIC connection is restored and DG does work ... Is it possible for DG not to depend on the boot state of another machine ?

[MrVideo]

AMD Quad core 3.2 GHz
SATA HDD (separate from C
GT240
Latest NVidia driver

Don't know about the cache issue, but for me there was definitely a difference.

The source is a MPEG-2 elementary stream (don't do audio with my jobs, done separately), 11.6 GB.

2018 - 2:41
2018p - 1:43

I think the big reason for the time difference is the lack of waiting for the buffer. The hesitation is gone. There is now a consistent reading of the source file.

Based on test results from Win7 users, it is another reason I'm not leaving XP.

[tormento]

The test I promised you.

Windows 7 x64 - 3 x Raptor 300GB Raid 0 ~ 300 MB/s average read

Rocky Balboa BD

DGIndex x86 standard - dgi only: 06m36s
DGIndex x64 standard - dgi only: 05m15s
DGIndex x86 optimized - dgi only: 04m27s

DGIndex x86 standard - dgi with audio: 10m32s
DGIndex x64 standard - dgi with audio: 10m30s
DGIndex x86 optimized - dgi with audio: 06m00s

DGIndex x86 standard - dgi with audio + video: 12m30s
DGIndex x64 standard - dgi with audio + video: 14m05s
DGIndex x86 optimized - dgi with audio + video: 10m57s

P.S: When reading mpls it could be nice to have language instead of PID XXXX in demuxed audio.
P.P.S: Uh and an audio *beep* when finished should be nice too.

[Guest]

Originally Posted by hydra3333

EDIT3: Oh. One of my NICs is connected to another box which I use for other things, and when that box is down the NIC loses connectivity and DGindexNV doesn't work. When it's up then the NIC connection is restored and DG does work ... Is it possible for DG not to depend on the boot state of another machine ?

No guarantees, but I'll look into the feasibility of that after I get the performance release out. There are technical issues with having multiple keys in the license file with my current architecture.

[tormento]

Originally Posted by neuron2

There are technical issues with having multiple keys in the license file with my current architecture.

It's a pity.

Moreover: I use x64 and x86, could you please make x64 version look for license file in parent directory too?