Most introductions to the Meishe AR Face Filters SDK start with what it can put on a face. That is the interesting part on day one and almost irrelevant by month nine, when the question is whether a library of two hundred looks can still be edited by anyone who did not build it.
The Meishe AR Face Filters SDK is built around that second question. It is the filter and effects layer of the Face AR SDK family, evaluated on the cross-platform audio/video processing engine used across the product family, and structured so that the library itself — not merely the rendering — is maintainable.
Meishe brings over 20 years of development experience in the field of video and audio, holds more than 70 video-related patents, and has won many national awards. What follows is a plain account of what ships, what it connects to, and who should not buy it.
1. Product Positioning
Meishe Face Filters SDK is a module for applications that need real-time facial effects, evaluated without pre-processing on the same core that powers capture, timeline editing, and live streaming. Individual elements and complete looks, with per-element intensity control, ship as authored packages rather than compiled behaviour.
Supported targets are iOS, Android, Web, Desktop (Windows), smart hardware, React Native, and Flutter (supported through the short-video solution, for cross-framework teams).
It is a module, not an application. There is no editor UI, no preset store, and no shade library in the box.
2. Two layers: element and look
Everything else follows from this two-layer structure, so it is worth stating precisely.
An element is a single component — one lip product, one eye treatment. It is the smallest unit that can be authored and the smallest unit that can be applied.
A look is a combination of elements. It is not a flattened image; it is a structure that references elements. Both layers are first-class, and one element can appear in many looks.
The consequences are operational rather than technical:
- Editing one element updates every look that references it, with no per-look re-export.
- Adding or removing an element inside one look leaves every other look untouched.
- Retiring an element becomes a review rather than a rebuild, because dependency is expressed as a reference.
Teams that adopt a flattened look format — one exported image per look — usually discover the cost at their second seasonal drop, when a single shared component needs to change everywhere at once. The failure rarely looks like a bug; it looks like a week spent re-exporting things nobody remembers authoring.
Worth noting too that per-element intensity is not only a browsing control. Because the same asset at the same intensity reads differently across faces and lighting conditions, most teams define a small number of presentation levels per element rather than one fixed value, which turns an aesthetic judgement into something reviewable before release.
3. Three paths, one stack
The same effect stack is consumed at three points, and nothing has to be re-authored to move between them.
| Path | Typical surface | What the library must tolerate |
|---|---|---|
| Capture | Camera preview and recording | Immediate feedback, first unstable seconds of tracking |
| Timeline editing | Clips already on a track | Scrubbing, repeated evaluation of the same frame |
| Live streaming | Real-time rendering on outgoing frames | Long unbroken sessions, no chance to retake |
One stack serving all three means a look validated in preview is not a different object later. It also means a defect found on one path is reproducible on the others, which shortens triage more than any tool does.
In practice that single description also covers the unglamorous middle: a look applied during capture can be adjusted later on a clip in the timeline, using the same package and the same intensity semantics. Users rarely distinguish those moments, and they notice immediately when the two disagree.
4. Authoring, training, and delivery
Authoring tools and training exist so that design teams work directly in the authoring environment. The alternative round trip — designers write a specification, an engineer packages it, designers discover it drifted — is slow, and it puts the people least familiar with the asset model in charge of expressing intent in it.
Delivery follows from treating materials as content, not code. Packages are data evaluated by the engine, so publishing new looks does not require a new binary or another app store review cycle. Seasonal work becomes a content release with its own calendar.
Per-element intensity sits at the intersection of the two. It is both a browsing control for end users and an authored decision, and most teams define a small number of presentation levels per element — light, standard, strong — rather than exposing a continuous slider.
The snippet below is schematic. Package shapes and method names are illustrative and are not the shipped API surface.
// Illustrative library shape consumed by any application target.
import { createEffectEngine } from "@meishe/effects-core"; // placeholder name
const engine = await createEffectEngine({
modules: ["filters.core"], // further modules load on demand
assetChannel: "https://cdn.example.com/assets", // your channel, your cadence
});
// A look references elements rather than embedding them.
await engine.assets.resolve("look.autumn.01");
await engine.looks.apply("look.autumn.01");
await engine.looks.setElementLevel("lip.satin.maple", "standard");
// The same descriptor evaluates during capture, on timeline clips, and on live output.
await engine.timeline.setClipEffect(clipId, "filter.warm.film", { intensity: 0.6 });Two properties survive whichever target reads that descriptor: updating the referenced element propagates everywhere the look appears, and the channel is yours rather than a release gate.
5. Who this is not for
Say this before the purchase rather than after.
If you need an application rather than a module, this is not it. There is no finished UI of any kind: recording controls, permission prompts, gallery access, and upload are yours to build. Teams evaluating an effects SDK while expecting a camera app will be unhappy for understandable reasons.
If you need colour measurement, this is not that either. Rendered pigment lands inside the exposure and white balance of the frame it is composited onto. The same shade reads differently in daylight, indoors, and under mixed sources, because the render follows the picture — it does not correct the room. Tone, undertone, and texture also vary person to person, so one intensity setting will not produce equivalent results across faces. Use cases that depend on a user matching a physical product need a different instrument, and users need to be told that what they see is a preview, not a colour measurement.
If nobody owns curation, the library will drift regardless of the engine. Consistency here comes from naming conventions, grouping, and agreed ownership of changes — not from rendering.
FAQ
What exactly ships with the SDK?
The effects module and the material authoring tools, including the training that accompanies them. What does not ship is any finished application surface: no editor UI, no preset store, and no shade library.
Do we author our own looks or use supplied ones?
Both are available. The authoring tools let your team produce elements and looks directly, and supplying your own is normal for branded collections. Either way the output is packaged as data.
Can the same look run on mobile, web, and desktop?
Yes, within the supported target set, because a look is a structure referencing elements rather than a platform-specific artefact. What differs by target is how your own interface reaches the engine, not the asset itself.
How much work is integrating it?
Enough to plan for. Because no camera UI is included, you own recording controls, permission handling, gallery access, and upload. The engine owns detection, tracking, compositing, and asset playback.
What is the most common mistake new teams make?
Treating looks as images. Once a look is flattened, changing one shared component means re-exporting every look that used it, and the maintenance cost starts scaling with the size of the library.
Ready to see it in your own stack? Request a free trial or talk to our integration team — we’ll help you scope the modules you actually need.