{"id":396,"date":"2026-10-19T16:53:01","date_gmt":"2026-10-19T08:53:01","guid":{"rendered":"https:\/\/en.meishesdk.com\/blog\/?p=396"},"modified":"2026-10-19T16:53:02","modified_gmt":"2026-10-19T08:53:02","slug":"face-beauty-sdk-for-web-mobile","status":"publish","type":"post","link":"https:\/\/en.meishesdk.com\/blog\/396.html","title":{"rendered":"Face Beauty SDK for Web & Mobile"},"content":{"rendered":"\n

A face beauty SDK<\/strong> looks like one line on a roadmap and turns into two implementations the moment it ships. In the browser you inherit a camera stream you do not control, a compositor whose behaviour shifts between operating system versions, and a GPU budget shared with every other tab. On mobile you get far richer camera control and direct access to hardware codecs, but you also carry several OS generations with subtly different colour handling. Build the two independently and users notice: the same person looks smoothed and reshaped one way in the web session and another way in the app.<\/p>\n\n\n\n

Meishe builds Face Beauty SDK on one cross-platform audio\/video processing engine \u2014 the same core used across the product family. The per-target packages differ; the detection pipeline, the parameter semantics, and the asset format do not. That separation is what turns cross-platform retouching into a configuration exercise rather than a port.<\/p>\n\n\n\n

This article walks through where web and mobile beauty pipelines drift apart, what has to be shared to keep them aligned, and what genuinely has to be tuned per target.<\/p>\n\n\n\n

1. Product Positioning<\/h2>\n\n\n\n

Meishe Face Beauty SDK is a retouching module set built on the cross-platform audio\/video processing engine used across the product family. It covers three operations that share a single detection pass: face reshaping, skin smoothing, and virtual makeup compositing \u2014 all evaluated in real time, with no preprocessing stage ahead of preview. The audience is teams whose product already has a camera, a recorder, or an editor and needs retouching inside it: social and live commerce apps, conferencing tools, creator utilities, and browser-based video studios. The SDK does not ship a finished camera UI; your team owns the interface, permission handling, and upload flows.<\/p>\n\n\n\n

2. Where browser and mobile pipelines drift apart<\/h2>\n\n\n\n

Drift shows up in three places.<\/p>\n\n\n\n

Input.<\/strong> A mobile integration can negotiate camera profiles and request specific resolution and frame cadence from the platform. A browser tab receives whatever the platform media stack grants, and device-side capability varies far more than most teams plan for. The common workaround \u2014 transcode or resize before processing \u2014 quietly becomes a second source of truth for how a face looks.<\/p>\n\n\n\n

Budget.<\/strong> A flagship phone sustains multi-layer compositing comfortably. A mid-range laptop running a busy tab does not. The honest fix is not to strip features from the web build but to make the render graph degrade in a controlled order, and to know which knob does the degrading.<\/p>\n\n\n\n

Colour.<\/strong> Mobile clients sit closer to the camera’s own processing, while browser preview depends on platform colour management. Two pipelines that look correct in isolation still disagree side by side. The colour pipeline here supports HDR preview, mixed HDR and SDR material on a single timeline, and export following either HLG or ST 2084, so the transfer chain is explicit rather than implied.<\/p>\n\n\n\n

\"Face<\/a><\/figure>\n\n\n\n

3. One detection pass, several consumers<\/h2>\n\n\n\n

Retouching cost is dominated by detection, and detection should run once. Face detection locates how many faces are present and where, with a confidence value attached to each result. Landmark analysis then places reference points on facial structure \u2014 contour, eyes, brows, lips, nose. Everything downstream consumes that shared output:<\/p>\n\n\n\n

Detection output<\/th>Consumed by<\/th>What it decides<\/th><\/tr><\/thead>
Face bounds<\/td>Subject framing, AR anchoring<\/td>Where an effect is allowed to attach<\/td><\/tr>
Facial landmarks<\/td>Reshaping control points, smoothing regions, makeup placement<\/td>How the face is redrawn<\/td><\/tr>
Landmark motion<\/td>Temporal stabilisation<\/td>Whether a subtle adjustment holds still<\/td><\/tr>
Segmentation<\/td>Effects that treat subject and background separately<\/td>What is protected from processing<\/td><\/tr>
Gesture detection<\/td>Interactive props<\/td>Whether an interaction fires<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Because the work is shared, adding a sticker or a second makeup element does not add another round of full detection. That property is the reason a three-operation retouching stack fits inside a real-time budget at all.<\/p>\n\n\n\n

The sensitivity trade-off, stated plainly<\/h3>\n\n\n\n

Detection sensitivity cuts both ways. Set too strict, and the effect drops out when a face is partially turned or poorly lit. Set too loose, and the effect appears on a poster or on a reflection in the background. There is no threshold that removes this trade-off. Single-subject camera paths generally prefer strict detection plus a stable result; decorative scenes with several faces tolerate looser thresholds. It is a product decision you make deliberately, not a defect you discover later.<\/p>\n\n\n\n

4. Capability parity across targets<\/h2>\n\n\n\n
Capability<\/th>Web<\/th>iOS<\/th>Android<\/th>Desktop (Windows)<\/th>Notes<\/th><\/tr><\/thead>
Real-time beauty preview<\/td>Yes<\/td>Yes<\/td>Yes<\/td>Yes<\/td>No preprocessing pass<\/td><\/tr>
Reshaping with per-region parameters<\/td>Yes<\/td>Yes<\/td>Yes<\/td>Yes<\/td>Same landmark model<\/td><\/tr>
Smoothing bounded by landmark regions<\/td>Yes<\/td>Yes<\/td>Yes<\/td>Yes<\/td>Boundary handling in one pass<\/td><\/tr>
Virtual makeup compositing<\/td>Yes<\/td>Yes<\/td>Yes<\/td>Yes<\/td>Layer above the processed frame<\/td><\/tr>
Up to 8K video editing, 16K image processing<\/td>Yes<\/td>Yes<\/td>Yes<\/td>Yes<\/td>Upper bound also set by the device decoder<\/td><\/tr>
HDR preview, HLG \/ ST 2084 export<\/td>Yes<\/td>Yes<\/td>Yes<\/td>Yes<\/td>Colour pipeline converts internally<\/td><\/tr>
Portable asset packages<\/td>Yes<\/td>Yes<\/td>Yes<\/td>Yes<\/td>Materials as content, not code<\/td><\/tr>
No plug-in or driver installation<\/td>Yes<\/td>\u2014<\/td>\u2014<\/td>\u2014<\/td>Standard browser facilities only<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The dashes matter. “Desktop (Windows)” is the desktop scope; other desktop operating systems are not part of the official target list, and writing them into an evaluation spreadsheet creates work for everyone downstream.<\/p>\n\n\n\n

5. Looks as content, not as release code<\/h2>\n\n\n\n

The least glamorous and most valuable part of parity is packaging. Beauty materials and filters ship as packages rather than compiled code. A packaging decision changes who does the work: because assets are data, a seasonal look or a holiday makeup set reaches browser and mobile through one channel, without an app release or a store review cycle.<\/p>\n\n\n\n

\n

The snippet below is schematic. Module names, parameter names, and signatures are illustrative and do not represent the shipped API surface.<\/p>\n<\/blockquote>\n\n\n\n

\/\/ Illustrative: one look description reused by a web session and a mobile session.\nimport type { BeautyLook } from \"@meishe\/beauty\"; \/\/ placeholder import\n\nconst studioLook: BeautyLook = {\n  id: \"studio.natural.v3\",\n  smoothing: { level: 0.45, protect: [\"eyes\", \"brows\", \"lips\", \"hairline\"] },\n  reshaping: { chin: 0.12, jaw: 0.08, eyes: 0.10, nose: 0.05 },\n  makeup: [{ element: \"lip.tint.rose\", intensity: 0.6 }],\n  detection: { minConfidence: 0.7, cadence: 3 },\n};\n\nawait webSession.beauty.apply(studioLook);\nawait mobileSession.beauty.apply(studioLook); \/\/ identical semantics on both ends<\/code><\/pre>\n\n\n\n
The interesting line is cadence<\/code>. Nothing about how the face looks changes when you alter it \u2014 only how often detection runs.<\/p>\n\n\n\n
6. Budgets: what degrades, and in what order<\/h2>\n\n\n\n
Detection typically runs on downsampled frames; intermediate frames track or reuse landmarks, with full detection re-run on a lower frequency. Users see identical parameters while the per-frame cost changes materially. On constrained hardware, cadence is the primary lever for fitting the retouching chain into budget.<\/p>\n\n\n\n
Temporal stability is what bounds how far you can push that lever. Landmark positions that jitter by fractions of a degree produce visible flicker in reshaping and makeup even when every individual frame looks acceptable. Cross-frame stabilisation is the difference between an adjustment that reads as steady and one that reads as twitchy \u2014 and it matters most at exactly the small, conservative settings users actually prefer.<\/p>\n\n\n\n
FAQ<\/h2>\n\n\n\n
Does input need preprocessing or transcoding before retouching?<\/strong>
No preprocessing stage is required. The engine renders effects in real time directly from incoming frames, which removes a whole category of “works on mobile, needs transcoding on web” defects.<\/p>\n\n\n\n
Can one beauty asset package serve both the browser build and the app?<\/strong>
Yes. Asset packages are data rather than code, so an authored look ships to every target with identical semantics and no per-platform reauthoring.<\/p>\n\n\n\n
What happens when detection loses the face during a take?<\/strong>
Your session sets the policy. With a stricter confidence threshold the effect may drop out on a turned head or in poor light; with a looser one it may attach to something that is not a face. Most single-subject camera flows prefer strict detection and rely on tracking between full detections.<\/p>\n\n\n\n
Does enabling makeup multiply the cost of smoothing and reshaping?<\/strong>
No. Detection runs once and landmark output is shared, and makeup compositing works as a layer above the already-processed frame. Changing one operation does not force a recomputation of the others.<\/p>\n\n\n\n
Who owns the camera UI and permission prompts?<\/strong>
Your team. The SDK supplies the processing engine and effect modules, not a finished application shell. The recording interface, permission flow, and upload pipeline stay in your product.<\/p>\n\n\n\n
Ready to see it in your own stack? Request a free trial<\/a> or talk to our integration team<\/a> \u2014 we’ll help you scope the modules you actually need.<\/p>\n","protected":false},"excerpt":{"rendered":"
A face beauty SDK looks like one line on a roadmap and turns into two implementations the moment it ships. In the browser you inherit a camera stream you do not control, a compositor whose behaviour shifts between operating system versions, and a GPU budget shared with every other tab. On mobile you get far richer camera […]<\/p>\n","protected":false},"author":1,"featured_media":397,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[40,46,4,114,375],"class_list":["post-396","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-face-ar-sdk","tag-face-ar-sdk","tag-face-beauty-sdk","tag-meishe","tag-mobile","tag-web"],"_links":{"self":[{"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/posts\/396","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/comments?post=396"}],"version-history":[{"count":1,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/posts\/396\/revisions"}],"predecessor-version":[{"id":398,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/posts\/396\/revisions\/398"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/media\/397"}],"wp:attachment":[{"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/media?parent=396"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/categories?post=396"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/tags?post=396"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}