- The one support check asks for a desktop again, as #4059 had the
pipeline do: menu and pipeline still agree, so a phone is neither
offered blur nor refused it.
- Lifting it moves to the PR that tells the user where effects run
slowly, so it is their choice to make.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- The menu asked the browser; the pipeline asked the browser and for a
desktop. On a phone whose browser can run them, blur was offered and
then refused: the toggle moved and the video did not change.
- Both now ask one function, and it asks the browser alone. The platform
was the wrong measure: a phone on the fast route held 99% of its frame
rate and was refused, a desktop on the slow one held 73% and was
allowed.
- The in-call device switcher is still withheld on a phone; that is the
device menu's own rule and is unchanged.
- The provider tests run as a phone, and fail with the desktop test back.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- One pipeline, shared by the pre-join preview and the call, attached the
first time an effect is wanted and never detached after; turning blur
off switches it to a disabled mode in place. Main dropped the processor
whenever blur went off, and a pipeline taken off the camera is destroyed
and re-primed, so each time blur came back one unprocessed frame went
out. Built once, the priming frame is spent once.
- Still driven by the existing blur setting: nothing a user sees changes.
- Its logic is BackgroundEffects in src/state/, which the provider only
builds, so the tests drive it without rendering anything.
- Disabled drops the blur radius too. The SDK's disabled mode keeps it,
and with a radius every frame is still segmented and thrown away; with
neither a radius nor a picture, frames pass untouched.
- Switches run one at a time and skip any overtaken, so an earlier,
slower switch can't land after a later choice.
- Builds, rebuilds and teardowns of the pipeline run one at a time
(OneStepPipeline). The preview's and the call's tracks attach and stop
it independently, and the SDK's wrapper holds one track's streams: two
builds at once overwrite each other's, and a stop during a build does
nothing.
- Every camera track starts with the pipeline on: the room's capture
defaults follow it, and a camera turned off before the first effect is
replaced on turning it on, since a stopped track can't take one. One
attached after publishing lets the room through while it is built.
- BlurBackgroundTransformer becomes BackgroundEffectTransformer: it also
sits disabled, and its init applies that state as the SDK's would.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
If the camera track has already ended by the time the blur processor is
applied to it, MediaStreamTrackProcessor cannot be constructed and
setProcessor rejects. Both call sites used `void`, so this surfaced as
Unhandled promise rejection: TypeError: Failed to construct
'MediaStreamTrackProcessor': Input track cannot be ended
(element-call-rageshakes#17225). Skip ended tracks, and catch and log
processor attach/detach failures instead of leaking them.
