Flicker/Pulsate Problem with QTGMC

[nfv]

I really like QTGMC but anything I use it on I notice that static areas in the picture move and are all warbly/flicker/pulsating.

You can see what I'm talking about in this clip here:
http://www.mediafire.com/download/49g6c1m561n961k/DEMI+3.mpg

Here is script I used on that clip:

QTGMC()
SelectEven()

And you will see the problem I am describing, most noticeable in the upper left hand corner (the walls flicker/pulsate).

Anyway to tweak QTGMC so it doesn't do this? Or is there something else I'm missing?

Thanks and any help would be very much appreciated.

J

[Groucho2004]

Can you post the original, unaltered clip? The one you uploaded seems to be edited with TMPGenc.

[nfv]

Can you post the original, unaltered clip? The one you uploaded seems to be edited with TMPGenc.

This is unaltered and yes I used TMPGEnc MPEG Editor 3. I just used it to cut a little piece of the movie out to show the issue I was having. I didn't change any settings. Thank you!

[Groucho2004]

You probably need some kind of image stabilizer/de-shaker. I'm not very knowledgeable about these things but I'm sure the Avisynth filter experts will chime in soon. :)

[johnmeyer]

Why are you processing this clip with QTGMC? What was the problem in the original clip that you were attempting to fix?

I ask this because the main function QTGMC provides is deinterlacing, and since your clip is from a PAL film source, I would expect that no deinterlacing is required. Thus, you may have created the problem by using the wrong tool (QTGMC) for the job.

[nfv]

Why are you processing this clip with QTGMC? What was the problem in the original clip that you were attempting to fix?

I ask this because the main function QTGMC provides is deinterlacing, and since your clip is from a PAL film source, I would expect that no deinterlacing is required. Thus, you may have created the problem by using the wrong tool (QTGMC) for the job.

You obviously haven't even downloaded the clip to make such a statement.

I am using QTGMC because even though the source is a PAL DVD, it's phase-shifted and full of interlacing. The company that produced the DVD didn't know what they were doing.

It can be fixed with:

TFM()

but.....it leaves aliasing. That is why I like QTGMC because it smooths away the aliasing.

QTGMC is doing it's job great by fixing the interlacing issues but I'm trying to figure out why it's causing the "flickering/pulsating" problem. That is my question.

Thanks,

J

[johnmeyer]

You obviously haven't even downloaded the clip to make such a statement.That is a pretty insulting statement. The reason I knew it was a PAL clip is that I downloaded it and looked at it. How else would I know that? Not only that, I deconstructed it into fields so I could see what was going on. What I was asking for is the original clip, before you did any processing.

However, since you don't appreciate my attempt to help you, there is no point in my providing any further assistance.

[edit]I just walked through the entire clip, one more time, field-by-field. There is no interlacing or phase shifting. Therefore, either this clip has already been processed or, if it is the original clip as you claim, there is no problem.

[colours]

johnmeyer: Get your head out of your ass. If you don't want to be insulted, stop being wrong.

The sample the OP posted does in fact have wrong phase and severe combing/aliasing artifacts.

Yes, ideally, the OP should've posted the source with absolutely no processing or reencoding. But an unfiltered reencode would be good enough to diagnose source issues, too.

[johnmeyer]

johnmeyer: Get your head out of your ass. If you don't want to be insulted, stop being wrong.Thank you for those kind remarks. It sure makes me feel good.

[colours]

You're quite welcome, if you're going to be all passive-aggressive at being called out for being wrong. (This isn't even the first time I've done that either!)

[LemMotlow]

Thank you for those kind remarks. It sure makes me feel good.TMPGEnc MPEG Editor 3 is a smart-rendering editor, not an encoder. You know what smart rendering is, right? You also know that TMPGEnc is a brand name, not a product name.

[johnmeyer]

TMPGEnc MPEG Editor 3 is a smart-rendering editor, not an encoder. You know what smart rendering is, right? You also know that TMPGEnc is a brand name, not a product name.Guys, I am a software engineer. Yes, I know what smart rendering is: cuts-only, without re-encoding, except for frames within the GOPs at the cut points. For cheap smart-rendering engines, cuts are only allowed at GOP boundaries and therefore there is no re-encoding at all. Except for the cut points, each frame in the resulting edited video file should be precisely identical to the original.

For the record, if you re-read all the posts above, you will see that it was not I who made the comment about TMPGEnc.

Must be a full moon tonight ...

[LemMotlow]

Yes, john, we know you're a software engineer. And this is related to video in....what way did you say?

The video sample has a field shift and field phase problem at about frame 30.
The sample is interlaced.

TMPGenc smart rendering encodes only a few starting and ending fields in a GOP. You can see the smart rendering in the two starting and two ending GOP's, which are nominally GOPs of 15 frames. The other, un-rendered GOP's are ridiculous 5-frame GOPs with a different field priority.

If you want completely unrendered frames from smart rendering editors, start a cut only on key frames. And don't tell your app that the video is TFF when it's really BFF, and vice versa. Another way to get same-as samples is to cut an m2v video file with the DGindex utility.

What's the story on this video? Where did it come from? Recorded off cable TV? I have 3 MPG recordings of this Lawrence Olivier movie and a DVD issue, but after just now looking at two of my cable recordings I see hard-telecined NTSC MPEG with 15-frame GOP's. I don't have a PAL version.

Maybe try DGIndex to make a cut to avoid any disputes.

[LemMotlow]

I really like QTGMC but anything I use it on I notice that static areas in the picture move and are all warbly/flicker/pulsating. Well, you can't blame QTGMC for someone's bad work. This video has been around the block more than a few times.

And you will see the problem I am describing, most noticeable in the upper left hand corner (the walls flicker/pulsate).You appear to have missed a few others. In the second nshot mof the clip, notice the black lamp post behind the guy speaking. In the last shot of the clip when the camera cuts to a medium shot of the man and woman in the car, they both appear out of focus briefly. In that shot there are blips and occasional "flips" or shift of small details along the right-hand side. The video also has flicker and vertical jitter. Now and then a detail will "bubble", "blister" or ripple briefly. Seems due to a poor source or master and bad processing on its way to you.

Anyway to tweak QTGMC so it doesn't do this? Or is there something else I'm missing?Find a better source. You can run motion smoothers on this clip all day long -- must be dozens of them around -- and end up with more image degradation and lost detail, but little gain. The distortion in this sample is the same thing I see on "HD"(sic) TV all day long 24/7/365. See it on retail issues, too.

Might look a little better if you run a deflicker and stabilizer. This is what I used:
LoadVirtualDubPlugin("Drive:\path\VirtualDub\plugins\Deflick.vdf", "DeFlick",1)
QTGMC(preset="very fast").SelectEven()
Stab()
ConvertToRGB32(matrix="Rec601",interlaced=false)
DeFlick(0, 8, 0, 0, 0)
ConvertToYV12(interlaced=false)
ReplaceFramesMC(301,1)
aWarpSharp2(depth=5)
AddGrainC(1.0,1.0)
Crop(2,2,-10,0).AddBorders(0,2,12,0)
grayscale()
return last

results: Demi3_25p.mpg
https://www.mediafire.com/?6d7q8a6vhb4vl0d

With bad source there are things you can fix, and things you can't.

[TheSkiller]

1) Ignore the field order transition that DGIndex wants to fix. The clip is 100% TFF.

2) It's field shifted.

3) After pairing the fields that belong together there's residual combing and aliasing left.

So my suggestion is:


DoubleWeave().SelectOdd()

QTGMC(InputType=2)

You can also use TFM(pp=0) instead of the DoubleWeave().SelectOdd() combo in case the field shift is not constant throughout the entire video.

Personally I would also make use of QTGMC's Noise Bypassing because the clip looks kinda artificial to me without the noise.

QTGMC(InputType=2, NoiseProcess=2, GrainRestore=1, NoiseRestore=0.5, NoiseTR=2)Looks OK to me.

[LemMotlow]

Thanks for the tips, TheSkiller. At 2-AM I just wanted a quickie -- we all know how those quickies overlook a few details. DoubleWeave didn't occur to me at that hour. Thanks again.

[Reel.Deel]

@nfv

If you're feeling adventurous try the suggestions posted here (http://forum.doom9.org/showthread.php?p=1574368#post1574368).

[johnmeyer]

I have some interesting findings to report.

I went back and looked at the clip again, but using a different software tool than what I usually use, and I can see why some of you think I have my head in a dark place. The problem around frame 30 is massive and obvious.

However ...

I went back and looked at the clip again using my normal software, which is what I used in my initial tests, and the clip played just fine, without any issues whatsoever at frame 30, or elsewhere.

So, when I posted above, I wasn't seeing any of the major problems that other people are seeing. I've had this happen before with some MPEG-2 files, but I'm not sure what causes the problem.

There is still a major issue with warping of the odd fields. If you do a separatefields() or bob() and then look at each field, you will see a huge amount of shift between the even and odd fields, but only in the upper right and upper left corners. In the middle of the frame, there is almost no shift at all (i.e., a normal amount of bob). In other words, the odd fields are warped (the way I count, the first field is odd). I would guess that this is what leads to the flicker that the OP reported. I will leave it to others to speculate how only the odd fields got warped, whereas the even fields appear to be linear (i.e., horizontal straight lines are still horizontal and straight). Perhaps some sort of resizing issue in the chain of events which led to this video.

To show you what I am seeing, here is an animated GIF showing the two fields from one frame. I scaled these back to 4:3 to make it easier to view. Look at the center of the frame and note the up/down shift and compare it to what is going on in the upper-left and upper-right corners. As you can see, the movement in the corners is far more than just the bobbing due to the offset between scan lines.

Odd/Even Field Showing Warp (http://i177.photobucket.com/albums/w208/johnmeyer/output_aqmpd5_zpsqbamymbv.gif)

Every frame in the entire clip has this same problem.

If I come up with some solutions, I'll report back.

[johnmeyer]

Reel.Deel linked to a Didée script that seems to fix the problems that I showed in my animated GIF.

Thank you, Reel.Deel!

The field phase shift issue didn't show up on my computer because I use a different workflow that I use to feed MPEG-2 files into my scripts (see my previous post). However, if you read Didée's post in the thread to which Reel.Deel linked, he explains how to deal with that. For this video, phase shift is not the difficult issue.

So, I removed the field warp using Didée's script, and then took that result and fed it into my version of VideoFred's film restoration script, but with most of the parameters turned way down, and the motion stabilization turned off, and deflicker enabled. I've uploaded the result, but in PAL DV format, just to make sure we eliminate any MPEG-2 reading errors from the discussion. Here is the result:

Fixed and Enhanced (http://www.mediafire.com/watch/ra7wrta4la5ta7e/Fixed_and_enhanced.avi)

[nfv]

1) Ignore the field order transition that DGIndex wants to fix. The clip is 100% TFF.

2) It's field shifted.

3) After pairing the fields that belong together there's residual combing and aliasing left.

So my suggestion is:


DoubleWeave().SelectOdd()

QTGMC(InputType=2)

You can also use TFM(pp=0) instead of the DoubleWeave().SelectOdd() combo in case the field shift is not constant throughout the entire video.

Personally I would also make use of QTGMC's Noise Bypassing because the clip looks kinda artificial to me without the noise.

QTGMC(InputType=2, NoiseProcess=2, GrainRestore=1, NoiseRestore=0.5, NoiseTR=2)Looks OK to me.

Thanks Skiller

I liked the results from this one the best

much appreciated

J:thanks: