Page 1 of 1
[RESOLVED] DGDecNV wrong frame on non-linear/random access
Posted: Tue Jan 03, 2012 11:41 am
by 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)
Re: DGDecNV shows wrong frame on non-linear/random access
Posted: Tue Jan 03, 2012 4:54 pm
by 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.
Re: DGDecNV shows wrong frame on non-linear/random access
Posted: Tue Jan 03, 2012 8:17 pm
by 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
Re: DGDecNV shows wrong frame on non-linear/random access
Posted: Wed Jan 18, 2012 12:13 pm
by admin
@mastrboy
Did you try it with Avisynth 2.58 stable?
Re: DGDecNV shows wrong frame on non-linear/random access
Posted: Wed Jan 18, 2012 12:40 pm
by 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?
Re: DGDecNV shows wrong frame on non-linear/random access
Posted: Fri Jan 20, 2012 8:12 pm
by 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
Re: DGDecNV shows wrong frame on non-linear/random access
Posted: Wed Feb 08, 2012 2:21 pm
by 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...)
Re: DGDecNV shows wrong frame on non-linear/random access
Posted: Wed Feb 08, 2012 3:07 pm
by 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.
Re: DGDecNV shows wrong frame on non-linear/random access
Posted: Wed Feb 08, 2012 3:19 pm
by 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
Re: DGDecNV shows wrong frame on non-linear/random access
Posted: Wed Feb 08, 2012 5:24 pm
by 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.
Re: DGDecNV shows wrong frame on non-linear/random access
Posted: Wed Feb 08, 2012 8:29 pm
by 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.
Re: [RESOLVED] DGDecNV wrong frame on non-linear/random acce
Posted: Thu Feb 09, 2012 9:18 am
by mastrboy
awesome and thanks
I will test and report back when i get home.
Re: [RESOLVED] DGDecNV wrong frame on non-linear/random acce
Posted: Thu Feb 09, 2012 12:31 pm
by mastrboy
Tested now, and can report that my problem is fixed
