[FFmpeg-devel] [PATCH] yadif: restore speed of the C filtering code
james.darnley at gmail.com
Fri Mar 1 20:46:19 CET 2013
On 2013-03-01 18:31, Paul B Mahol wrote:
> On 3/1/13, James Darnley <james.darnley at gmail.com> wrote:
>> Always use the special filter for the first and last 3 columns (only).
>> The changes made in 64ed397 slowed the filter to just under 3/4 of what
>> it was. This commit restores almost all of that speed while maintaining
>> identical output.
>> For reference, on my Athlon64:
>> 1733222 decicycles in old
>> 2358563 decicycles in new
>> 1740014 decicycles in this
>> libavfilter/vf_yadif.c | 93
>> libavfilter/x86/vf_yadif_init.c | 12 +----
>> libavfilter/yadif.h | 4 +-
>> 3 files changed, 60 insertions(+), 49 deletions(-)
> That commit claimed it fixed overreads.
> Have you checked that no overreads happens with this patch?
Not with anything other than my brain. I haven't changed the effective
behaviour of the left which reads as far as -3. That commit filters up
to the right edge minus 3. I haven't changed that so the assembly can
still read up to 4 bytes beyond the right edge.
Your comment from my email mishap:
> Note that my wish is that code is faster and with no overreads -
> reading uninitialized/unallocated bytes.
I can change it so that the right edge gets special treatment but with
this commit (and the previous) there are no effects on the frame from
reading uninitialised bytes. Over-read pixels on the right edge would
either be written off the right edge or written over by the edge filter.
I think the only place where it may read into possibly unallocated
memory is on the right edge of the last line.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 553 bytes
Desc: OpenPGP digital signature
More information about the ffmpeg-devel