Desktop is the only face beauty SDK deployment where nobody is holding anything. There is no thermal envelope to fall off after ten minutes, no cellular connection to lose mid-upload, and — critically — no assumption that the person using it is the person in frame. That last point changes what the software needs to do, because it moves retouching from a self-facing activity to a reviewing and finishing workflow.
On Desktop (Windows), the official framing covers two things: authoring review and editing-path application, plus preview and batch asset work within a desktop workflow. This article unpacks all three, then covers what desktop changes about budgets and what it does not change at all.
Everything below assumes Windows; other desktop operating systems are not part of the supported target list, and planning around them would produce work with nothing behind it.
1. Product Positioning
Meishe Face Beauty SDK performs face reshaping, skin smoothing, and virtual makeup compositing from one detection pass per frame, rendered in real time with no preprocessing stage. On Desktop (Windows) the module set supports authoring review and editing-path application, alongside preview and batch asset work within a desktop workflow. As on every target, your application owns interface, permission prompts, and export; and the same cross-platform audio/video processing engine used across the product family supplies up to 8K video editing, 16K image processing, HDR preview, and export in HLG or ST 2084.
2. What desktop changes
Four differences matter more than raw capability.
The operator is not the subject. Retouching is something a person does to someone else’s footage, so controls need to be reviewable and repeatable rather than momentary.
Sessions are long. A review session can hold thousands of frames open, which turns resource discipline into a functional requirement rather than politeness.
Output is heavier. Desktop workflows finish things: long timelines, high-bitrate exports, and resolution that mobile workflows never touch.
Keyboard and window conventions apply. Review tools live inside expectations about undo, shortcuts, and multi-window layouts that mobile users never ask about and desktop users assume immediately.
3. Authoring review: checking assets before they ship
Authoring review is the desktop role most teams overlook. Before a look reaches a mobile release, someone has to answer: does this element behave across a range of faces, and does it hold up over thirty seconds of movement rather than one frame?
Because beauty materials ship as data packages rather than compiled code, that review loop does not require an application build between iterations. An author adjusts, re-previews, and the change lands in the same session. This is also where curation discipline lives — the same element at the same intensity reads differently on different faces, so per-element intensity is a curated range rather than one fixed value, and desktop is where that range gets chosen.
Two properties make desktop the right place for this. It can hold many subjects side by side, and it can replay long takes without the thermal behaviour that complicates long mobile sessions.
4. The editing path
Editing-path application means retouching evaluated on a timeline rather than exclusively in front of a camera. The important structural property is that nothing is baked during preview: effects render in real time with no preprocessing stage, so scrubbing shows the same result an export will produce.
This matters most around detection boundaries. Edits frequently cut mid-phrase, and reattachment after a cut or an occlusion should be predictable. Reshaping anchors to landmarks and warps surrounding pixels, smoothing stays bounded to landmark-defined regions with boundary handling in the same pass, and makeup composites as a layer above the processed frame — all of which stay true per frame on the timeline, not just in a live preview.
5. Preview and batch asset work
Batch work is where desktop earns its keep. When a content team ships forty looks or revises a set after a review, nobody wants forty interactive sessions.
The snippet below is schematic. Type names, fields, and helper names are illustrative and do not represent the shipped API surface.
// Illustrative: a batch review pass over an asset set within a desktop workflow.
export interface BatchJob {
workspaceId: string;
subjects: string[]; // fixture clips representing a range of faces
looks: string[]; // asset packages under review
detection: { minConfidence: number; cadence: number };
reviewWindowMs: number; // how much of each clip a reviewer evaluates
}
export async function runBatch(job: BatchJob) {
for (const look of job.looks) {
for (const subject of job.subjects) {
const session = await openSession(job.detection);
await session.loadLook(look);
await session.render(subject, { upToMs: job.reviewWindowMs });
await session.close(); // explicit release: batches leak otherwise
}
}
}Notice the loop release. In batch work, session lifecycle is the difference between a job that finishes forty sub-runs and one that fails at run nine for reasons that look like a renderer fault. Explicit disposal is not optional here, and it should be asserted in your test suite rather than assumed.
6. Export budgets and long-session stability
Desktop resolution headroom invites misuse, so it needs stating with its qualification: the pipeline reaches up to 8K video editing and 16K image processing, and export supports HLG or ST 2084, but what any given machine sustains also depends on its memory and decoder capability. Express your export budget as a per-configuration statement rather than an absolute, and validate it on the weakest machine you support.
Long-session stability follows similar discipline. Three practices prevent most incidents: release every session explicitly, separate asset download from application lifetime so content accumulates without leaking into process memory, and monitor the batch loop rather than trusting it to complete.
Retouching cost meanwhile stays the same shape as everywhere else. Detection runs on downsampled frames, intermediate frames track or reuse landmarks, and full analysis re-runs at a lower frequency — so even on a workstation, cadence is the first lever if a heavy timeline starts missing its budget.
7. What desktop does not change
| Area | Desktop behaviour | What it does not change |
|---|---|---|
| Detection thresholds | Same two-way trade-off | Tighter means dropouts; looser means false positives |
| Landmark motion | Same mitigation | Flicker stays most visible at conservative intensities |
| Asset packages | Same data format | Content still ships without an application release |
| Session lifecycle | Same requirement | Explicit disposal is still mandatory |
| Target scope | Windows only | Other desktop operating systems are unsupported |
The rows above are worth reading as a warning as much as a spec. Desktop does not repair analysis. If detection does not locate the face correctly, no amount of tuning in the rendering stage recovers the result — and a workstation’s extra headroom does not change that, because the error is in what the operations read, not in how fast they run. What desktop gives you is room to review decisions properly: hold many subjects side by side, replay long takes, and finish heavy output without a thermal limit dictating the pace.
FAQ
Which desktop operating system is supported?
Windows. The official target is Desktop (Windows); other desktop operating systems are not part of the supported list, and planning around them would produce work with nothing behind it.
What is authoring review, operationally?
Reviewing looks and elements on a workstation before they ship: checking behaviour across several subjects, over long takes, and adjusting curated intensity ranges without an application build between iterations.
Can we run batch work without interactive preview?
Yes. Batch asset work is supported within a desktop workflow, which is what lets a review pass run across a whole set rather than requiring an operator to sit through every combination. How those passes are orchestrated — queued, scheduled, or driven by a reviewer — is your application’s decision, and is worth agreeing internally before you design the review screen.
Does higher-end hardware change the retouching result?
Not the result itself. A workstation sustains heavier timelines and finishes exports faster, but detection quality, landmark stability, and asset semantics behave identically.
Where do batch jobs usually fail first?
Session lifecycle. Loops that open a session per sub-run and release it late will fail at an arbitrary point, and the failure reads like a renderer fault rather than a leak.
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.