separatefields() and qtgmc() cause a 'jump' at the bottom of the video

[pooksahib]

Hi. As I usually do with a DVD, I scripted it with megui and checked for combing. There was combing and so I added separatefields() to the script to confirm it was interlaced (it was). The video preview, however, is now 'jumping' as if every second frame is a different height than its neighbour by a pixel. I added assumetff() then assumebff() prior to separatefields() but to no effect. Scripting with just qtgmc() also causes the jump.

Hopefully someone recognises what I'm describing and can tell me the cause and cure. Thank you.

[poisondeathray]

Don't separate fields then apply deinterlacer . It's one or the other .

Either look at the individual fields, or check with bobber. Not both

[jagabo]

separatefields()... The video preview, however, is now 'jumping' as if every second frame is a different height than its neighbour by a pixel

Of course. The lower field is now in the wrong vertical position relative to the upper field.

provide a sample...

[pooksahib]

Good morning. I wasn't using separatefields and qtgmc simultaneously ("Scripting with JUST qtgmc() also causes the jump").
Using separatefields first was to confirm it was truly interlaced. This is the guide I follow: "...if there is motion every field, it is interlaced, so you deinterlace using QTGMC. If there is motion every two fields, it is telecined, so you IVTC using TFM".

As requested, a short clip. Thanks for your time, guys.

[poisondeathray]

Sorry I misunderstood the "and" in the title "separatefields() and qtgmc()"

MPEG2Source()
AssumeTFF()
AddBorders(0,8,0,8)
QTGMC(preset="faster", border=true)
Crop(0,8,0,-8,true)

One difference between QTGMC, and it's precursor TempGaussMCbeta1 is the border=false in the former . Sometimes, that's not enough, and you need to add borders for it to "lock on" to the frame edges

EDIT - actually it's not completely fixed by that. You might have to crop the edges

[pooksahib]

Thanks for that, poisondeathray. I don't understand why you added 8 top and bottom only to crop them off again - I experimented by deleting both those commands and the preview stayed the same. However, adding 'border=true' to the QTGMC command cured the 'jump' which is great. Thanks again.

Out of interest, what exactly does 'true' achieve as in "Crop(0,8,0,-8,true)"?

[pooksahib]

Out of interest, what exactly does 'true' achieve as in "Crop(0,8,0,-8,true)"?

[jagabo]

Why don't you just read the documentation? It's very clearly spelled out.

[pooksahib]

Well, I did try that, jagabo, but there's nothing there that answers my query:
http://avisynth.nl/index.php/Crop
Unless you're referring to some other documentation...

[poisondeathray]

Well, I did try that, jagabo, but there's nothing there that answers my query:
http://avisynth.nl/index.php/Crop
Unless you're referring to some other documentation...

Look under "align" = true vs. false

The omitted arguments are in order

Crop really means
Crop(clip, left, top, -right, -bottom, align)

Instead of

Crop(clip=clip, left=0, top=8, right=0, bottom=-8, align=true)

It can be simplifed to
Crop(0,8,0,-8,true)

Because "clip" is implied last, it can be omitted

[davexnet]

From the reference page:

bool align = false

Cropping an YUY2/RGB32 image is always mod4 (four bytes). However, when reading x bytes (an int), it is faster when the read is aligned to a modx placement in memory. MMX/SSE likes 8-byte alignment and SSE2 likes 16-byte alignment. If the data is NOT aligned, each read/write operation will be delayed at least 4 cycles. So images are always aligned to mod16 when they are created by AviSynth.

If an image has been cropped, they will sometimes be placed unaligned in memory; align=true will copy the entire frame from the unaligned memory placement to an aligned one.

So if the penalty of the following filter is larger than the penalty of a complete image copy, using align=true will be faster – especially when it is followed by smoothers.

[pooksahib]

Many thanks.