There are much faster algorithms available for Gaussian blur though, running in O(n) rather than O(nσ) for an n pixel image and radius σ. See https://www.ipol.im/pub/art/2013/87/article.pdf for a survey.
What surprises me is that the original VLC filter does not use SIMD. Sometimes I wonder why I spent my money on a "modern" CPU with a lot of new features that stay completely ignored by most software I run every day.
Probably a reflection of the age of that code along with the usefulness of the feature. If no one actually needs the video blurry, then it doesn't matter how efficient the filter is.
I would have expected the filters to run as a shader on the GPU which would make them much more efficient.
I remember implementing two-pass gaussian blur in GLSL almost 20 years ago.
Very interesting readup! I have some C# projects I've had in mind to try to compile to AOT. Quite different for complex programs of course, but the perf being very close to C is a great motivator.
Why would you want them in AOT, though? It's great for startup time and native interoperability, but it might be slower in general due to machine specific optimizations.
And 8% milk would taste bad and ruin most recipes.
I don't know why we're comparing completely different categories of number though. In a business context getting a project done a few percent faster, or more accurately one step done a few percent faster, barely affects revenue at all. And saving CPU time matters even less.
There are much faster algorithms available for Gaussian blur though, running in O(n) rather than O(nσ) for an n pixel image and radius σ. See https://www.ipol.im/pub/art/2013/87/article.pdf for a survey.
Nice article!
What surprises me is that the original VLC filter does not use SIMD. Sometimes I wonder why I spent my money on a "modern" CPU with a lot of new features that stay completely ignored by most software I run every day.
It surprises me that it runs on the CPU at all, honestly.
Probably a reflection of the age of that code along with the usefulness of the feature. If no one actually needs the video blurry, then it doesn't matter how efficient the filter is.
I would have expected the filters to run as a shader on the GPU which would make them much more efficient. I remember implementing two-pass gaussian blur in GLSL almost 20 years ago.
Yep if you want it done quickly, the GPU is the way to go. Especially once you get to 4K resolution and beyond.
See here:
https://aras-p.info/blog/2026/10/01/Fast-blur-with-animated-...
Very interesting readup! I have some C# projects I've had in mind to try to compile to AOT. Quite different for complex programs of course, but the perf being very close to C is a great motivator.
Why would you want them in AOT, though? It's great for startup time and native interoperability, but it might be slower in general due to machine specific optimizations.
Because of Docker. You want the images to be as small as possible.
Most industries consider 8% a mountain. More than their entire profit margin.
And 8% milk would taste bad and ruin most recipes.
I don't know why we're comparing completely different categories of number though. In a business context getting a project done a few percent faster, or more accurately one step done a few percent faster, barely affects revenue at all. And saving CPU time matters even less.