Faster Crop()?

[n0an]

Hello,

I want to know if there's any faster way to crop down the black bars. Crop() brings down the FPS considerable.

FFT3DFilter is a really slow filter and that gives me 15 FPS or so, but Crop() reduced my FPS considerably. Any alternatives?

Thanks,

n0an

[G_M_C]

Whats the source's format, how are you opening it, what are you trying to achieve ? What is the machine you're using ? In short: Tell more, cause Crop () is fast enough.

[Adub]

I doubt that crop() is your problem. It's about as fast as a filter can get. I use it all the time, and there is practically no processor penalty.

[IanB]

As Adub points out Crop() is about as fast as a filter can gets. However because it does it's magic with simple pointer arithmetic it can result in the output video data being unaligned in memory. Some filters perform very badly with unaligned data.

There is an Align=True option to Crop() that causes the output to be copied into a new aligned frame, this means Crop now has the cost of an unaligned to aligned memory copy, but the subsequent filters are again working with aligned data. Depending on how degraded the unaligned performance of the other filter is you may see a positive net result.

Depending on the alignment requirements of the filters it may be better to coarse Crop() the left side to mod 8, 16 or 32 on input and then do a fine Crop latter in the script where the filters are not so sensitive to memory alignment.

I.e. total crop required Crop(20, 6, -20, 6), do this as...
Crop(16, 6, -16, 6) # mod 16 alignement
FFT3DFilter(....)
Crop(4, 0, -4, 0)
...

[n0an]

I am running Vista Home Premium SP2 on a 1.6 Ghz Pentium Dual Core, 2.5GB Ram. It's a HP DV2124TU Laptop :p.

The source is a DVD9.

I also doubt now that Crop() is the problem. Will try to do another encode and post back.

@IanB

So if I have crop() values of "6, 50, -6, 56" so I should just use mod16 values for 50 and 56 and then do another crop after my filters with the remainder?

[IanB]

@n0an,

No, only left edge cropping has the potential to causes unaligned data in memory (conscientious filters check alignment and act appropriately).

The right edge cropping has the potential to cause non integral number of chunks (SSE could process upto 16 pixels per chunk).

Top and bottom cropping involve complete whole lines so there is never a problem.