[FFmpeg-devel] [PATCH 2/3] delogo: Use weighted interpolation

[Jean Delvare]

Following up on this...

On Mon, 24 Jun 2013 11:26:57 +0200, Jean Delvare wrote:
> On Sun, 23 Jun 2013 12:06:33 +0200, Stefano Sabatini wrote:
> > How much slower (-benchmark or use libavutil/time.h macros to test the
> > processing loop)?
> 
> I used -benchmark to measure the difference but couldn't really, it has
> the same order of magnitude than the measurement noise. I collected
> numbers over multiple runs to cancel the noise as much as possible, and
> to my surprise the results suggest the new algorithm is slightly faster
> (by 8%, nothing spectacular).
> 
> Originally I suspected my algorithm would be slower because it does a
> lot more multiplications and uses uint64_t, but looking a bit closer,
> the inner loop now has only 1 division instead of 5, and divisions are
> much more expensive than all other operations. This could explain the
> performance gain.

OK, I came up with a benchmark command where I actually benchmark the
delogo code rather than surrounding noise. Originally I was measuring a
real-world case, while I am now measuring the first pass of a two-pass
encoding, with no sound and no other filters, and with a very large
logo area. In these conditions, the delogo filter represents about 40%
of the overall CPU time so I could reliably measure performance gain or
loss of each of my patches.

The result is that this patch makes the filter about 10% slower. I
wouldn't be worried though, for 2 reasons:

1* The filter is still very fast. In a typical video encoding workflow,
it accounts for 1% or less of the total CPU time. So relative to the
total CPU time we're talking about 0.1%, tops. Nothing to worry about
(and this is why I was originally unable to reliably measure the
change.)

Plus...

> BTW, if performance is an issue, I noticed that the original code is
> not optimized at all and I have several ideas how it could be made
> faster. I planned to work on that next.

2* I have two code optimization patches ready, which improve
performance by 2% and 20%, respectively. This more than covers for the
loss incurred by the improved algorithm.

> > What if you add a flag for setting the enhanced quality?
> 
> Given the results above, I'd rather avoid it, it would add complexity
> for no good reason.

Thus I stand on my previous position here, there's no reason to add a
flag to select the old algorithm, it's simply not worth it.

Thanks,
-- 
Jean Delvare