Getting weird artifacting at the same place when encoding

[djesteban]

Hi,

I re-encoded a BD movie I have the other day only to notice on playback that I had some weird corruption artifacts (here's a screenshot (http://imageshack.us/photo/my-images/20/videomkvsnapshot0038522.png/)) at one point in the movie. Since this never happened to me before, I made some research on the web as to what could've caused that, and all seemed to point at a hardware issue (bad RAM stick?!). Anyways, I stressed tested my system for a whole week (Memtest86+ for RAM, prime95 for CPU and furMark for my GPU) and I got nothing but a stable system.
So, I thought it might have been a "bad luck" kinda thing and rencoded the movie with the same settings. On playback, the image corruption happens at the EXACT same place... I then decided to update my x264 build thinking this might be causing it. After yet another re-encode... the artifact is still present at the same damn place! (as a side note the artifacting lasts for roughly 1 second)

Also, whether I load my AVS script in MeGUI and playback this part of the movie or even if I mux the source in a mkv container, there's no problem whatsoever. And to top it all, I used DGIndexNV to demux only about 5 minutes around the problematic area, encoded with the same settings I used to encode the whole movie and get NO artifact!

What the heck could be causing that! I mean, if it was a corruption caused by a hardware issue, I'm assuming it wouldn't always happen at the same place right?

If someone can help me with this, as to what is causing the issue, I would really appreciate... really curious to know what it is.

Thanks in advance,
Cheers

[Ghitulescu]

Are you sure your source is perfect?
Have you played your source (untouched, no encoded, no "scripted", just the raw source) in a player frame by frame? Try using more than one player, as some of them (I think here more towards the commercial players) tend to hide if the source has problems.

[SquallMX]

Hi,

I re-encoded a BD movie I have the other day only to notice on playback that I had some weird corruption artifacts (here's a screenshot (http://imageshack.us/photo/my-images/20/videomkvsnapshot0038522.png/)) at one point in the movie. Since this never happened to me before, I made some research on the web as to what could've caused that, and all seemed to point at a hardware issue (bad RAM stick?!). Anyways, I stressed tested my system for a whole week (Memtest86+ for RAM, prime95 for CPU and furMark for my GPU) and I got nothing but a stable system.
So, I thought it might have been a "bad luck" kinda thing and rencoded the movie with the same settings. On playback, the image corruption happens at the EXACT same place... I then decided to update my x264 build thinking this might be causing it. After yet another re-encode... the artifact is still present at the same damn place! (as a side note the artifacting lasts for roughly 1 second)

Also, whether I load my AVS script in MeGUI and playback this part of the movie or even if I mux the source in a mkv container, there's no problem whatsoever. And to top it all, I used DGIndexNV to demux only about 5 minutes around the problematic area, encoded with the same settings I used to encode the whole movie and get NO artifact!

What the heck could be causing that! I mean, if it was a corruption caused by a hardware issue, I'm assuming it wouldn't always happen at the same place right?

If someone can help me with this, as to what is causing the issue, I would really appreciate... really curious to know what it is.

Thanks in advance,
Cheers

Are you using DGIndexNV?, i was having a similar problem with Hall Pass (Theatrical Cut), that forced me to try DirectShow instead of DGIndexNV, the workaround worked, maybe is some kind of decoding bug that only happens under certain circumstances?, you should send a small sample of the affected area to Neuron2.

[setarip_old]

@djesteban

Are you playing your problematic backups from your hard drive or from burned discs?

[Guest]

Are you using DGIndexNV?, i was having a similar problem with Hall Pass (Theatrical Cut), that forced me to try DirectShow instead of DGIndexNV, the workaround worked, maybe is some kind of decoding bug that only happens under certain circumstances?, you should send a small sample of the affected area to Neuron2. Can't you send me your sample? I don't remember hearing about this from you.

[nibus]

I recently had the same problem with the Dumb and Dumber Bluray. I'll try to upload a sample of the VC-1 stream.

[Guest]

I wonder if it's related to multi threading the input. Are you guys doing that when encoding with x264?

[nibus]

I just use "DGSource("C:\filename.dgi",fieldop=0)" , don't know if that is multi-threading the input...

[Guest]

I meant threading by x264.exe when encoding. I don't know much about it so I could be totally off base.

[djesteban]

Are you sure your source is perfect?
Have you played your source (untouched, no encoded, no "scripted", just the raw source) in a player frame by frame? Try using more than one player, as some of them (I think here more towards the commercial players) tend to hide if the source has problems.
The source plays perfectly in playback and frame by frame in MPC-HC. When I load my AVS in MeGUI and open the player, I don't see a glitch either. Also, like I said in my OP, if I only demux 5 minutes of my source and encode that, I don't get the glitch.

Are you using DGIndexNV?, i was having a similar problem with Hall Pass (Theatrical Cut), that forced me to try DirectShow instead of DGIndexNV, the workaround worked, maybe is some kind of decoding bug that only happens under certain circumstances?, you should send a small sample of the affected area to Neuron2.
Yes I am using DGIndexNV. Must be a decoding bug like your stating because if it was a hardware glitch of some sort, I don't think the bug would be reproducible 3 times in a row at the exact same place in the movie.
Also, since I always use DGDecodeNV.dll, how would I use DirectShow to make a test and see if that's really the culprit? (I mean do I need any special plugin to decode h264 with directshow, could you give me an example of an avs please)
@djesteban

Are you playing your problematic backups from your hard drive or from burned discs?
From a hard drive obviously. And like I said the source is certainly not the issue here since it plays fine in at least 3 players.

I wonder if it's related to multi threading the input. Are you guys doing that when encoding with x264?
Well... good question. Not sure what you mean by that, but if multithreading is enabled by default when encoding with x264, then yes, if not, then I did not force any multithreading "mode" by using a special parameter.
Let me tell you the steps I followed here (and which I basically always follow when encoding):
- I index the original h264 stream with DGindexNV (cropping in DGindexNV directly if needed... but this particular movie was 1088 in height, so I left the 8 pixels autocrop on)
- This is my avs script
LoadPlugin("<PATH>\dgdecnv2041\DGDecodeNV.dll")
DGSource("<PATH>\video.dgi")
- To encode, I use LoRd_MuldeR's Simple x264 Launcher with a recent build of x264
... let me know if you need more info...

As for a sample, would you need a part of the glitchy problematic file? Because if I send you a sample of the original file, I don't think that would really help you since if I encode only a small section, I can't reproduce the problem... I would have to send you the whole video stream... or maybe would the dgi file help?

Thanks all for helping!!

[Groucho2004]

Also, since I always use DGDecodeNV.dll, how would I use DirectShow to make a test and see if that's really the culprit? (I mean do I need any special plugin to decode h264 with directshow, could you give me an example of an avs please)

Instead of DirectShowSource I suggest you try FFVideoSource implemented in FFMS2. Multiplex the video stream into a mkv container with mkvmerge and use the source filter like this:
FFVideoSource("xxx.mkv")
...
...

[TheRyuu]

What happens if you add ConvertFPS(last,last,true) at the end of your script?

i.e.
LoadPlugin("X:\path\to\DGDecodeNV.dll")
DGSource("X:\path\to\video.dgi")
ConvertFPS(last,last,true)

Instead of DirectShowSource I suggest you try FFVideoSource implemented in FFMS2. Multiplex the video stream into a mkv container with mkvmerge and use the source filter like this:
FFVideoSource("xxx.mkv")
...
...


ffms2 is not guaranteed to work with BDMV h264 files even if remuxed into mkv and especially if they're interlaced (will probably work ok if it's progressive, may possibly require a few special settings). The safest thing to do since he has access to DGDecodeNV is to try and figure out what's up with that as that is the preferred method (either of the DG Tools) for sourcing BDMV transport streams in avisynth.

[kemuri-_9]

I meant threading by x264.exe when encoding. I don't know much about it so I could be totally off base.

what threading are you referring to exactly?

x264.exe's own 'input threading' feature is more along the lines of 'read/decode the next frame while encoding the current frame'
rather than 'decode/read frames simultaneously'.

libx264 also threads the encoding, but that should never impact decoding as all of that revolves only around uncompressed data which is actually copied from the input provider.

So I'm not sure how these could impact your NV decoder...

[djesteban]

What happens if you add ConvertFPS(last,last,true) at the end of your script?

i.e.
LoadPlugin("X:\path\to\DGDecodeNV.dll")
DGSource("X:\path\to\video.dgi")
ConvertFPS(last,last,true)

I don't mind adding the ConvertFPS like you're suggesting but could you tell me what this would do? I guess you want me to put the ConvertFPS at the same FPS parameters then my original footage right?

ffms2 is not guaranteed to work with BDMV h264 files even if remuxed into mkv and especially if they're interlaced (will probably work ok if it's progressive, may possibly require a few special settings). The safest thing to do since he has access to DGDecodeNV is to try and figure out what's up with that as that is the preferred method (either of the DG Tools) for sourcing BDMV transport streams in avisynth.
Yeah... would really like to know what's going on with DGDecodeNV.. I mean it always worked nicely, don't know why it's acting up all of a sudden... Hope neuron2 can find what's causing the issue :P

[TheRyuu]

I don't mind adding the ConvertFPS like you're suggesting but could you tell me what this would do? I guess you want me to put the ConvertFPS at the same FPS parameters then my original footage right?

Frame caching. Thinking about it though it probably won't do a thing, I have no idea why x264 would be causing it but nothing else is, how does it look in vdub?

[SquallMX]

Can't you send me your sample? I don't remember hearing about this from you.

Unfortunately I trade-in the movie on BlockBuster for Thor so I can't longer send you a sample :(:(:(.

Back then I suspected that the problem was similar to the one with X-Men: First Class (That was before release 2041).

[7ekno]

I was getting alot of these type of macroblocking decode errors on GT2XX (tried 210/220/240) and DXVA decoding (that is, it would show up in MPC-HC using DXVA decode, but go when switched to CPU multithread ... POTPlayer did the same thing with DXVA enabled ...). It seemed to have a greater chance of appearing in more "complex" scenes (and often happened in similar frames, but never the same distortion and never the exact same frame number) ...

The funny behaviour with this thing is that with DGDecNV inside AsvPMod just using DGSource(), stepping thru frame by frame was PERFECT (and even serially clicking the left button on the frame advance at ~ 15 clicks per second was PERFECT), however, hold left click down on the "frame by frame" button so that it would run as fast as possible (sometimes at up to 110 FPS), and sure enough you would eventually get macroblocking (you had to be quick to see it and release the button, then step back to corrupt frame because there was only ~ 10 frame cache and if you went back to the corrupt frame that had to be re-read, it would come up normal again) ...

I did more experimenting, I imaged the OS from a mainboard using a PCI-E v2.0 slot + GT2XX cards to a mainboard using a PCI-E v1.0 slot + GT2XX cards and the macroblocking disappeared ...

I upgraded the GT2XX cards in the PCI-E v2.0 mainboard to a GT430, and the macroblocking disappeared ...

My only conclusion from all that I did was that their was some backwards compatibility bug in PCI-E v2.0 slots for PCI-E v1.0 cards that only reared it's ugly head when bandwidth started to get swamped ... It certainly wasn't a DGDecNV specific problem as it was common to all DXVA decoder implementations ...

Due to this, I don't recommend anything less than a GT430 for DXVA decoding tasks :P

Tek

[kypec]

Thank you very much for your detailed report, 7ekno. We can only hope that such errors won't occur on new coming PCI-E v3.0 capable mainboards with PCI-E v2.0 cards, which are currently all of them IIRC. :(

[Guest]

It certainly wasn't a DGDecNV specific problem as it was common to all DXVA decoder implementations ... Oh, good to know, thanks. I was imagining code in x264 like this:

open AVS script
grep DGSource
if found
break decoding

:)

Whoa, maybe I shouldn't give them ideas!

[djesteban]

Frame caching. Thinking about it though it probably won't do a thing, I have no idea why x264 would be causing it but nothing else is, how does it look in vdub?
In vdub, the original looks fine... the encoded result is messed up like in the screenshot.
I was getting alot of these type of macroblocking decode errors on GT2XX (tried 210/220/240) and DXVA decoding (that is, it would show up in MPC-HC using DXVA decode, but go when switched to CPU multithread ... POTPlayer did the same thing with DXVA enabled ...). It seemed to have a greater chance of appearing in more "complex" scenes (and often happened in similar frames, but never the same distortion and never the exact same frame number) ...

The funny behaviour with this thing is that with DGDecNV inside AsvPMod just using DGSource(), stepping thru frame by frame was PERFECT (and even serially clicking the left button on the frame advance at ~ 15 clicks per second was PERFECT), however, hold left click down on the "frame by frame" button so that it would run as fast as possible (sometimes at up to 110 FPS), and sure enough you would eventually get macroblocking (you had to be quick to see it and release the button, then step back to corrupt frame because there was only ~ 10 frame cache and if you went back to the corrupt frame that had to be re-read, it would come up normal again) ...

I did more experimenting, I imaged the OS from a mainboard using a PCI-E v2.0 slot + GT2XX cards to a mainboard using a PCI-E v1.0 slot + GT2XX cards and the macroblocking disappeared ...

I upgraded the GT2XX cards in the PCI-E v2.0 mainboard to a GT430, and the macroblocking disappeared ...

My only conclusion from all that I did was that their was some backwards compatibility bug in PCI-E v2.0 slots for PCI-E v1.0 cards that only reared it's ugly head when bandwidth started to get swamped ... It certainly wasn't a DGDecNV specific problem as it was common to all DXVA decoder implementations ...

Due to this, I don't recommend anything less than a GT430 for DXVA decoding tasks :P

Tek
The thing is I tried nearly EVERYTHING to find another way to make the source glitch (played it faster slower frame by frame...) and like I said in an earlier post, even demuxing and encoding a small sample of about 5 minutes around the area where the problem happens is not enough to reproduce the issue...
Also, the graphic cards I'm using is a Quadro 4000... so I don't think that is consider less than a GT430 :P
I still think the problem comes either from DGdecodeNV, but really don't have a clue why :(
I mean, playing the indexed dgi and going back and forth in it doesn't give me an error, and encoding a small sample of this area doesn't either...
Oh, good to know, thanks. I was imagining code in x264 like this:

open AVS script
grep DGSource
if found
break decoding

:)

Whoa, maybe I shouldn't give them ideas!
@neuron2: Do you know anything I could do to debug the issue? Do you need a sample or something?
Would testing it on my 8800GT be a good test to do? Any help would be appreciated to determine and find the cause of this issue...
Should I post the issue on your forum (I'm a registered user of your DGindexNV)

Btw... thank you all for responding, I really appreciate

[Guest]

Until someone gives me a stream that I can use to duplicate the issue, I don't know what to do about it. Surely someone can snail mail me a disk. I'll use it to reproduce the issue and then return it, to allay rule 6 concerns.

The other thing we can do is tabulate the system details of people that have the issue. We'd need:

Motherboard
OS
Type of slot used
Nvidia card type
more?

...and see if we can identify a common factor.

[djesteban]

Until someone gives me a stream that I can use to duplicate the issue, I don't know what to do about it. Surely someone can snail mail me a disk. I'll use it to reproduce the issue and then return it, to allay rule 6 concerns.

The other thing we can do is tabulate the system details of people that have the issue. We'd need:

Motherboard
OS
Type of slot used
Nvidia card type
more?

...and see if we can identify a common factor.
Ok, sounds good, I could snail mail you a drive, with the stream on it... I've got no problem with that. Before I do that though, I think I will try to make an encode with another graphic card I own... but unfortunately I don't have that damn card handy... hurgh... if I see it's going to take too much time to get my card, I'll just send the drive anyway... I'll contact you by email for address info.

Also, I am currently encoding the same stream using FFMS2 like someone suggested, for testing purpose (Though I had to remux the source in a mkv, heh...). I will post the result as soon as the encoding process finishes...
I mean.... theorically, if the encode succeed, that would only tell us that the source is not the issue here... but it wouldn't prove if the problem comes from DGdecodeNV or the graphic card since FFMS2 is CPU decoding right?

[Guest]

Right.

No need to mail the drive. Just a disk with the stream would be fine if you can make it fit. Or, if it is a commercial bluray, I'd be willing to buy it, as long as it is reasonably priced (don't make me buy a collection or box set that is beaucoup bucks).

[TheRyuu]

What's wrong with cutting out a small bit and uploading that as a sample?

[7ekno]

Or, if it is a commercial bluray

The opening anime type scene of Kung Fu Panda @ 1080p just after where the panda is eating food and the meanie thumps his fist down, then panda retaliates & objects fly everywhere is where I got the most repeatable macroblocking problem on GT2XX cards ...

PS I think the Quatro 4k has the same VP chip as the GT2XX's ...

I started to document the issue here:
http://forum.doom9.org/showthread.php?p=1429801#post1429801

But because of the randomness and fixed with a card swap to GT9800 (and finally a GT430), I didn't bother following up the issue ...

You can see those posts were made amidst me trying the entire GT2XX line of cards, but the GT240 mentioned didn't fix the issue (at that stage I had only tried GT210 and GT9800). The GT430 DID fix the issue :P

7ek

[Guest]

What's wrong with cutting out a small bit and uploading that as a sample? People are reporting it doesn't happen when they do that! That's what makes this a difficult problem.

I'd like to know if anyone sees this on cards *other than* 2xx.

[djesteban]

What's wrong with cutting out a small bit and uploading that as a sample?

Dude, with all due respect, if you would've read the thread, you wouldn't have asked this question. I've repeated at least 3 times in this very thread that it doesn't happen on a small sample....

[Ghitulescu]

Maybe the GPU/VRAM became overloaded somehow, maybe they expect a MAX_VALUE for something, maybe the allocated buffers simply overflew (videoframe, GOP, refs etc.), which is definitively related to the source.
Have you disabled any HW accelerations and still got this error, to get the graphic card or its drivers out of the problem?

[djesteban]

@neuron2:
Ok! So my encode using FFMS2 just finished and doesn't exhibit any problem, so the part that was glitching before is fine now.

Also, another thing I just noticed with the glitchy encode is a running time discrepancy; it runs for 1:47:47.258 whereas the source and the FFMS2 encode clocks in at 1:47:40.791

Now, I won't swear that the FFMS2 encode is ok at 100% until I watch it completely... but at least we know it's not the source that's corrupted and have a better idea of what's causing the issue.

BTW here's my machine's spec:
MS Windows 7 Ultimate 64-Bit SP1
Intel Core 2 Quad CPU Q9450 @ 2.66GHz
8.0GB RAM
Nvidia Quadro 4000

The movie I used for this encode test is:
Jiang Hu - The Triad Zone (http://www.blu-ray.com/movies/Jiang-Hu-The-Triad-Zone-Blu-ray/23977/)
YesAsia sells it for around 20 bucks (not linking since I don't want to look like I'm making free publicity)... if that's too expensive, let me know and I'll send you a drive or a disc with the source elements on it!

[djesteban]

Maybe the GPU/VRAM became overloaded somehow, maybe they expect a MAX_VALUE for something, maybe the allocated buffers simply overflew (videoframe, GOP, refs etc.), which is definitively related to the source.
Have you disabled any HW accelerations and still got this error, to get the graphic card or its drivers out of the problem?

I have never HW accelerated anything here. Stock Nvidia driver with no SW or HW mod.
Also, it's good your pointing out drivers, because between my first encode and my second shot at it, I updated my GPU drivers from v270.71 to v276.14 (which I'm still running)... and the issue was identical.
Regarding GPU/VRAM becoming overloaded, I'm wondering why it would happen when I encode the whole movie, but not when encoding a 5 minutes (5 min before and 5 min after) sample around the problematic area... I mean if anything was overloading because of this particular part in the source, it would certainly do it in that type of sample...
Now, I'm not excluding that the source is not part of the problem's equation, but I don't think it's the main culprit here.

[levicki]

Also, another thing I just noticed with the glitchy encode is a running time discrepancy; it runs for 1:47:47.258 whereas the source and the FFMS2 encode clocks in at 1:47:40.791

From what I know, this is because FFMS2 supports frame accurate seeking and DGIndex(NV) does not.

If you open both files and manually select the same frame in VirtualDub you will see they are different. From my experience, DGIndexNV frame that corresponds to the frame you selected in FFMS2 can be 2-4 frames behind the actual frame number.

[Guest]

From what I know, this is because FFMS2 supports frame accurate seeking and DGIndex(NV) does not. DGDecNV is frame accurate, and it functions correctly in cases that flummox FFMS2.

[levicki]

Apparently you don't know much, because that is ridiculous. DGDecNV is frame accurate, and it functions correctly in cases that flummox FFMS2.

I never said I know much. That is exactly why I wrote "from what I know" :)

Maybe I got confused because your website doesn't explicitly mention the term "frame-accurate" in the application description -- instead it is "burried" in the manual which so far I didn't have to read since using the application is so simple.

Because he mentioned time discrepancy I thought it might be worth mentioning that with certain source I also get different frames for the same frame numbers with DGDecNV and FFMS2.

Given that FFMS2 so far provided me with frame-accurate results where most other DirectShow decoders failed, I assumed that the problem might be with DGDecNV. In the meantime I checked FFMS2 docs and found this:

Haali's splitter requires transport streams to be cut at packet boundaries.

and:

VOB, MPG: Seeking seems to be off by one or two frames now and then

It seems that I was wrong, and hereby I apologize for not doing my homework.

[CruNcher]

black belt levicki here ? welcome :P
donalds parser is hard craftsmanship and hardly comparable to ffms2 ;)
for those who doesn't know levicki http://software.intel.com/en-us/profile/61352/

[Guest]

In email, it became clear that levicki was confused by the fact that playing from an open GOP will show a few macroblocked frames if the start is an open GOP. I responded as follows:

DVD GOPs are usually open! So if you start at a random point then you are
starting to decode an open GOP. Here is what the manual says:

---
The Play/Preview commands decode and display all frames from the starting point,
i.e., they do not suppress orphaned frames, if any, at the start of the GOP.
So you may see macroblocking on the first few frames of a Play/Preview operation
if your stream has open GOPs. Note that this is purely a display matter in DGIndexNV;
it never occurs in the frame-served video or in demultiplexed video files. While such
frames could have been suppressed, DGIndexNV is intended for analysis and not playback;
it can be useful to operate this way because one can easily identify open GOPs in the stream.
Note that when navigating on the timeline when stopped, orphaned frames are suppressed.
---

When serving your video via the script, the initial orphaned frames are replaced by
copies of the first decodable frame. This way, all the frames in the source stream
have a counterpart in the output. That's part of being frame accurate, because you want
frame number N in the input to also be frame number N in the output. That would not be the
case if ophaned frames were discarded.

I join CruNcher in welcoming levicki to the forum.

[djesteban]

Found another movie getting a glitch while using DGdecodeNV...
Not the same type of glitch though; this one seems to be a "frame repeat" type of issue... what I mean by that is let's take 10 frames around the problematic area... The encode is suppose to be something like "ABCDEFGHIJ" (one letter means a frame), but it encodes as "ABCDEBGHIJ"... only happens once through the whole movie... at least from what I was able to detect... I was able to reproduce the problem more than once, at the exact same place in the footage. I will try to upload a sample of the glitch when I have a minute.
This is really starting to worry me since I now can't trust my encodes without watching every damn encode like a hawk.

Now I checked some older encodes I have and there's no problem at all.... still strange that it does that with those two movies :(

[looney]

... BD movie. I had some weird corruption artifacts (here's a screenshot (http://imageshack.us/photo/my-images/20/videomkvsnapshot0038522.png/)) at one point in the movie.

That resembles as problem from VOBs iirc from my day of reenc some DVDs. It usually happens on VOB splits so if you have mannually check your vobs you'd probably saw this is first scene on some of them. It's poor that vobs are only 1024MB, but tats usually something wrongly produced DVD/BD and it doesnt shows itself neither in DVD reproduction nor in copied DVD onto hdd.

[SquallMX]

Unfortunately I found another movie with the same problem, when the AVS script is loaded on VDub the image is perfect, but the encoded file is corrupted, happens in the same place regardless of the x264 settings.

Original stream on VDub:
http://img196.imageshack.us/img196/316/corrupteddgindexgh.png
Video Sample (http://www.mediafire.com/?6ph77azc5xxxd7z)

1080p Re-encode stream on VDub (Blu-ray compilant):
cabac=1 / ref=2 / deblock=1:-3:-2 / analyse=0x3:0x113 / me=hex / subme=6 / psy=1 / fade_compensate=1.00 / psy_rd=1.00:0.10 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=12 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / fgo=0 / bframes=2 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=1 / keyint=24 / keyint_min=2 / scenecut=40 / intra_refresh=0 / rc_lookahead=24 / rc=2pass / mbtree=1 / bitrate=18000 / ratetol=1.0 / qcomp=0.60 / qpmin=5 / qpmax=40 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=30000 / vbv_bufsize=30000 / nal_hrd=vbr / ip_ratio=1.10 / aq=1:1.00
http://img193.imageshack.us/img193/3769/corrupteddgindex.png

720p Re-encode stream on VDub (DXVA compilant):
cabac=1 / ref=4 / deblock=1:-3:-2 / analyse=0x3:0x113 / me=umh / subme=7 / psy=1 / fade_compensate=1.80 / psy_rd=0.90:0.09 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / fgo=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=1 / keyint=48 / keyint_min=4 / scenecut=40 / intra_refresh=0 / rc_lookahead=48 / rc=2pass / mbtree=1 / bitrate=5000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=44 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=15000 / vbv_bufsize=15000 / nal_hrd=vbr / ip_ratio=1.10 / aq=1:0.90
http://img171.imageshack.us/img171/3800/corrupteddgindex720p.png
Video Sample (http://www.mediafire.com/?z5ox83xzs6urpps)

Simple AVISynth script with only DGIndexNV and the resize filter (if needed)

If I only encode a small sample around the affected frames everything is Ok.