Strange glitch in encoded material

[tormento]

I have some strange glitches in encoded material. I have tried to reproduce them in frame by frame browsing of the script but no success. Here is a small sample:
http://img85.imageshack.us/img85/8959/cantando62mkvsnapshot00.th.jpg (http://imageshack.us/photo/my-images/85/cantando62mkvsnapshot00.jpg/)
I use DGDecNV and can't understand if it is a video card problem, a AviSynth one or from x264. I have tried to change video drivers and x264 builds, no idea. Has anybody seen such a problem?

[Guest]

Post a sample video clip! What am I going to do with a JPG?

[tormento]

Here (http://www.mediafire.com/?cb52w905jemk5o5) and the script is:

SetMTMode(5)
SetMemoryMax(2048)
LoadPlugin("D:\eseguibili\media\dgdecnv\DGDecodeNV.dll")
DGSource("E:\in\1_42 Cantando sotto la pioggia\cantando.dgi")
CompTest(1)
ChangeFPS(last,last,true)
SetMTMode(2)
SMDegrain (tr=6,PreFilter=2,thSAD=400,contrasharp=false,lsb=true,mode=6)


x264 2200 with avs4x264mod-0.8.0-git-r61(099ad2f)
dgdecnv latest
smdegrain 2.20 (on doom10)

[Guest]

I've never seen anything like that.

Try encoding without these things (just the source filter):

1. MT stuff
2. CompTest()
3. ChangeFPS()
4. SMDegrain()

If it still happens then I'll need a source sample. If it doesn't then add that stuff back one at a time to determine the culprit.

You know that DGDecNV is not supported in MT scenarios, right?

[StainlessS]

then I'll need a source sample

Source MKV supplied under 1st word "Here".

[tormento]

If it still happens then I'll need a source sample.
It appears randomly on any source.

[Guest]

Source MKV supplied under 1st word "Here". That link is to the encoded video.

[tormento]

I've never seen anything like that.

As I can't see the whole movie each time, is there any kind of script that could help me to find out the glitch? It is a line, each time, random colors, mainly primary and very well contrasted.

[tormento]

My findings:


it's not avs4x264mod 0.8 as 0.7 gives me same problem (and it worked before)
it's not AvsTP-1.0.1.dll as 1.0 gives me same problem (and it worked before)
it's not x264 2200 current compile, as I tried many


Still searching.

[tormento]

Reverting to forceware 301.24 has probably solved the problem. Damn drivers.

Neuron2: is possible to investigate reasons? I use CUDA decoding.

[Guest]

What driver version were you having the problems with? What nVidia card do you use?

Also, I'm still asking for the source sample for the problematic section.

[tormento]

What driver version were you having the problems with? What nVidia card do you use?

Also, I'm still asking for the source sample for the problematic section.
The latest beta gave me same problem. I am using a GTX 460 in CUDA mode.

The source sample is useless: pick any kind of BD and feed AviSynth multiple times for encoding. If you are unlucky enough, you'll notice that stupid line. The only thing I could not remember is if it was AVC or h264. I think AVC.

It gave me those lines on any encoding, randomly, almost 30-40 times on whole film lenght, different colors, usually well contrasted.

This afternoon, if any spare time, I'll watch some encoded material to definitely exclude that glitch.

[nibus]

I've actually come across the same thing with SMDegrain. I think it might be the mt modified mvtools2.dll, similar to my last findings: http://doom10.org/index.php?topic=2178.30

[Didée]

You know that DGDecNV is not supported in MT scenarios, right?
Problems with DGDecNV + Avisynth-Multithreading are known, but since when it is officially not supported? I read the documentation up and down, but can't find a note about that?


BTW, to enhance the "robustness" as much as possible, I usually do like

SetMemoryMax(800)
SetMTmode(5,4)

DGSource("file.dgi")
RemoveGrain(0) # No-Op filter, just to do frame request
ChangeFPS(last,last,true) # initiate a small forward buffer
RemoveGrain(0) # not sure if this 2nd one is needed. But surely it doesn't hurt.

SetMTmode(2)

## now comes the script ##

This doesn't fully prevent possible problems. But the chance of getting through without problems increases very much.

[tormento]

I was wrong, the glitch is still present.

I've actually come across the same thing with SMDegrain. I think it might be the mt modified mvtools2.dll, similar to my last findings: http://doom10.org/index.php?topic=2178.30

I suppose it's the same thing. If only he could read us on this forum.

[Pat357]

I think I have the same issue : colored horizontal lines on certain frames when using MVTools/avstp.dll.

see
http://www.mediafire.com/?baazz5slsn9epz8
http://www.mediafire.com/?wwhgli2lb6s66m0

If I use Mcompensate to create the "compensated frames", I have always these colored horizontal lines on my image.
If I use MFlow to create the "compensated frames", all looks OK.

I tried different combinations for blocksize (16,8 and 4) and with/without MRecalculate : for smaller block-size, the lines get thinner (less height), but they are always there.
(source is Lagarith Lossless 720 x 304 progressive , screenshot = 1920 x 1080 (MadVR).

I narrowed it down to MVTools/avstp.dll. My next step is to try it with a "non-multithreaded version" from MVTools.
Currently I use MVTools v2.6.0.4 for this script.

This is my script :


---------------------------------------------------------------------------------------
LoadPlugin("k:\programs\AviSynth 2.5\special filters\RemoveGrain-1.0pre (1.0 has a bug)\RemoveGrainSSE2.dll")
LoadPlugin("k:\programs\AviSynth 2.5\special filters\masktools-v2.0a48\mt_masktools-26.dll")
Loadplugin("k:\programs\AviSynth 2.5\special filters\degrainmedian082_20061008\degrainmedian.dll")
LoadPlugin("k:\programs\AviSynth 2.5\special filters\fft3dfilter211\fft3dfilter.dll")
LoadPlugin("k:\programs\AviSynth 2.5\special filters\deblock12\deblock.dll")
LoadPlugin("k:\programs\AviSynth 2.5\special filters\mvtools-v2.6.0.4\mvtools2.dll")
LoadPlugin("k:\programs\AviSynth 2.5\special filters\unfilter_v0.0.1.5__25_dll_20030116\UnFilter.dll")
Import("k:\programs\AviSynth 2.5\special filters\LimitedSharpenFaster avisynth_2.60\LimitedSharpenFaster.avs")
AVISource("k:\film\Safe-House-2012-DVDRip-xCrazy0328x\Safe_30__lagarith_mvdegrain3.avi", audio=false, pixel_type="YV12")
AssumeFPS(last,last,false)
clp0 = last
sclp0 = clp0.msuper(pel=2,levels=1,sharp=1)
clip = clp0.deblock(quant=51).blur(1)
sclip= clip.msuper(pel=2,sharp=1)
vf1=manalyse(sclip,isb=false, delta=1, overlap=4, truemotion=true, blksize=8) # divide=2
vb1=manalyse(sclip,isb=true, delta=1, overlap=4, truemotion=true, blksize=8)
vb2=manalyse(sclip,isb=true, delta=2, overlap=4, truemotion=true, blksize=8)
# vf1=Mrecalculate(sclip, vf1, overlap=4, blksize=8, truemotion=true, thSAD=280,smooth=1)
# vb1=Mrecalculate(sclip, vb1, overlap=4, blksize=8, truemotion=true, thSAD=280,smooth=1)
# vb2=Mrecalculate(sclip, vb2, overlap=4, blksize=8, truemotion=true, thSAD=280,smooth=1)
vf1=Mrecalculate(sclip, vf1, overlap=2, blksize=4, truemotion=true, thSAD=200,smooth=1,pnew=50)
vb1=Mrecalculate(sclip, vb1, overlap=2, blksize=4, truemotion=true, thSAD=200,smooth=1,pnew=50)
vb2=Mrecalculate(sclip, vb2, overlap=2, blksize=4, truemotion=true, thSAD=200,smooth=1,pnew=50)

## Mshow(sclip,vb1)
## __END__
compvb2=Mflow(clp0,sclp0,vb2,thSCD1=600)
compvb1=Mflow(clp0,sclp0,vb1,thSCD1=600)
compvf1=Mflow(clp0,sclp0,vf1,thSCD1=600)
# bcompvb2=Mcompensate(clp0,sclp0,vb2,thSCD1=600)
# bcompvb1=Mcompensate(clp0,sclp0,vb1,thSCD1=600)
# bcompvf1=Mcompensate(clp0,sclp0,vf1,thSCD1=600)

compvf1 ## (MFlow)
# bcompvf1 ## (Mcompensate)
BicubicResize(720,576)
__END__

#### Here we get the horizontal lines on bcompvf1, but not on compvf1. #####

E=interleave(compvb2, compvb1, clp0, compvf1)
fft3dfilter(E, sigma=3, plane=4, bt=4, bw=32, bh=16, ow=12, oh=6, sharpen=0, wintype=0, ncpu=6)
selectevery(4,2)
.....
more processing.....
----------------------------------------------------------------------------------------

System : i7-970 @ 3.8Ghz, 24 GB RAM @ 1600Mhz, NVIDIA GTX-570 , Win7 x64 Prof SP1
AviSynth 2.6 MT 32 bit (SET's latest version)

[Reel.Deel]

Are the horizontal lines deterministic? When I use SMDegrain v2.0d (http://doom10.org/index.php?topic=2178.0) with MVTools v2.6.0.4 the horizontal lines are nondeterministic.
Also, I did not experience this bug with the MVTools2 from the QTGMC package.

[Pat357]

Are the horizontal lines deterministic? When I use SMDegrain v2.0d (http://doom10.org/index.php?topic=2178.0) with MVTools v2.6.0.4 the horizontal lines are nondeterministic.
Also, I did not experience this bug with the MVTools2 from the QTGMC package.

No, they are non-deterministic.
I'll check with the MVTools version from the latest QTGMC.

[Pat357]

I just finished testing with MVTools-v2.5.14.2 : there are no strange lines visible ; this version is not affected.

Notice that this version is more recent than the one from the latest QTGMC-3.32 : the QTGMC-3.32 package includes MVTools v2.5.11.2 dated 2 April 2012.

Is there anything else I could check to help debugging ?

[tormento]

Is there anything else I could check to help debugging ?
There is nothing more we could do without author's attention.

[cretindesalpes]

I couldn't reproduce the bug on my computer but I think I found the cause. Could you try this dll (http://ldesoras.free.fr/tmp/mvtools2.dll-fix2.zip) and tell me if it works better?

[Pat357]

I couldn't reproduce the bug on my computer but I think I found the cause. Could you try this dll (http://ldesoras.free.fr/tmp/mvtools2.dll-fix2.zip) and tell me if it works better?

Thanks, I'll report back as soon as I've tested your fix.

Is this in fact the same problem as mentioned here on Doom10 ?

[mandarinka]

Is the bug only triggered by multithreading?
It's embarassing but I do use a singlecore...

[Reel.Deel]

I just tested the updated MVTools and I did not notice the horizontal lines or any other discrepancies. I used the same 6 min. source as with v2.6.0.4. Hopefully other users can confirm this.
Thanks again cretindesalpes.

[tormento]

I will do some encodings and tell you results.

[Pat357]

I have no longer artifacts when using the fixed version from MVTools that you provided.

As for me : problem is solved !!

Thank you !!

A small question though : why weren't the artifacts there when I used Mflow instead of MCompensate ?
Was the bug in the module "MCompensate" itself or were the artifacts just more hidden (invisible) due the interpolation(s) with neighbor-blocks in Mflow ?