DG NV tools

[stranno]

My mistake, i mean 59,94.

Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 3.83 GiB
Duration : 1h 19mn
Overall bit rate mode : Variable
Overall bit rate : 6 933 Kbps
Writing application : Lavf53.3.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1h 19mn
Bit rate : 6 797 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate mode : Variable
Frame rate : 59.940 fps
Minimum frame rate : 59.940 fps
Maximum frame rate : 60.000 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Bits/(Pixel*Frame) : 0.328
Stream size : 3.75 GiB (98%)

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 1h 19mn
Bit rate mode : Variable
Bit rate : 128 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 72.4 MiB (2%)

[LigH]

The most current DGIndexNV version should be able to read MP4 and derive the frame rate from its header.

Changes.txt
Build 2044
----------

* Added MP4 container support.
...

[stranno]

I'm using 2044 (64bit) :-/

And i've also tried demuxing the 264 stream, it doesnt work. Even setting the right framerate through h264info in 264 stream or mp4box in mp4 container.

[LigH]

A raw H.264 video stream may not contain any information about its framerate at all. No surprise that this step was not useful.

How about converting the container to MKV, using mkvmerge (MMG)?

Or rebuilding the MP4 with MP4Box before using it in DGIndexNV? "Writing application : Lavf53.3.0" is an indication towards ffmpeg, which is known to create incomplete MP4 containers (due to its "filter" behaviour, sequentially writing the output only once).

[stranno]

No, it stills detect the half lenght of the video and forcing it 59.94FPS accelerate the video.

Its strange, FFmpegSource2 run and index it perfectly. Is there any way to transform the .ffindex of FFmpegSource2 in .dgi of DGNV? Sure its a nonsense, just guessing.

[Guest]

If you post a sample stream that I can use to duplicate your issue, I'll be able to tell you what is happening and what you should do. If DGIndexNV says there are 142143 frames, I would believe that.

Where did you get this movie MP4 file?

[stranno]

Its a record from Avermedia Game Capture HD.

http://imagenes.pccomponentes.com/avermedia_game_capture_hd_1.jpg

The source i'm talking its 3,8GB so it will take so long just for check it. I will try to upload a shorter one, it happens no matter the lenght.

[stranno]

Here's one source.

https://mega.co.nz/#!gVh0DTwD!Ze_lTnkvIOCzsBx5Y5AGizbFdO5f6WHYx2kN2nUYHqE

[Guest]

telecide()
assumefps(29.97)

[stranno]

telecide()
assumefps(29.97)
Thanks, this worked. But, is there any way to use all of frames, i mean, the 59.94 per second instead of 29.97 that DG index?.

I still dont understand why all frames are not indexed.

[Guest]

The source contains 29.97 frames per second, not 59.94 frames per second. There are no missing frames.

[LigH]

Probably as I said before, some tools report a "field rate" (half-frame rate) for PAFF interlaced MPEG4-AVC.

[Selur]

DGMPGDec Known Issues and Limitations (http://forum.doom9.org/showthread.php?t=109119) states:
...
Unicode paths and file names are not supported.
...
Are there any plans to fix/change this in the near future?

It's kind of annoying having to rename all unicode files or use a 8.3 compatible short file names (if the file system supports it).

Cu Selur

[Guest]

It's on my to-do list but it won't happen anytime soon, as I am concentrating on a physics paper for a conference in August.

[Selur]

Okay, thanks for the info. :)

[Morku]

Hi,
I got a problem with "Gran Torino" and DGIndexNV 2045 (32bit). There is a position in the movie which let DGIndexNV crash (or the NVIDIA driver). In the final movie output the image just stops in that position and displays the whole last piece of the movie (only audio is played till the end).
So I took a second look and opened the Video preview of MeGUI, switched to that position and pressed play.
This is what will happen everytime: http://i.imagebanana.com/img/7q5g7ttj/Gran.jpg
In english like "the display driver 'NVIDIA Windows Kernel Mode Driver' doesn't react anymore and was restored after an error."
When I look to the original movie file, at this position there is one frame, which is completly wrong, but MeGUI already crashs 3 frames before the 'wrong' frame appears.
I have a GTX480 newest WHQL driver, Windows 8 64bit.

What can I do?

[Guest]

What can I do? Please post a link to an unprocessed source stream sample that I can use to try to reproduce the issue. Use DGSplit to cut the stream and make sure the problem happens with the file that you upload. Use a hosting site such as mediafire.com and post the link here. Thank you.

[Morku]

I have send you a private message with the link.

[Guest]

Thank you. Investigating...

[Morku]

Sooo... have you found out something?

[Guest]

The stream is corrupted. Try re-ripping it.

[Morku]

Thats all? Of course it is corrupt. It is corrupt on the BluRay and I can rip it as many as I want, it will stay corrupt. DGIndexNV should skip it, like Media Player Classic - Home Cinema does, not crashing... The BD has no scratches and damages at all. Warner Bros. released that stuff.

[Guest]

I'm not going to spend my life making workarounds for corrupted streams (especially for someone who is unfriendly and demanding). I also doubt that you will motivate nVidia to do that either.

[Morku]

You really wonder about the answer after yours? Thanks Captain Ovious.

[jpsdr]

The thing you can try, but it may be difficult to obtain, is to try to rip from another Blu-Ray. Even if the Blu-Ray has no scratch or anything, it doesn't mean that you may not have a little physical defect on the layer. But, to do this, you have to get access to another Blu-Ray, this can be the tricky part...

[Shevek]

Agreed, I have a blu ray drive in both my HTPC and my main desktop PC. Some discs will be OK in one drive but not the other and some discs vice versa.

If you have access to another drive, try that.

[x265]

Are there any speed difference between DGIndex and DGIndexNV?

[LigH]

DGIndex (DGMPGDec) handles only MPEG2 via CPU.

DGIndexNV (DGDecNV) handles MPEG2, MPEG4-AVC and VC-1 via Nvidia-PureVideo.

[x265]

I know that. Will there be any speed gain during the encoding process when using DGIndexNV?

[LigH]

Only if your video decoder chip is a lot faster than your CPU. This is more probable for graphic cards with VP5 chip. VP2 to VP4 cards have an average speed limited close to double frame rate (45-60 fps, according to reports by Selur (http://forum.gleitz.info/showthread.php?46329&p=436990#post436990)). Especialy if your decoder is stable enough to run multithreaded (like FFMS2), it will outpace DGDecNV easily. DGMPGDec is rather outdated, though.

[Guest]

It depends on your VP engine and your system. I think that, generally, if you have a VP5 engine and only a moderately powerful CPU (not a 12-core overclocked beast!) you will get some gains for HD material.

I emphasize again that the raison d'etre of DGDecNV is not performance gains (though you may see gains in some scenarios), but rather integrated, consistent, and correct random access and handling for interlaced video, pulldown, etc., for all the video types.

[Selur]

Main reason for me to use DGDecNV:
- it can handle interlaced MPEG-2/MPEG-4 AVC/VC-1; ffmpegsource2 often struggles there.
- it can handle transport streams and vobs properly, ffmpegsource2 needs Haalis Media Splitter installed to be useful at all when it comes to mpeg2 based containers
- opens up some cpu power by using the gpu (mainly useful when the avisynth script or encoding is power hungry)

Main things I miss with DGDecNV:
- Unicode paths and file names are not supported. (annoying; workaround: rename input)
- no ifo/pgc parsing (annoying; workaround: pgcdemux)
- no H.264 10bit handling, since there's no fallback software decoder (annoying; workaround: use ffmpegsource2 instead)
- not free (annoying; but understandable and worth the donation)
- no standalone version, would be nice if one could use DGDecNV/DGSource without Avisynth to simply decode the content to raw (pipe output) so that it can be piped to x264/vpxenc/... without the need for avisynth. (I know, I'm probably the only one that thinks this would be useful)
- windows only (a linux&mac version which also can work as stand alone version would be really cool; gpu decoding and properly handling of transport streams on linux in a console would be nice)

Cu Selur

[Selur]

Curious thing I just encountered, when I called:
"G:\Hybrid\avisynthPlugins\DGIndexNV.exe" -i "h:\TestClips&Co\DVDs\ElephantsDream\VIDEO_TS\VTS_01_1.VOB"
DGIndexNV crashed, after some testing I found the problem.
If I put DGIndexNV into a folder with multiple other files it crashed indexing anything.
removing some of the files solves the problem -> would be nice if you could add some option to stop DGIndexNV from looking into other files than the license.txt file. :)

[Guest]

Can you be more specific about how to make this happen please? Steps for me to reproduce it would be very helpful. What files are problematic and are you talking about the EXE file or the license file? AFAIK, DGIndexNV doesn't "look into" any files other than the license.txt file and the video file that you try to open.

[Selur]

will upload my folder which causes the problem and send you a link -> send link and simple instructions

[Selur]

can you reproduce the problem?

[laserfan]

This might be a complete distraction, but when I updated to 2045 in July, after a VERY LONG period where I'd been running successfully 2041, I did initially have a couple of ugly crashes myself, which of course startled and concerned me, but I found that after some fiddling the crashes stopped and then never returned.

A wild guess on my part, but as I look at my C:\Program Files (x86)\DGIndexNV\ folder, I see that I had been hanging-on to old .ini files, which I did on 7/23/2013 place into a separate subfolder called "Old ini files". Maybe (just maybe) the .exe hadn't liked these i.e. files named:
DGIndexNV_2.ini
DGIndexNV2038.ini
DGIndexNV2039.ini
DGIndexNV2040.ini
DGIndexNV2041.ini

being in the same folder with DGIndexNV.ini (the real deal for use with 2045).

[Groucho2004]

Maybe the version number in DGIndexNV.ini doesn't get updated to the correct version when DGIndexNV is started from the command line (i.e. without initializing the GUI).

[Guest]

can you reproduce the problem? Looking at it now. Was running QM simulations all day yesterday.

[Guest]

Looks like it is caused by the multiple avs template support. Digging deeper...

[Guest]

There were two bugs:

1. Because Windows findfirstfile etc. checks short filenames as well as long filenames it was finding .avsi files as .avs files. I had to add extra filtering on the found names. This bug was not fatal, however.

2. I allowed for 10 template files but the array for holding them had only 4 entries. Oops, this bug is fatal when DGIndexNV finds more than 4 files to add to the template list.

I want to add a new feature for demuxing and then I will release version 2046. It's time for a new version anyway to make the crackers mad. :devil:

[Groucho2004]

1. Because Windows findfirstfile etc. checks short filenames as well as long filenames it was finding .avsi files as .avs files. I had to add extra filtering on the found names.
Hehe, I ran into that issue years ago with html/htm files. Since then I always use "*.*" and filter afterwards. :)

[Selur]

Happy you found the problem and it's not my system going crazy. :)
Looking forward to 2046 :D

[Guest]

Happy you found the problem and it's not my system going crazy. And I'm grateful to you for bringing this to my attention. Preparing the release now...

[Guest]

2046 is released. Please tell me if I screwed up. :cool:

[Selur]

not at home till tomorrow evening, just connected to my machine at home via remote desktop and I get:
---------------------------
Warning
---------------------------
ERROR: cuInit failed (100)

Hit Yes to continue notifying this specific error type; hit No to disable it.
Hit Cancel to suppress all further errors.
---------------------------
Yes No Cancel
---------------------------

but that is probably due to Remote Desktop, will report back tomorrow, when I'm back at home :)

[Guest]

Yes, remote desktop unloads the video driver. You can use alternatives such as TightVNC.

[Guest]

A wild guess on my part, but as I look at my C:\Program Files (x86)\DGIndexNV\ folder, I see that I had been hanging-on to old .ini files, which I did on 7/23/2013 place into a separate subfolder called "Old ini files". Maybe (just maybe) the .exe hadn't liked these i.e. files named:
DGIndexNV_2.ini
DGIndexNV2038.ini
DGIndexNV2039.ini
DGIndexNV2040.ini
DGIndexNV2041.ini

being in the same folder with DGIndexNV.ini (the real deal for use with 2045). Shouldn't be a problem. I'm not sure why you encountered crashes, but all's well that ends well.

[tormento]

It's time for a new version anyway to make the crackers mad. :devil:

:rolleyes:

[Selur]

2046 solves the problem, thanks for fixing :)