[FFmpeg-devel] [PATCH] avfilter: add radial and circular blur video filter

[Paul B Mahol]

On 7/18/20, Steinar H. Gunderson <steinar+ffmpeg at gunderson.no> wrote:
> On Sat, Jul 18, 2020 at 04:59:21PM +0200, Paul B Mahol wrote:
>>> Is it good that it's slow? Or do you mean that the algorithm isn't
>>> actually
>>> slow?
>> It is pretty fast here.
>
> Could you quantify what you mean by “pretty fast”? (Is it fast also measured
> in CPU time, or only if you have a bunch of cores to spread it out over?)

It is faster than many other filters, and could be made even faster.
But considering that I do all this for free, why I should listen to someone who
spends 5 seconds to write review.

>
>>> It sure is. With -vf vblur, a simple single-threaded transcode (to
>>> magicyuv)
>>> drops from 64 to 5 fps. A quick perf run indicates that about 67% of the
>>> CPU
>>> time is spent in converting to and from polar coordinates (p2c, c2p,
>>> atan2),
>>> give or take a little.
>> It can be made faster, but why i would do that when you complain on
>> current code?
>
> I agree that optimizing the current algorithm is not a good way to go
> when there are multiple better ones available, but you were claiming
> performance was not affected at all, which fairly obviously is not true.

Why you still spreading nonsense that there is better algorithm?

>
>> Actually, fact is that you came here at first to bring some jumbo
>> about better algorithms
>> with pages that had almost no valuable information.
>> And later when proven wrong you started to object to current patch
>> just for pure amusement.
>
> Can we please talk about the patch instead of personal attacks?
>
> Also, what do you mean by “proven wrong”? Your only “proof” so far that your
> algorithm is better than the standard vector-based variations (whether
> recursive, or simply by integrating along a line with bilinear filtering,
> neither of which needs any trigonometry or divisions) has been an expression
> of doubt -- no benchmarks, no reasoning, no back-of-the-envelope
> calculations.

There is no better algorithm than current one.
If you want to prove different, write one!
But if you do not want, then better current solution than no solution at all.
It could have even same options like current implementation than just
code would be changed.

>
>>> It's good that you fixed the quality issue you claimed didn't exist less
>>> than an hour earlier. Could you please post the updated patch?
>> I will keep it to my fork only. You can enjoy your negative reviews
>> later at any time.
>
> OK, if you don't plan to actually commit this to FFmpeg master, then we
> don't
> need to argue further about it.

I changed my mind when I looked how many benefits it give.

>
> /* Steinar */
> --
> Homepage: https://www.sesse.net/
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".