DG NV tools

[frubsen]

I'm having a problem with audio delay.

I have been using DGAVCDec for a while with H.264 transport streams and have never had an issue with audio delay. It always outputs an ac3 track with 0ms.

Now I started using DGDecNV 2046 and its reporting an audio delay for all files now. anywhere between -1ms to 60ms. I can run the same files through DGAVCDec and it won't report a delay.

This is causing issues when muxing audio and video now.

Any idea why the two programs are reporting something different?

[Guest]

I don't support DGAVCDec and I won't answer any questions about it.

If you can formulate your question just about DGDecNV I may be able to assist you. But you'll have to provide a stream and instructions for duplicating your problem.

[frubsen]

Hi neuron2,

I think I've tracked it down to a Videoredo v4 problem and not DGDecNV. I don't have any issues with VRD v3 and DGDecNV. But both mpeg and h264 files give me grief with vrd v4 and dgdecnv.

Thanks

[frubsen]

After further testing, I have come to the conclusion that I am still having an issue with sync, and it does seem to be related to DGDecNV from what I can tell.

Here is a 10 second sample of an H.264 TS record.
http://www.filedropper.com/lenotest

If you look at the file in Mediainfo, there is no audio delay listed. However, if you index the file with DGDecNV, it will show it has a 62ms delay.

This only seems to happen with H.264 transport streams. I don't have this issue with MPEG transport streams.

[Guest]

Well, I don't develop or support MediaInfo so I feel no need to try to match its output.

You don't say whether the 62ms correction does a proper job or not. You just tell me it doesn't match MediaInfo.

I tried your file with the correction:

vid=dgsource("leno_test.dgi")
aud=nicac3source("leno_test PID 1100 3_2ch 48KHz 384Kbps DELAY 62ms.ac3",2).DelayAudio(0.062)
audiodub(vid,aud)

The sync appears just fine to me.

If you have problem you'll have to give me what I need to duplicate the issue: streams, script, and instructions for seeing the issue.

[frubsen]

Yes if I add the delay it fixes the sync problem. My point is that there shouldn't even be a delay.

I did a test. I demuxed an ac3 track using both VRD(I know this isn't your program), DGIndexNV, and DGAVCDec(I know you don't support this program anymore, I was merely using it for testing purposes.)

I checked the frame count on all 3 AC3 files. Both the output from VRD and DGAVCDec match. The output from DGIndexNV is 3 frames shorter. If I then take those AC3 files and mux it to my encoded video, for both the VRD and DGAVCDec output, I do not have to add a delay and the file is perfectly in sync. If I mux the AC3 output from DGIndexNV to my encoded video, I have to add a delay.

So basically, for whatever reason, DGIndexNV is chopping off 3 frames somewhere. Either at the beginning or end and is causing this delay.

Again, this only seems to be for H.264 files. MPEG2 does not have this issue.

[sneaker_ger]

So basically, for whatever reason, DGIndexNV is chopping off 3 frames somewhere. Either at the beginning or end and is causing this delay.

If it's at the end, there is no delay. Compare the different ac3 files in an editor to see where it got chopped off.

[frubsen]

Just brought them into an editor(Adobe Premiere) and placed them on top of each other. The DGIndexNV AC3 had 3 frames cut off the top compared to the other file. When I moved it 3 frames ahead on the timeline, it matched the AC3 audio from the VRD/DGAVCDec Demux.

So I have now confirmed that DGIndexNV is chopping off frames at the beginning of the audio track.

I just tried it with another video and it's the exact same thing. 3 Frames off the top.

[Guest]

I'll look into it and report back.

[sum1]

I have an issue taking a 30fps AVC source and converting it to 23.976 while using "deinterlace=1" in my dgsource line. I am using DGindexNV 2044.


An Example video source is located here http://www.filedropper.com/test_16

If I run the following .avs everything is fine and I end up with a 20 second clip at 23.976 fps, however it takes about twice as long to process.
LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\LeakKernelDeint.dll")
dgsource("1.dgi")
LeakKernelDeint(order=1)
Select5()

crop(4,4,-4,-12)
lanczosresize(720,404)


However if I use dg to deinterlace the video with "deinterlace=1" I end up with a clip that is 16 seconds long instead of 20?? I have also noticed that if I view the avs in Vdub it will show no duplicate frames at 30fps?

The AVS
dgsource("1.dgi", deinterlace=1, resize_w=720, resize_h=404)


I believe the proper AVS should be
dgsource("1.dgi", deinterlace=1, resize_w=720, resize_h=404)
Select5()

However this still gives me a 16 second clip where are the other 4 seconds going? I should also mention when the video being encoded is staying at 30fps I do not have any issues.

Any help would be appreciated, perhaps I am missing something obvious here.

[Guest]

The sample you posted is pure soft 3:2 pulldown. The correct handling for that is:

dgsource("test.dgi", fieldop=1, resize_w=720, resize_h=404)

You never want to deinterlace telecined content.

[frubsen]

I'll look into it and report back.

Any luck on this?

[Guest]

Any luck on this? It's definitely not a matter of luck. :sly:

Are you using the 32-bit or 64-bit version? I will post a link to a test version for you after you so advise.

[frubsen]

I mainly use the 32bit version on my one computer, and then the 64bit occasionally on my other.

[Guest]

Here's a 32-bit build to try:

http://neuron2.net/misc/DGIndexNV_frubsen.exe

It seems to fix your issue for the sample you uploaded, but we will need some extensive regression testing.

[frubsen]

That seems to have done the trick! Tested it on both mpeg2 and h264 transport streams and nothing is giving me delays anymore, and the ac3 files are no longer a few frames short compared to their VRD output counterpart!

I'll do more testing in the next few days but it seems to be fixed.

Thanks so much!

[Guest]

Assuming no-one has experienced any issues with this fix, I'd like to slipstream it into version 2046. So, are there any adverse consequences that anyone has seen?

[frubsen]

Assuming no-one has experienced any issues with this fix, I'd like to slipstream it into version 2046. So, are there any adverse consequences that anyone has seen?

I've used it a bunch and it's working perfectly for me now. What was the issue if you don't mind me asking?

[Guest]

OK, thank you for the feedback. My video lookahead was finding out too late where the audio should start in coincidence with the first decodable frame, and the parser had already passed that point in the stream. I had to rearrange a few things.

[MeteorRain]

DGDecodeNV sometimes gets halt on single core environment, i.e. if VDM is set to only execute on CPU core 0, loading an avisynth script with dgdecnv will halt the process, with 0% CPU usage.

When affinity of the process is set to more than one core, the same script can be loaded properly.

i7 4770, Win 8.1

A test clip for you: https://copy.com/FTgmAkcSA2r6

DGDecodeNV_dgsource("nvtest.dgi")

[Guest]

When affinity of the process is set to more than one core, the same script can be loaded properly. Please set the affinity to more than one for such use cases.

[Shevek]

When affinity of the process is set to more than one core, the same script can be loaded properly.

Please set the affinity to more than one for such use cases.

:goodpost: :rolleyes: :cool:

[Selur]

Got a path problem:
When having Japanese Characters like '言の葉の庭' in the path and feeding an mpls to DGIndexNV it doesn't recognize the mpls file. (file list is empty)
If I rename the path/folder to 'test' and feed the path to DGIndexNV everything is fine.
Using the command line options I also tried feeding the 8.3 filename instead of the normal path and still got the problem, so it seems like DGIndexNV has problems with such paths.
Would be nice if this could be fixed.

Cu Selur

Ps.: btw. I'm using an english Windows 7 64bit with DGIndexNV 2046.

[Groucho2004]

Got a path problem:
When having Japanese Characters like '言の葉の庭' in the path and feeding an mpls to DGIndexNV it doesn't recognize the mpls file. (file list is empty)
If I rename the path/folder to 'test' and feed the path to DGIndexNV everything is fine.
Using the command line options I also tried feeding the 8.3 filename instead of the normal path and still got the problem, so it seems like DGIndexNV has problems with such paths.
Would be nice if this could be fixed.

Cu Selur

Ps.: btw. I'm using an english Windows 7 64bit with DGIndexNV 2046.
I'm quite sure that it works. However, you have to change your system locale to cp932(JA) (or use Japanese Windows) so all non-Unicode text functions are translated properly.

[Selur]

You are right that would work, but that seems more like a workaround than a fix + if I got a few French, Japanese, German, Russian words mixed the switching workaround doesn't work either. ;)
Using wide char instead of normal char should help.
-> would be nice if this could be fixed/changed (a. shouldn't be hard to implement, b. users won't be forced to switch their locale)

[Selur]

btw. DGIndexNV also has problems with some 8.3 file names in the command line interface.
for example if I grab the 8.3 name for "I:\BDMV\PLAYLIST\00000.mpls", Win 7 sometimes returns something like "I:\BDMV\PLAYLIST\0001#NMQ.MPL" I know this seems like a really moronic (short file name which is longer than the original) output from Windows, but that's what GetShortPathName returns, problem is DGDecNV doesn't handle such a path properly.
I know this only is a problem if DGIndexNV is used from a command line, but still would be nice if that could be fixed too. :)

[Groucho2004]

Using wide char instead of normal char should help.
-> would be nice if this could be fixed/changed (a. shouldn't be hard to implement, b. users won't be forced to switch their locale)
a. Have you ported an application to Unicode? It's usually a pain in the hole.
b. "Normal" users don't change their locale, they use the locale that corresponds to their native language. It's also rather unlikely to assume that a user would have file/path names which consist of characters of various languages.

[Groucho2004]

btw. DGIndexNV also has problems with some 8.3 file names in the command line interface.
for example if I grab the 8.3 name for "I:\BDMV\PLAYLIST\00000.mpls", Win 7 sometimes returns something like "I:\BDMV\PLAYLIST\0001#NMQ.MPL" I know this seems like a really moronic (short file name which is longer than the original) output from Windows, but that's what GetShortPathName returns, problem is DGDecNV doesn't handle such a path properly.
I know this only is a problem if DGIndexNV is used from a command line, but still would be nice if that could be fixed too. :)
Make sure that the volume supports 8.3 file/path names when you use GetShortPathName().
The short name may be longer than the specified name, it's mentioned in the documentation.

Generally, I can't imagine any scenario that would require to use the short name of a file/path except with some ancient 16 Bit software.

[Selur]

Make sure that the volume supports 8.3 file/path names when you use GetShortPathName().
I know and yes, all my volumes support 8.3 file/path names.

Generally, I can't imagine any scenario that would require to use the short name of a file/path except with some ancient 16 Bit software.
Short name is normally a nice way to feed unicode file names or paths to applications which do not support unicode (you are right a lot of old 16bit tools fall under that category).

Have you ported an application to Unicode? It's usually a pain in the hole.
ported a few application and it wasn't really such a big deal, especially if a decent coding style/organization was used.

"Normal" users don't change their locale, they use the locale that corresponds to their native language.
I agree.

It's also rather unlikely to assume that a user would have file/path names which consist of characters of various languages.
Strange, I run into that rather frequently, especially when folks using different languages work together.
In example when a Russian and a Chinese swapping files and folders, from time to time you encounter the scenario that both share stuff where the folder structure contains some language specific symbols.
-> for me it's a normal thing in an internationalized world
(I for example frequently correspond with a Russian and a Chinese and thanks to that some of my folder structures are a colorful mix of languages. :))

[Groucho2004]

Strange, I run into that rather frequently, especially when folks using different languages work together.
In example when a Russian and a Chinese swapping files and folders, from time to time you encounter the scenario that both share stuff where the folder structure contains some language specific symbols.
-> for me it's a normal thing in an internationalized world
(I for example frequently correspond with a Russian and a Chinese and thanks to that some of my folder structures are a colorful mix of languages. :))
OK, you made your point and I agree that with a Unicode application these issues would not exist.

As for the likeliness of this being resolved, see here (http://neuron2.net/board/viewtopic.php?f=8&t=291).

[Selur]

As for the likeliness of this being resolved, see here.
..
I have two criteria that could trigger me to implement a feature: 1) I personally need it, or 2) a lot of people are asking for it.
-> at least I'm doing my contribution to point number 2 :)

Cu Selur

[MeteorRain]

-> at least I'm doing my contribution to point number 2 :)

Cu Selur

I guess you should be able to edit the d2v/dga/dgi files manually if the locale doesn't match.

Or just use alphabets instead of Unicode, and this is what I have been doing.

[Guest]

-> at least I'm doing my contribution to point number 2 :) Noted. We're up to 3 now. ;)

[LigH]

4. Not for myself only, but for everyone who may need it soon™...

[mikeyakame]

Unicode support would be great, I have too run into cases where I've had to rename files with characters outside my code page to index them.

I know the Avisynth side would pose a big problem, but at least Unicode as far as the internal index side of things (unicode filename referenced in index file, but index filename limited to characters of the systems locale) would be great.

[Guest]

Guys, I need some testing for my new licensing scheme (inspired by user sef, who found that every time he reconnected with his USB modem the machine ID changed!). I ditched the IP silliness and the need for multiple keys for different network configurations. Don't ask what I am using now for machine identification, because I won't tell you! Smart people will likely figure it out anyway (if you are thinking of forcing your HDD volume ID, forget it). So licensing should be much more stable now. The candidate 2047 build is here:

http://neuron2.net/dgdecnv/dgdecnv2047.zip

Please read the changes document and be aware you need to make a new license. Save your old one in case you need to back off.

If everything works fine, then I will make a formal release and update the registration instructions, etc. I'll probably do a mass license number reset for everyone as well. I will do this for all my tools as time permits.

Thank you for your testing.

[Groucho2004]

New license works for me.

[Guest]

Thanks Groucho. I'm dazzled that a barely conscious guy could figure this stuff out. Maybe your girlfriend helped you? :sly:

[Groucho2004]

I'm dazzled that a barely conscious guy could figure this stuff out.
Huh? Figure what out?

[Guest]

Huh? Figure what out? It was just a stupid joke based on the thing under your user ID at the left. Forgive me for my silliness.

[SeeMoreDigital]

Bummer...

I receive an 'Invalid Licence!' notification...

[Guest]

Please email me a screenshot of your Help/About dialog and attach the license.txt file you generated. Things should be working if you did the licensing properly.

[Groucho2004]

It was just a stupid joke based on the thing under your user ID at the left.
Outrageous! You cracking jokes! :eek:

Forgive me for my silliness.
Don't worry about it.

[SeeMoreDigital]

Please email me a screenshot of your Help/About dialog and attach the license.txt file you generated. Things should be working if you did the licensing properly.Ahaaaa...

After digging out the old email you sent me (Oct 2012) I sussed out where I was going wrong. It must be me who's "barely conscious" ;)

[Guest]

Good to hear. Thanks for your testing.

[Carpo]

Worked fine here, although I only have the one PC with an Nvidia card now, I could put an older card in one of the other PC's if you would like me to test on that too?

[Guest]

No need for that Carpo. Thanks for your testing.

[Carpo]

Will this licence change also make its way into DGDecodeIM ? Was going to try it out on my Laptop, but it says invalid licence, going to try it out on my old i7 2600, using your rat.264 file :p

[Guest]

Please re-read my first post describing the new licensing.

You can use your old license file for DGDecIM until it is updated.

[Carpo]

Guess I never added the laptop then :(