Deblock_QED_MT2 and re-size interlaced clip

[halsboss]

Seeking to convert a fast action sports PAL HDTV 1920x1080i capture which is blocky, into a PAL DVD compatible 576i with additional deblocking.

From other threads, http://forum.doom9.org/showthread.php?p=1115201#post1115201 indicates how to resize interlaced

# PAL HD 1920x1080i => 576i
MPEG2Source("G:\HDTV\ZZZZ.d2v",cpu=6)
AssumeFPS(25)
AssumeTFF()
LastW=LAST.width()
LastH=LAST.height()
bicubicresize(720,LastH)
tdeint(mode=1,order=1) # mode=0=same rate output mode=1=double rate output (bobbing) order=0=BFF order=1=TFF
bicubicresize(720,576)
separatefields()
selectevery(4,0,3)
weave()
Converttoyv12(interlaced=true)
SetPlanarLegacyAlignment(True)


and in http://forum.doom9.org/showthread.php?p=934083#post934083 Didee shows how to correctly deblock interlaced sources
The only correct way for interlaced sources is: (alas)
i=LAST
SeparateFields().PointResize(i.width,i.height)
Deblock_qed().AssumeFrameBased()
AssumeFrameBased().Deblock_qed()
GetParity(i) ? AssumeTFF() : AssumeBFF()
SeparateFields().SelectEvery(4,0,3).Weave()

Now, how do I combine these concepts so it operates efficiently ? Like this below, or does the horizontal resize and Tdeint muck it up ? I'm hoping that the deblock code above doesn't have to be done in addition to the resize code above :)

# PAL HD 1920x1080i => 576i
MPEG2Source("G:\HDTV\ZZZZ.d2v",cpu=6)
AssumeFPS(25)
AssumeTFF()
LastW=LAST.width()
LastH=LAST.height()
bicubicresize(720,LastH)
tdeint(mode=1,order=1) # mode=0=same rate output mode=1=double rate output (bobbing) order=0=BFF order=1=TFF
bicubicresize(720,576)
Deblock_QED_MT2() #default quant1=20
separatefields()
selectevery(4,0,3)
weave()
Converttoyv12(interlaced=true)
SetPlanarLegacyAlignment(True)

[scharfis_brain]

you cannot use deblocking after resize.
you have to place it after loading the video.

[halsboss]

Oh. Thanks. Like this then (the processing time goes up due to the extra resize etc, but that's life I guess).


# PAL HD 1920x1080i => 576i
MPEG2Source("G:\HDTV\ZZZZ.d2v",cpu=6) # from DGindex
AssumeFPS(25)
AssumeTFF()
LastW=LAST.width()
LastH=LAST.height()
# Deblock before resize or it doesn't deblock
i=LAST
SeparateFields().PointResize(LastW,LastH)
#Deblock_QED_MT2.AssumeFrameBased()
AssumeFrameBased().Deblock_qed()
GetParity(i) ? AssumeTFF() : AssumeBFF()
SeparateFields().SelectEvery(4,0,3).Weave()
# now resize
bicubicresize(720,LastH)
tdeint(mode=1,order=1) # mode=0=same rate output mode=1=double rate output (bobbing) order=0=BFF order=1=TFF
bicubicresize(720,576)
separatefields()
selectevery(4,0,3)
weave()
Converttoyv12(interlaced=true)
SetPlanarLegacyAlignment(True)


I was hoping there was a less processing-intensive "trick" :) Oh well.

[scharfis_brain]

Oh. Thanks. Like this then
Yeah.
(the processing time goes up due to the extra resize etc, but that's life I guess).
Nope. Due to Deblocking. Pointresize doesn't eat up much processing time.

[halsboss]

Nope. Due to Deblocking. Pointresize doesn't eat up much processing time.

Great ! :thanks: Righto, the extra processing is mostly due to the deblocking filter itself which can't be avoided anyway. I can't hope for too many fps given the clip dimensions it has to work on :)

[halsboss]

With DGDecode I'm already using cpu=6, however I just spotted in the DGDecode manual that there's a function called Deblock()

Deblock(clip, int "quant", int "aOffset", int "bOffset", bool "mmx", bool "isse")
Manao's H.264 Deblocking Filter. (v0.9.5)


It doesn't say whether it processes interlaced correctly so I could call it just after the MPEG2Source ...

Can anyone comment on their preference of DGDecode's Deblock() vs Deblock_QED_MT2() or give me a hint on what to search for re such a discussion ?

[scharfis_brain]

deblock_QED is based on DeBlock() and improves it further!

[Didée]

The Deblock() function has no interlaced mode, it's only for progressive material. Since Deblock_QED basically is just a modded version of Deblock(), that's the reason for the effort with point-bob + re-interlace.

Then, generally I wouldn't use Deblock_QED together with DGDecode's internal postprocessing. My first try is to use only Deblock_QED, and see if it's sufficient to remove the blocking. Only if the blocking is so strong that Deblock_QED can't be set up to sufficiently deal with it, then QED is sent to vacation, and either plain Deblock() or DGDecode's internal PP gets the job.

The problem with chaining different deblockers is that the first deblocker will process some places "not enough", but still so much that the 2nd deblocker won't reckognize the blocking anymore.

Note that those experiences are mostly during processing SD material. It could very well be that for 1080 HD, DGDecode's internal PP is fully sufficient. Remember that you adjust it's "sensitivity" via the "moderate_h" and "moderate_v" parameters.

[halsboss]

OK. Thankyou. To summarize the deblocking approach, then:

1. use Deblock_QED_MT2() as it's improved over deblock(), but not together with MPEG2Source's cpu=6
2. try MPEG2Source's cpu=6 which is DGDecode's internal PP if Deblock_QED_MT2() doesn't quite do it, but not together with Deblock_QED_MT2

Cheerio

[halsboss]

Oh dear, for 1920x1080i using Deblock_QED_MT2 I get the error message

Sorry, DctFilter test version needs size multiples of 16x16

Is there a version of dctfilter which doesn't have this limitation, or should I add 8 to the clip bottom and crop it after Deblock_QED_MT2 ?

[scharfis_brain]

just try things out...

[halsboss]

ok. added 8 to the bottom and remove it afterward. achieves about 1.5 fps. Works OK.

[aand]

Sorry, DctFilter test version needs size multiples of 16x16
I get the same error! I've tried using deblock_qed() but it says "crop:you cannot use crop to enlage or "shift" a clip".
I don't know what to do next :(
This is my script:
source=DGDecode_mpeg2source("G:\videoclip.d2v")
d2v="G:\videoclip.d2v"

b=source.checkmate()
a=b.nnedi()
c=b.tfm(order=1,slow=2,mode=5,d2v=d2v,mi=40,pp=6,chroma=false,cthresh=8,clip2=a).tdecimate(hybrid=1)
c.crop( 14, 154, -18, -150).deblock_qed()

Any ideas?

[scharfis_brain]

the video you feed into deblock_qeg needs to be mod16 or mod32 (dunno anymore).

[foxyshadis]

If it's larger than 720x576 or so, the original Deblock QED won't work with it. You have to use the variation found in the wiki (http://avisynth.org/mediawiki/Deblock_QED). If it's much larger than 1920x1080, you need to modify it again, adding another stackhorizontal/stackvertical; but I can't imagine having an mpeg2 that large.

[aand]

Thanks for the help! I have 1920p.
This is crazy! It worked once (I think) but then the error appeared again. I copy/pasted 2 random lines (I don't understand what they do...).
So which of these I have to duplicate?!
block = blankclip(clp,width=6*4,height=6*4,color=$000000).addborders(4,4,4,4,color=$FFFFFF)
block = stackhorizontal( block,block,block,block)
block = stackvertical( block,block,block,block) .pointresize(32,32) .mt_binarize(upper=false)
block = stackhorizontal( block,block,block,block,block,block,block,block)
block = stackvertical( block,block,block,block,block,block)
block = stackhorizontal( block,block,block)
block = stackvertical( block,block,block)
block = stackhorizontal( block,block,block)
block = stackvertical( block,block)


LE: I'm using the MT2 version, the original QED doesn't exist on wiki.

[Didée]

Yeah, Deblock_QED was made some time before MaskTools had reached alpha35.

block = blankclip(clp,width=6*4,height=6*4,color=$000000).addborders(4,4,4,4,color=$FFFFFF)
block = stackhorizontal( block,block,block,block)
block = stackvertical( block,block,block,block) .pointresize(32,32) .binarize(upper=false)
block = stackhorizontal( block,block,block,block,block,block,block,block)
block = stackvertical( block,block,block,block,block,block)
block = stackhorizontal( block,block,block)
block = stackvertical( block,block,block)
block = stackhorizontal( block,block,block)
block = stackvertical( block,block,block)
block = block .crop(0,0,ox,oy)
block = (uv!=3) ? block
\ : YtoUV(block.crop(0,0,ox/2,oy/2),block.crop(0,0,ox/2,oy/2),block)
block = block.trim(1,1) .loop(framecount(clp))
# ...[*getting dizzy*]...
That hurts.


block = clp.mt_LutSpa(false,"x 1 + 8 % 1 < x 8 % 1 < y 1 + 8 % 1 < y 8 % 1 < | | | 255 0 ?",U=3,V=3)
Much nicer. And never too small. ;)

[aand]

:) much nicer but... it still doesn't work with my 1920x1080 TS. It worked ok with a processed, sized-down to 1200p version of it.
I've even tryed 32x32 resolution (yeah I'm desperate :P) and it didn't work.

Funky error:
http://img240.imageshack.us/img240/1990/24629575ap4.png (http://imageshack.us)

[Didée]

:) much nicer but... it still doesn't work with my 1920x1080 TS.

c.crop( 14, 154, -18, -150).deblock_qed()

Your source is 1920x1080. You're cropping 154 from top & 150 from bottom. 1080 minus 154 minus 150 equals 776. Now, 776 is not "mod16", since 776 / 16 = 48.5 ...

Apart from that, the horizontal cropping (14 from left) is also WRONG to do before running a deblocker: you are shifting the block borders to a location where the deblocker does not search for them, making it more or less impossible for the deblocker to do its job correctly ...


Try this:

c.crop( 0, 144, -16, -136) # crop as much as possible while keeping mod16
deblock_qed() # deblock
crop( 14, 10, -2, -14) # crop the remaining bits

[aand]

It works!
LOL what a dumb mistake :D I was thinking 1920 --> a 'standard' resolution --> must be mod16 :))))
Silly me!

Yes, I knew cropping is bad before deblocking, but the script was just for testing purpose(to see it there will be an error).

Do you mind if I put your shorter variant of deblock_qed() on the wiki?

[Didée]

I just updated Deblock_QED_MT2 on the wiki.

[Avenger007]

The only correct way for interlaced sources is: (alas)

SeparateFields() .PointResize(width,height)
Deblock_qed() .AssumeFrameBased()
SeparateFields() .SelectEvery(4,0,3) .Weave()
Should it be
SeparateFields().PointResize(width,height)
Deblock_qed().AssumeFrameBased()
SeparateFields().SelectOdd().Weave()

The fields line-up perfectly for my source when doing it this way. :)

[Didée]

Nope.

My code was wrong (or: incautious). In fact it works only for BFF interlaced sources, it fails for TFF.

Your code is wrong, too. It works only for TFF interlaced sources, it fails for BFF.


That post was made in a rush (I remember), and forgot about the fact that AssumeFrameBased() resets clip parity to BFF always, no matter the input.

The correct way is (of course)

i = last
i.SeparateFields() .PointResize(i.width,i.height)
AssumeFrameBased() .Deblock_qed()
GetParity(i) ? AssumeTFF() : AssumeBFF()
SeparateFields() .SelectEvery(4,0,3) .Weave()

[Avenger007]

All correct. :thanks:

[Gavino]

My code was wrong (or: incautious). In fact it works only for BFF interlaced sources, it fails for TFF.

Your code is wrong, too. It works only for TFF interlaced sources, it fails for BFF.
I think Avenger007's code works for BFF and fails for TFF just as yours did - because of the PointResize, aren't the two versions equivalent? I think in this context SelectOdd() and SelectEvery(4,0,3) happen to have the same result.

[Avenger007]

No, my source is TFF.
In this case, SelectOdd() is equivalent to SelectEvery(4,1,3) (i.e. select frames 1 and 3 within every 4 frames, ).

[Gavino]

I may be wrong, but my point was that because of the PointResize, you have pairs of identical lines. So my thinking was that after the second SeparateFields, in each group of 4, frames 0 and 1 would be identical, as would frames 2 and 3.

[Didée]

I may be wrong, but my point was that because of the PointResize, you have pairs of identical lines. So my thinking was that after the second SeparateFields, in each group of 4, frames 0 and 1 would be identical, as would frames 2 and 3.
Correct at the entrance, but not at the exit.

Look at a block sniplet after pointresizing one field:

...
...
A4t
A4b
B1t
B1b
B2t
B2b
B3t
B3b
B4t
B4b
C1t
C1b
...
...
That's the "input" block, and surely, all "XXt" and "XXb" pixel pairs are identical.
The clue is that we're not only juggling fields around forth and then back again - funnily, we're doing some processing inbetween. :)

This block now gets processed by the deblocker. After that, we're SelectX()'ing-out the fields again. Now look at the pattern: at the top of block B, we want to get pixel B1t, because that pixel was processed with a pixel from block A as neighbor. We don't want pixel B1b, because this pixel was not in block A's direct neighborhood during processing.
At the bottom of block B it's the other way round: we want pixel B4b, since it was in C's neighborhood. We don't want B4t, because it wasn't.

Summary: we want B1t and B4b.

With SelectEven or SelectOdd, you get either B1t and B4t, or B1b and B4b. One is always wrong.


After deblocking, the formerly identical pairs can not be considered identical anymore, easy as that. Generally this would affect any deblocking filter when using SeperateFields.Pointresize as input, though it probably wouldn't be a major issue with most ones.

But for Deblock_QED in particular, it is extremely important to choose the 'correct' t/b lines, because of it's "borderline-vs-interiour of a block" distinction.
In effect, SelectEven/Odd() would lose almost half of the vertical deblocking work completely, because it would output "borderline" pixels that have been processed while they've been "interiour" pixels.

[Gavino]

Didée - Thanks for your (as usual) clear and informative explanation.
With SelectEven or SelectOdd, you get either B1t and B4t, or B1b and B4b. One is always wrong.
Indeed. What had me confused was that Avenger007 said SelectOdd worked for him, and you appeared to agree that it worked (though only for TFF).

[Didée]

Both of the "wrong" versions would produce field-swapped output when fed with the non-fitting fieldorder. Field-swapped output is utterly wrong, and very obvious.
Agreeing that it "worked" for TFF was in respect to not produce faulty things like swapped fields (note that in #22, the issue reported to be "solved" was field alignment), not in respect to full deblocking efficiency.
(Didn't adress that in #23, since my hope was that just posting the always-correct version would let me get away without having to dive into all the bothersome little details.) :p

[Gser]

I suppose this should be used to also deblock progressive content that is encoded as interlaced?

[poisondeathray]

I suppose this should be used to also deblock progressive content that is encoded as interlaced?

You can treat progressive content as progressive (as long as the decoder treats it as progressive)