Identify the client before searching for a flag
A phone can run Jitsi in a browser, the stock native app or another application’s embedded SDK. Do not assume a web feature is available in each of those environments. The October 2026 SDK request asks for virtual backgrounds and blur on native platforms; the maintainer said a native implementation is needed and supplied no estimate. [S1]
| Client | What this review establishes | What you must verify |
|---|---|---|
| Desktop web | A web implementation and configuration gate exist in the pinned source. [S2] | Your actual browser, device, deployed configuration and effect result |
| Mobile browser | It is a browser context, not proof of the native SDK’s features | Exact browser/device capability and the meeting’s controls |
| Stock native app | Its shipped client determines available camera effects | Exact app version and its current supported features |
| Custom Android/iOS SDK app | The upstream request describes a native implementation gap. [S1] | Exact SDK, any host-app custom effects and released documentation |
This is an evidence and diagnostic table, not a device-tested compatibility matrix.
Check ordinary camera video first
Recommended sequence:
- Join a disposable meeting with the intended client and confirm ordinary camera video without effects.
- If that fails, follow camera diagnostics first.
- If video works, identify whether the background control is missing, disabled, or fails only after selecting an effect.
- Compare the same client/build with the operator’s supported configuration. Avoid changing the server and the device at the same time.
A missing menu and an effect-processing failure are different symptoms; neither is established as a bridge-port problem by this source review.
For desktop-web operators
The reviewed 11248 helper treats config.virtualBackground.disabled === true as disabled. Preserve the organization’s intended policy and check the merged configuration actually delivered to the browser, rather than only a host-side file. This gate does not establish every other capability required by an effect. [S2]
For Docker, follow the normal custom-config workflow; package operators should inspect their installed web configuration. Use custom configuration diagnostics if changes do not appear. A tutorial for a different release is not proof of your client’s controls.
Once the control is available, test the resulting video with another participant. Verify the effect remains applied when the camera is toggled and after an ordinary rejoin. These are recommended acceptance checks, not completed tests from this review.
For mobile SDK developers
Read the current SDK’s feature documentation and the maintainer discussion before promising browser-equivalent effects. Adding a web config option to a native integration does not implement the native camera-processing feature discussed in issue #17967. The reviewed discussion supplies no delivery schedule. [S1]
If your host app supplies a custom effect, document that implementation and test it with the exact SDK/device combination. Do not describe a host-app customization as a feature available in every stock Jitsi client.
For immediate meetings, use a client whose supported features meet your needs, or continue with ordinary camera video and an appropriate physical background. Those are alternatives, not a repair of the missing implementation.
Open questions and maintenance
Reviewed 24 October 2026 against Jitsi Meet 11248 source f765042 and the then-open native SDK request. We did not run background processing on a browser, phone, native app or SDK. No performance, device or image-quality guarantee is established. Recheck the exact release and issue status before changing the capability table or promising native availability. [S1][S2]
Sources
- [S1] Native SDK background request #17967, opened 13 October 2026; maintainer implementation explanation and lack of an estimate, checked 24 October.
- [S2] Pinned 11248 web effect configuration helper and configuration reference.