[FFmpeg-devel] [PATCH] lavfi/vf_deshake: fix segfaults #2443
jbvsmo at gmail.com
Mon Apr 15 20:43:16 CEST 2013
> the code can be changed to work on an aligned grid, this does not need
> extra copying, just dont start at rx but rather at FFALIGN(rx, 16) or
> FFALGN(rx+15, 16)
That looks like a big change (error prone) compared with a simple copy.
> besides, extra copying is negligible in speed, with rx/y being 20
> there are 1600 16x16 compares for 1 copy of a 16x16 block
I realized the filter is very slow. I can't use it on real time with big
values of rx and ry.
The author added a SMART_EXHAUSTIVE flag to reduce compares, but it is not a
> also if you care about speed change the 1600 compare search to one of
> the predictive zonal style searches whatever the more modern ones are
> called or even a old one like EPZS, that will give a 100x speedup
> while the copy is < 1% slowdown with the current exhaustive search
People who write SIMD, be that SSE2, MMX, NEON, altivec or other can
> trust that no caller breaks this rule and all callers can trust that
> it will work if they align the first src that way and dont align the
The "deshake" code was already breaking the rule since it was created...
And it already worked on MMX by luck because PSADBW will not complain of
alignment on 64bit operands.
You cant just pick one implementation and change it to work with
> unaligned data and then expect that your one caller can saftely call it
> with unaligned data in both src while the API still says it is 16byte
You're right, it is too drastic. What solution do you think is most
Maybe you could disable the sse2 call just for a while so the filter will
More information about the ffmpeg-devel