problem with flickering

[LaughingMan]

Does anyone know how to deal with this flickering when whole screen is moving? Is there some filter for it? Thanks.

Sample (http://www.mediafire.com/file/jajedqvojsdzhz0/debugflicker.demuxed.m2v)

[Didée]

This is caused by deinterlacing that has done at some time before.

It's a good showcase for the "progressive" mode of QTGMC (http://forum.doom9.org/showthread.php?t=156028):

QTGMC(2,1,3,InputType=1,SLrad=2)

> Result (http://www.mediafire.com/?b3bpz7scxlauoy2) <

[poisondeathray]

nice showcase example

[manono]

It also works wonders on a lot of end credits for movies when the text is small and/or thin. Or Chinese. I've used it several times for that and been very pleased with the results.

[dansrfe]

wow I used the above line on a pre-deinterlaced, progressive source for the end credits portion and it looks brand new! I actually don't know if the settings Didée has for the source video on the OP is optimal for the source I have.

Sample (http://www.sendspace.com/file/b874sa)

[LaughingMan]

Thank you Didée, that definitely help with this scrolling text, but in some scene it doesn't help much, picture still looks like "under water" I tried some different setting but no luck.

Sample VOB (http://www.mediafire.com/file/b8vm6h1ic6tb6az/testflicker.demuxed.m2v)

Sample encode (http://www.mediafire.com/file/o7h1pvdrm6c2884/testflicker.mkv)

[Didée]

Well, you cannot recover all cases of prior destruction. Simple as that. In this scene, the period of the nyquist walkthrough is simply too long. You'd need a temporal window of, dunno, twenty or thirty frames to smooth that wavering out. Hard to tell if it would work out at all. And even if a hypotetical monsterscript would work for that, the next question would be why it doesn't work for action scenes ....

BTW, some very, very poor vertical scaling has been used at some former time. Notice those jaggies/discontinuities that appear roughly every 480/(540-480) pixels? :rolleyes:

[-Vit-]

It does need a temporal window of ~20 frames, but with this simple slow motion we can do something like that:
- Throw away four out of five frames (just during the pan)
- QTGMC the result - kinda approximation to big temporal window
- Motion interpolate to recover the missing frames - OK since motion is so simple

Specialized for this particular pan, so needs to be manually trimmed.

>> Result (http://www.mediafire.com/?gluukdcyncmik7q) <<


clip = FFMpegSource("yourpathto\testflicker.demuxed.m2v")

before = clip.trim(0,28) # Manually trim sections
broken = clip.trim(29,229) # ...
after = clip.trim(230,0) # ...

# Decimate 4 out of 5 frames. Tweak values depending on temporal radius required for source
step = broken.SelectEvery( 5,0 )

tgmc = step.QTGMC( 2,1,3, SLRad=3, InputType=1 )

# Motion interpolation to recover decimated frames. Use MFlowFPS for more complex motion
super = tgmc.MSuper( pel=2 )
bVec = MAnalyse( super, isb=true, blksize=16 )
fVec = MAnalyse( super, isb=false, blksize=16 )
fixed = tgmc.MBlockFps( super, bVec, fVec, num=clip.FrameRateNumerator(), den=clip.FrameRateDenominator() )

before ++ fixed ++ after

[Didée]

Good result. Let's hope there aren't like one hundred different such pannings in the source, each one with its own "speed" of panning ... :eek:

Oh, BTW ... do you get an idea why there was that hidden "slo-motion" secition in my TGMC_b2 script? Preparation for the unexpected. :):)

[-Vit-]

Oh, BTW ... do you get an idea why there was that hidden "slo-motion" secition in my TGMC_b2 script? Preparation for the unexpected. :):)
My exact thoughts as I wrote that script... "Now why didn't I add slo-mo to QTGMC". Well, I still got a few parameters left... :devil: