blinking line on top or bottom when yadif bob

[MasterYGM]

with yadif(mode=1) some dvd show blinking thin line on top or bottom.

usally i crop this by letterbox(0,2) or letterbox(2,0) because this will reduce compressiblilty.

why this blinking happen? and how can I handle this with one general script?

[Forteen88]

Have you tried
TempGaussMC_beta1mod(EdiMode="NNEDI2").SelectEven()
instead?

[MasterYGM]

Have you tried
TempGaussMC_beta1mod(EdiMode="NNEDI2").SelectEven()
instead?

I know TGMC is best for quality. but it's too slow for me.

[Didée]

On the topmost and bottommost line, there are not enough neighbor pixels to make a spatial estimation from.

The issue can be worked around by manually padding the input clip:

mpeg2source(...)
pointresize(width,height+8,0,-4,width,height+8.001)
Yadif(mode=1).crop(0,4,-0,-4)

Et voila, no more blinking lines on top or bottom. BTW, that's the same padding method that TGMC uses.


Edit: just got aware of

because this will reduce compressiblilty.

Just to have it noted ... I surely understand if you consider TGMC as too slow for you. But, consider also that TGMC usually will give a result that is *way* more compressible than what Yadif (or any other deinterlacer/bobber) produces. It depends on the source and used settings, but 10~20% better compressability are almost guaranteed. I've seen cases where TGMC after q2-encoding had almost *half* the filesize of Yadif...

[Gavino]

Didée, why the extra .001?

[Didée]

Because occasionally, I'm still using AS v2.5.6. And it is realistic to assume that other people out there still do, too.

Remember that in 2.5.6, the resampler went NOP when in/out sizes were exactly the same, no matter the offset.

Yes it looks strange, but it works in all Avisynth versions. "Keep backward compatibility as long as possible!"

I prefer it that way. Else, people might try it, find "what crap is he telling, it does not work", and keep wondering in silence.


Edit:
Okay, I've beaten myself: In this case here, that epsilon thingy would not be needed.
I rephrase: In AS 2.5.6, the resizer would go NOP under some certain conditions.
... And since I can't remember for sure which the exact conditions are, I keep adding the epsilon thingy to be always on the safe side.

[Gavino]

Ah, I thought it might be something like that.
2.5.6 was before my time, so I'm not sure exactly what form the bug took. But here the in/out heights are not the same,
In: height
Out: height+8

[Didée]

Yeah ... thinking about it, it could be the bug first stroke me when doing subpixelshift-correction for NNEDI, where input/output sizes are equal. Forbear with a dodderer.

Just to confirm my claim about compressibility, I've run the "Musicians" test sequence through Yadif(mode=1) and TGMC(2,2,1,4,4,0,"bcbc"), encoded to Xvid@q2. (see, a dodderer)

Here they are:

Yadif - 14320 kB
TGMC - 7452 kB

I'm not sure if it's the visual appearance or the different bitrate requirement which is more remarkable.

***

For completeness: the Yadif sample was done *with* forementioned calming of the blinking lines. Without that, the resulting filsize was 14396 kB.

Easy math: calming of the blinking scanlines "improved" Yadif's compressibility by 0.005%. { (14396-14320)/14396 }
Whereas TGMC improved compressibility by 48%. { (14320-7452)/14320 }

(This falsely includes container overhead, but with those numbers that's completely irrelevant.)

[MasterYGM]

workaround script could produce artifact. is there any better way?

Original


Resize and crop

[Didée]

Workaround script does not produce artifacts. You certainly produced error in script. Post your script.

[MasterYGM]

ImageReader("rings_lg_orig.png")
pointresize(width,height+8,0,-4,width,height+8.001)
crop(0,4,-0,-4)

I tested script to resize test pattern image.
rings_lg_orig.png is 'Original' from previous post.

that script could fill top or bottom blinking line. but could produce another artifact.

[Gavino]

Originally Posted by MasterYGM

ImageReader("rings_lg_orig.png")
pointresize(width,height+8,0,-4,width,height+8.001)
crop(0,4,-0,-4)

Did you forget to put in the deinterlacer?
What you have there is an identity filter.

Or at least it should be. Are you in fact saying that it isn't?

EDIT: I've just tested it with Compare and it produces 100% identical image to original.

[MasterYGM]

see the second image i posted with 100% actual size. then you can see horizental crack about 100pixel below from top.
image is already changed before deinterlacer. so putting deinterlacer or not is not important.
if you see 100% idential image after script then it's maybe you are using another simple image as source or using another script.

[Didée]

Bad news for you, but ... using exactly the "ringslgorig.png" provided by you, and using exactly the script you posted, I get a result that is exactly identical to the input. No artifacts anywhere. And that's exactly what is expected to happen.

BTW, the artifact you show is not ~about~ 100 pixels from the top, it appears exactly at the 128th line. A funny number, that might indicate that some routine of some application somewhere on the long way to the compressed output might have a problem. Whatever it might be, don't know. But it's extremely unlikely that Avisynth is the culprit. And the script is correct.

Now it's up to you to provide more information about which programs (and their versions) you're using to open the script, and to save the PNG. In case of doubt, use VirtualDub (or -Mod).

[MasterYGM]

I'm using AvsP 2.0.2 to run script and capture
AviSynth version is 2.57 tsp MT version 5

[Gavino]

Try this script:

ImageReader("rings_lg_orig.png")
orig = last
pointresize(width,height+8,0,-4,width,height+8.001)
crop(0,4,-0,-4)
Compare(orig)

You will see a difference of zero, showing the two are identical.

[Didée]

Strange, but interesting.

I never used AvsP up to now, and Im not running any special MT-version ov Avisynth. (I've only single-core PCs, that's why.)

The script is expected to work (because it is correct), and it does work correct with the official Avisynth versions 2.56 and 2.58, in VirtualDub (and /Mod), and in all mediaplayers I tried (ZoomPlayer and mplayer2.exe).

So it seems that either AvsP, or the MT build of Avisynth is to blame.

Try to use just "+8" instead of "+8.001" (which is perfectly okay), perhaps the rounding is off for some reason.

If that ain't help, try vanilla VirtualDub instead of AvsP.

If that ain't help, try a standard Avisynth build.

[MasterYGM]

with 8.001 and Compare...

Main Abs Dev: 90.1333 (90.133/90.133/0.006)
Mean Dev: +0.0064 (+0.006/+0.006/+0.006)
Max Pos Dev: 228
Max Neg Dev: -228
PSNR: 7.78 dB (7.78/7.78/7.78)
Overall PSNR: 7.78 dB

I'll try other version of AviSynth later.

Edit: same result with AviSynth 2.58, Build Dec 22 2008 [08:46:51]

and same with VirtualDub too.

[Didée]

Hmmm ... I remember vaguely some discussion about pointresize and sample positioning, though long time ago. Perhaps the internal code for pointresize isn't the same in MT-Avisynth?

Try with e.g. bicubic instead:

ImageReader("rings_lg_orig.png")
orig = last
bicubicresize(width,height+8, .33,.33, 0,-4,width,height+8)
crop(0,4,-0,-4)
Compare(orig)

Better, or is it the same disaster?

[Gavino]

The problem is due to RGB 'starting at the bottom'.

pointresize(width,height+8,0,-4,width,height+8.001)
needs to be replaced by
pointresize(width,height+8,0,-4,width,height+7.999)
but
pointresize(width,height+8,0,-4,width,height+8)
works OK anyway.

When I tested it yesterday, I used a YV12 clip, so 8.001 worked.

See the problem you caused with your outdated 2.5.6 attachment Didée...