Can we speedup separatefields().selectevery(4,0,3).weave() ?

[hanfrunz]

[Didée]

It's not the separate/select/weave that is slow. Those are just copying bits from here to there.

The slow part is the bob, and the slow part is the resize. Those are the ones actually doing calculations.

a)

dgsource("1080i.dgi")

bob(0,0.5)
lanczos4resize(720,576) 

separatefields().selectevery(4,0,3).weave()

34 fps.
Bob() is doing a [y] resize. Lanczos is 4-tap (more taps = more slow) in both dimensions.


b)

dgsource("1080i.dgi")

bob(0,0.5)
bicubicresize(720,576,0,0.5)

separatefields().selectevery(4,0,3).weave()

76 fps.
Bicubic is 3-tap, hence faster than 4-tap.


c)

dgsource("1080i.dgi")

bicubicresize(720,height(),0,0.5)
bob(0,0.5,height=576) 

separatefields().selectevery(4,0,3).weave()

The number of resizing steps minimized.
101 fps.


Example a) with a 5-tap resizer (lanczos, blackman) comes out at 28.5 fps.

[IanB]

@hanfrunz,

To answer your original question, yes you can use DoubleWeave() which tries to optimise the frame memory copying if it can. Weave() always creates a new frame and copies the top field then the bottom field. DoubleWeave() in frame mode checks to see if either input frame IsWriteable() and will then only copy the alternate field from the other frame, saving 1 field memory copy. If neither are writeable then it does the same as Weave().

As you can see it does not make much difference to the whole script, which Didée points out is because most processing is taking place in other filters. Here we can save 0.5ms per frame, which as expected, is about the cost of a SD field bit on a modest machine. The semantics of using DoubleWeave() are a little tricky so most people tend to overlook using it.

ColorBars(1920, 1080, "yv12")

bicubicresize(720,height(),0,0.5)
bob(0,0.5,height=576) 

# separatefields().selectevery(4,0,3).weave() # 104 fps, 9.6ms
ComplementParity().DoubleWeave().selectevery(4,1) # 110 fps, 9.1 ms