[RESOLVED] DGDecNV wrong frame on non-linear/random access

[mastrboy]

Bug report about DGDecNV displays wrong frame on random/non-linear access, but correct frame on linear access:

Some information about the encoding OS and avisynth setup:
Operating System: Windows 7 Enterprise, 64-bit (Service Pack 1)
GPU processor: GeForce GTX 260
Driver version: 285.62
Avisynth 2.6 with MT fixes from sET (http://forum.doom9.org/showthread.php?t=148782)

I have managed to produce the bug with dgdecnv2040 and dgdecnv2041, bug does not exist on good old DGIndex 1.5.8
Tried different settings in DGIndexNV.ini file for UseD3D=0/1 and Decode_Modes=0,0,0/1,1,1 without that resolving it.

Sample file cut with DGsplit 1.0: http://www.mediafire.com/?fx9zh66u2ugvw95

On to the bug itself, using AVSPMod/Virtualdub stepping from frame 0 to 50+ no problems occour with the decode, if you randomly skip back and forth it will decode a different from what you would see with linear access.
To reproduce: Open avs script i AVSPMod, step frame by frame until frame 33 and hit F5. (Or use virtualdub and hit F2 for reload script)

My avs script:
DGSource("D:\Vobs\VTS_01_1.VOB.dgi",fieldop=0,crop_r=8,crop_l=8,debug=true)

Images of bug:
http://img441.imageshack.us/img441/7595/linear33.png (linear access, correct frame)
http://img831.imageshack.us/img831/4126/nonlinear33.png (non-linear/random access, wrong frame)

[admin]

I'll try to reproduce it tonight but note that I make no claims regarding proper functioning with MT builds. You are on your own in MT land.

[mastrboy]

Thanks

Hopefully you will consider this as a bug since DGIndex 1.5.8 works fine, but i understand avisynth 2.6 MT version can't be supported on the same level as 2.5 stable

[admin]

@mastrboy

Did you try it with Avisynth 2.58 stable?

[mastrboy]

No, i have not yet tried with avisynth 2.58

But i think this could be a problem with either source or how DGDecNV handles this source as i found a "strange" workaround:
In DGindex 1.5.8 use "Save project and Demux video", then index the m2v file with DGDecNV, and the problems is "gone". (Even in avisynth 2.6)

Edit: I see you uploaded a new slipstreamed hotfix version, i'll try that one too and report back.. I am hoping to avoid going back to avisynth 2.58, as i see some major speed increases for resizers like spline36resize and SetMTmode actually works without randomly crashing in avisynth 2.6...

Edit2: Any chance you could build DGDecodeNV.dll against avisynth 2.6 headers so i could test that too?

[mastrboy]

Was hoping for increased compatibility with 2.6, though i have not checked out the differences between 2.5 and 2.6 avisynth.h

[mastrboy]

I have probably found the reason for the "bug", but not the cause within DGindexNV...

The problem lies within the .dgi files, somehow with setting random settings i managed to get DGindexNV to produce a .dgi file in which this problem is gone, i compared it to the .dgi file with the problem and found that the problem file is "missing" on the first SEQ:

Good .dgi file:

Code: Select all

DGMPGIndexFileNV14 DGIndexNV 2041 X32
D:\dgdecnv2041\

D:\Vobs\EP012\VTS_01_1.VOB 1423271936

DEVICE 0
STREAM 3
CLIP 0 0 0 0
RANGE 0 0 1423271935 0
AUDIO a0

SEQ 4129
SEQEXT 0
GOP 0 5
0:FRM I 3 1 0 0
1:FRM B 3 1 0 0
2:FRM P 3 1 0 0
3:FRM B 3 1 0 0
4:FRM B 3 1 0 0
5:FRM P 3 1 0 0
6:FRM B 3 1 0 0
7:FRM B 3 1 0 0
8:FRM P 3 1 0 0
9:FRM B 3 1 0 0
10:FRM B 3 1 0 0
11:FRM P 3 1 0 0
SEQ 381914
..........
CODED 35664
PLAYBACK 35664

Bad .dgi file:

Code: Select all

DGMPGIndexFileNV14 DGIndexNV 2041 X32
D:\dgdecnv2041\

D:\Vobs\EP012\VTS_01_1.VOB 1423271936

DEVICE 0
DECODE_MODES 0,1,0
STREAM 3
CLIP 0 0 0 0
RANGE 0 0 1423271935 0
AUDIO a0

SEQ 4129
SEQEXT 0
GOP 0 5
0:FRM I 3 1 0 0
1:FRM P 3 1 0 0
2:FRM B 3 1 0 0
3:FRM B 3 1 0 0
4:FRM P 3 1 0 0
5:FRM B 3 1 0 0
6:FRM B 3 1 0 0
7:FRM P 3 1 0 0
SEQ 381914
.............
CODED 35660
PLAYBACK 35660

Both files where produced with DGDecNV 2041 newest build from Jan 18: viewtopic.php?p=1822#p1822

Currently i'm not sure what setting fixed it, but when i reset my DGIndexNV.ini after customizing it, it reverted to creating that bad dgi file with 4 missing frames.

Any ideas?

EDIT: Cause within DGIndexNV found, the problem is solved if i disable Audio Demuxing. Re-enabling it reintroduces the issue immediately.
(Audio demux problem is also probably the reason my workaround with demuxing the video to a m2v file and using that was working...)

[admin]

Is this with Avisynth MT or plain vanilla? If it is plain vanilla I will investigate. If it is with MT you are on your own.

[mastrboy]

Is that relevant now that i have confirmed that it's DGIndexNV that makes a mistake when creating the .dgi file when audio demuxing is enabled?
I didn't know DGIndexNV was dependent on avisynth at all for creating the index files? Or have i misunderstood how the indexing works?

Avisynth version is still the same as in the first post: Avisynth 2.6 with MT fixes from sET (http://forum.doom9.org/showthread.php?t=148782)

edit: I'll test with 2.5 vanilla from sourceforge anyways just to make sure...

edit2: Done testing with 2.5 vanilla, swapped out avisynth.dll in C:\Windows\SysWOW64, rebooted twice to make sure. Still able to produce the problem when Audio demuxing is activated.

.dgi file with 2.5 vanilla:

Code: Select all

DGMPGIndexFileNV14 DGIndexNV 2041 X32
D:\dgdecnv2041\

D:\Vobs\EP012\VTS_01_1.VOB 1423271936

DEVICE 0
DECODE_MODES 1,1,1
STREAM 3
CLIP 0 0 0 0
RANGE 0 0 1423271935 0
AUDIO a0

SEQ 4129
SEQEXT 0
GOP 0 5
0:FRM I 3 1 0 0
1:FRM P 3 1 0 0
2:FRM B 3 1 0 0
3:FRM B 3 1 0 0
4:FRM P 3 1 0 0
5:FRM B 3 1 0 0
6:FRM B 3 1 0 0
7:FRM P 3 1 0 0
SEQ 381914
.....
CODED 35660
PLAYBACK 35660

avisynth.dll info:
File version: 2.5.8.5
Date: 21.12.2008 22:46
CRC32: 9B8B8D11
MD5: F498E945211157E0063CE9ED6E679F1D
SHA-1: EE0BF01FBBE7730638E2AD2DD44C75B3F18ED9A2

[admin]

I've duplicated it. Nice work on isolating the critical factor. I expect to have it fixed shortly. Looks like a bug in LPCM audio demuxing.

I usually work on video bug reports with audio demuxing turned off (to not clutter my directories), so that is why I was not able to duplicate this earlier.

[admin]

OK, all fixed up. Please re-download 2041 and test it. When you give the A-OK, I will update the main thread.

Thanks for pointing this out and being persistent in helping me to duplicate it. It was indeed a bug in LPCM audio demuxing for program streams.

Is that relevant now that i have confirmed that it's DGIndexNV that makes a mistake when creating the .dgi file when audio demuxing is enabled?
I didn't know DGIndexNV was dependent on avisynth at all for creating the index files? Or have i misunderstood how the indexing works?

No, it's not dependent on Avisynth. My point was that I am not going to put MT on my system to try to reproduce something. So I wanted you to assure me it was broken with plain vanilla. With MT, you never know what weird things can happen.

[mastrboy]

awesome and thanks

I will test and report back when i get home.

[mastrboy]

Tested now, and can report that my problem is fixed