[FFmpeg-devel] [PATCH] yadif: restore speed of the C filtering code

James Darnley 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...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130301/5c3df12f/attachment.asc>


More information about the ffmpeg-devel mailing list