Launched this week
Effects SDK helps developers add production-ready AI video and audio effects to web, desktop, and mobile apps. Add background blur, virtual backgrounds, smart framing, lighting correction, beautification, overlays, avatars, and real-time noise suppression — all running client-side, without sending video or audio to our servers.











Effects SDK
Client-side and on-device is exactly why I'd reach for this over a server-side pipeline — for a privacy-sensitive app it means the video frames never leave the browser. On the plumbing: what's the added bundle weight, and does the segmentation model require WebGPU or is there a WASM/CPU fallback for users on older machines? Trying to gauge how gracefully background blur degrades on a low-end laptop before wiring it into an existing WebRTC stack.
Effects SDK
@hi_i_am_mimo Thanks for the question! The SDK automatically checks whether WebGPU is supported and working correctly. If it is unavailable or any issues are detected, it falls back to WASM SIMD, and then to standard WASM when needed.
Developers also have explicit control over the execution backend, so you can choose the most appropriate option for your target devices and performance requirements.
The tiered fallback with an explicit backend override is exactly what I'd want for shipping to unknown devices. One practical thing for debugging in the field: is there a runtime signal I can read to know which backend actually ran for a given session, so I can correlate dropped frames with the WASM path rather than guessing? And roughly what performance delta do you see between WebGPU and WASM SIMD on a mid-range laptop?
The client-side approach makes the integration story especially interesting because performance becomes part of the product experience, not just an infrastructure detail. Beyond the quality presets and per-effect controls, do you expose any runtime signal that helps an app decide when to reduce effect complexity or disable a feature on weaker devices? That kind of graceful degradation seems important for products with a wide range of hardware.
Effects SDK
@wesc Absolutely—you’re right, this is important.
The SDK exposes a range of runtime metrics, including FPS, segmentation inference time, and frame rendering time. These signals can be used to detect performance degradation and dynamically switch to a lighter preset, reduce effect complexity, or disable an effect when necessary.
We don’t directly manage broader system signals such as thermal state, CPU pressure, or overall device load, since those are usually best handled at the application level, where developers can apply their own product and business logic.
We also had an interesting discussion about this in the forum thread—check it out:
https://www.producthunt.com/p/effects-sdk/what-is-the-hardest-part-of-adding-video-effects-to-your-app
the GPU-for-segmentation / CPU-for-audio split for mobile is a smart way to avoid contention, good answer. one thing I'm curious about on the "nothing leaves the device" claim - for enterprise customers who need to actually prove that to their own compliance/security teams (not just take the marketing copy), do you provide anything concrete like a network traffic audit, an offline-mode flag they can verify themselves, or a SOC2-style attestation? that's usually the sticking point once a claim like that has to survive a security review.
Effects SDK
@galdayan Absolutely. We’ve worked with larger customers that required a full security and compliance review before integrating the SDK.
For the mobile and desktop versions, we support a fully offline mode that customers can verify in their own environment.
For the web version, there is one required control component: the session server. Full offline operation is more complex on the web than in native applications, but we offer an on-premises deployment option where the session server runs entirely within the customer’s infrastructure. No external connection is required, so it can also operate inside an isolated local network without internet access.
The session server does not process any video or audio. It only handles the key exchange required for the Web SDK to decode the models locally as part of the client-side processing flow.
me thinks the effect collection looks useful for many apps? could lightweight quality settings help developers support more devices easily?
Effects SDK
@alheri_murya Absolutely! We provide several quality presets so developers can balance visual quality and performance depending on the user’s device. This makes it easier to support both high-end and lower-powered hardware with the same integration.
qq. can devs adjust the threshold levels for features like background blur intensity or noise suppression aggressiveness via the API? by the way congrats👏 for launching @maxim_troshin
Effects SDK
@priya_kushwaha1 Thank you! 👏 Yes, developers can adjust effect parameters through the API. Background blur intensity is configurable, noise suppression supports different sample rates and suppression strength levels, allowing developers to balance audio quality, performance, and processing aggressiveness.
@maxim_troshin Awesome 🙌 API-level control over these parameters is a huge plus for developers, thanks for confirming
@maxim_troshin Have you had anyone choose a simpler solution instead of this and why?
Effects SDK
@aurther_bella We’re currently seeing two opposite trends.
On one side, some companies are moving away from open-source solutions such as MediaPipe Selfie Segmentation and choosing our SDK to get better quality, a broader set of effects, and ongoing technical support.
On the other side, companies migrating to platforms like the Zoom SDK may stop using a separate effects SDK because Zoom already provides a fairly robust built-in solution.
Our SDK may look complex because of the number of available features, but the actual integration is quite simple. On the web, for example, it usually takes only a few dozen lines of code. We also provide ready-to-use examples and integrations for platforms such as LiveKit, Cloudflare Meet, and the Zoom SDK.