A video effects SDK for Web and mobile puts the same effects engine behind your browser app and your native apps: face beautification, 2D and 3D stickers, colour filters, background segmentation, and gesture interaction, all rendered in real time on live camera frames. Users get the same effects whether they opened your product on a phone or in a browser tab.
1. Product Positioning
Meishe provides a video effects SDK built on the cross-platform audio/video processing engine used across the product family. Effects render with real-time rendering without pre-processing, and the same SDK covers iOS, Android, and Web, with Desktop (Windows), smart hardware, React Native, and Flutter supported through the short-video solution. It is the effects layer inside your own app: your interface, permissions, and upload flow stay yours, and the SDK handles detection, rendering, and effect delivery.
2. What runs on both platforms
Every capability below works on mobile and in the browser from the same effect packages:
| Capability | What it does in your app |
|---|---|
| Face beautification | Skin smoothing, face reshaping, and makeup applied live on the camera preview — on a phone screen or in a browser tab |
| 2D and 3D stickers | Stickers anchored to detected facial features; 3D props follow head turns on both platforms |
| Filters | Colour-grading filters with adjustable intensity, identical on Web and mobile output |
| Portrait and background segmentation | Real-time subject separation so users can replace backgrounds without a green screen |
| Gesture detection | A raised hand or a wave triggers effects and actions on either platform |
The modules share one detection result per frame. A user wearing beautification, a sticker, and a filter generates one face analysis, not three — which keeps the browser tab and the phone equally responsive as the effect list grows.
3. One effect library, both runtimes
The practical benefit of a Web-and-mobile SDK is a single content pipeline:
- Author once. An effect package produced in the Asset Creation Platform works on iOS, Android, and Web — there is no browser-specific rebuild.
- Test per platform, not per effect. Your QA team verifies each effect on each platform once; new campaigns reuse verified building blocks.
- Update without releases. Packages are data. A holiday sticker set ships as a content update on every platform at once — no app store review, no web redeploy.
The snippet below is schematic. Names and signatures are illustrative, not the shipped API.
// Illustrative: the same package identifiers on Web and mobile.
import { createEffectsRuntime } from "@meishe/ar-effects"; // placeholder name
const rt = await createEffectsRuntime({ platform: "web" });
await rt.looks.apply("look.natural.01"); // same id as on iOS/Android
await rt.props.attach("prop.glasses.round.3d"); // 3D sticker, face-anchored
await rt.filters.apply("filter.warm.film", { intensity: 0.6 });4. How the Web build holds up
Browsers add their own rules — camera access needs a secure origin, and rendering goes through the platform’s graphics stack. The SDK’s Web path is built for that environment: per-frame work stays inside the rendering pipeline, and effect packages load as data over your own delivery channel, so a browser session picks up new campaigns exactly like the mobile app does.
For product teams this means the Web experience is a peer of the app, not a trimmed-down version. The camera page on the web app offers the same looks, stickers, and filters, and the results match what mobile users record.
That parity extends to the workflows around the camera. A user who starts a recording in the browser and finishes on the phone works with the same effect library and the same package identifiers; a campaign that launches on Monday is live on every surface on Monday. Teams that maintain a web demo alongside the store app use the demo to preview exactly what ships — same engine, same content — instead of maintaining a parallel effects build for marketing.
5. Where a Web-and-mobile SDK pays off fastest
Three product patterns benefit most from the shared-runtime arrangement:
| Product pattern | What the shared SDK changes |
|---|---|
| Social or commerce app plus web companion | The web app offers the same camera effects as the store app, so the web experience drives installs instead of feeling like a brochure |
| Enterprise and internal tools with browser access policies | Full effects inside the browser, with packages delivered through the company’s own infrastructure |
| Products with user-generated templates | Creators author once in the Asset Creation Platform; consumers open the result on any device, in the app or on the web |
In each case the deciding factor is the same: the effect library is the product’s living content, and a single library across Web and mobile means that content never forks by platform.
6. Why teams choose Meishe
| Advantage | What it means for your project |
|---|---|
| Self-developed engine | Effects run on Meishe’s own cross-platform audio/video processing engine — years of in-house engine development and a deep video patent portfolio behind it |
| Real-time, no pre-processing | Effects appear the moment the camera opens, in the app and in the browser |
| Small footprint | The SDK core stays small on mobile; optional modules load on demand |
| One content pipeline | The Asset Creation Platform and Special Effects Customization services supply effects for every platform from one workflow |
| Cross-platform coverage | iOS, Android, Web, Desktop (Windows), smart hardware, plus React Native and Flutter through the short-video solution |
7. What shipping teams ask first
- Does the browser build need anything special from our side? A secure origin for camera access and your usual static hosting for effect packages — the rest matches the mobile integration.
- What happens on low-end phones? Detection cadence adapts within the same package, so one library serves the whole device matrix.
- Who maintains effects after launch? Your design team works in the Asset Creation Platform; Special Effects Customization is available when you need produced collections rather than in-house authoring.
- How do the two targets share QA effort? Effects verify once per platform; because packages and engine are shared, most regressions trace to platform behaviour rather than to content.
Planning the first month with a Web-and-mobile SDK follows a familiar shape. The first two weeks link the engine and stand up the camera preview with stock packages on both targets. Week three brings your own authored look and sticker set through the Asset Creation Platform, verified once per platform. By week four, segmentation or gestures come online and the streaming path is checked, still from the same package library.
From that point the operating rhythm changes character: campaigns publish as data through your channel, the browser and the apps pick them up together, and the next feature — a holiday sticker set, a new filter family — is a content decision rather than an engineering release.
FAQ
Is the Web version a cut-down build?
No. Web runs the same effect packages on the same engine as iOS and Android — the camera page in a browser offers the same looks, stickers, and filters.
Do browser users get new campaigns at the same time as app users?
Yes. Effect packages are data delivered through your own channel; a campaign publish reaches every platform at once.
How do permissions work on each platform?
Camera permission prompts belong to your app on mobile and to the browser on Web. The SDK renders once frames arrive; the permission flow stays in your interface.
Can we start with Web only and add mobile later?
Yes. The SDK is modular per platform — teams commonly prove the feature set on one target, then enable the same packages on the next.