Your GAN Beauty Effect Needs a Device Budget, Not a Universal “On” Switch

Tencent RTC's Beauty AR documentation and low-end optimization guide recommend that developers implement device-aware policies for GAN-powered beauty effects rather than enabling all features universally. A developer demonstrates an application-owned Beauty AR controller in TypeScript that separates consent, capability probing, and fallback states to avoid degrading performance on constrained devices.

A GAN-powered beauty effect can look convincing in a product demo and still be the wrong default for a real session. The uncomfortable part is not whether the effect is “AI.” It is deciding what the application should do when appearance processing, segmentation, rendering, and video compete for a limited device budget. If the answer is simply “enable everything and hope,” lower-capability devices pay the price. This is also where writing less integration code can create more engineering responsibility. The durable skill is not producing another effect toggle. It is defining consent, capability, fallback, and verification rules that remain understandable when the renderer fails. In this tutorial, we will build an application-owned Beauty AR controller that: Tencent RTC Beauty AR supports scenarios including real-time beauty filters, makeup, stickers, virtual backgrounds, avatars, gesture recognition, and image or video enhancement. The official overview is the appropriate starting point for checking the features available to your integration: https://trtc.io/document/beauty-ar-overview https://trtc.io/document/beauty-ar-overview For device-tier and degradation guidance, Tencent RTC’s low-end optimization guide recommends adapting the configuration to device capability, using performance-oriented modes, controlling resolution and frame rate, and disabling expensive segmentation or 3D/GAN effects where necessary: https://trtc.io/document/66968 https://trtc.io/document/66968 The code below is deliberately an application policy, not a replacement for the official platform-specific integration instructions. A useful Beauty AR contract separates three decisions that are often collapsed into one checkbox: A user selecting “Full” should not force a constrained device to run every effect. It means the application may use the richest profile that its capability policy currently permits. We will use these states: php awaiting-consent | +-- denied -------------------------- off | +-- granted -- probing -- applying -- running | | | +-- sustained pressure | | +-- failure v applying safer profile | +-- degraded | +-- failed -- off The distinction between degraded and failed matters. Degraded means the session is still providing an intentionally reduced visual experience. Failed means no approved profile could be applied safely, so the effects are off. Use Node.js with TypeScript for the policy and tests: mkdir beauty-budget cd beauty-budget npm init -y npm install --save-dev typescript tsx @types/node mkdir src test Add these scripts to package.json : { "scripts": { "test": "tsx --test test/ / .test.ts" } } The policy can be tested without a camera, a live room, or a specific Beauty AR SDK method. That is intentional: renderer callbacks should provide evidence to the policy, not contain the policy themselves. Create src/policy.ts : export type Tier = "constrained" | "balanced" | "capable"; export type Preference = "off" | "auto" | "basic" | "full"; export type Phase = | "awaiting-consent" | "probing" | "applying" | "running" | "degraded" | "off" | "failed"; export type Feature = | "beauty" | "makeup" | "stickers" | "segmentation" | "gan" | "avatar"; export interface RenderProfile { id: string; mode: "performance" | "quality"; inputHeight: number; targetFps: number; features: Feature ; } const tierProfiles: Record<Tier, RenderProfile = { constrained: { id: "constrained-v1", mode: "performance", inputHeight: 480, targetFps: 15, features: "beauty" }, balanced: { id: "balanced-v1", mode: "performance", inputHeight: 720, targetFps: 24, features: "beauty", "makeup", "stickers" }, capable: { id: "capable-v1", mode: "quality", inputHeight: 720, targetFps: 30, features: "beauty", "makeup", "stickers", "segmentation", "gan", "avatar" } }; function profileFor tier: Tier, preference: Preference : RenderProfile { const base = tierProfiles tier ; if preference === "basic" { return { ...base, id: ${base.id}-basic , features: base.features.filter feature = feature === "beauty" }; } return { ...base, features: ...base.features }; } export interface State { phase: Phase; consent: "unknown" | "granted" | "denied"; preference: Preference; tier?: Tier; profile?: RenderProfile; revision: number; badWindows: number; hasDegraded: boolean; error?: string; } export type Event = | { type: "CONSENT GRANTED" } | { type: "CONSENT DENIED" } | { type: "PROBE COMPLETED"; tier: Tier } | { type: "PREFERENCE CHANGED"; preference: Preference } | { type: "FRAME WINDOW"; observedFps: number } | { type: "PROFILE APPLIED"; revision: number } | { type: "PROFILE FAILED"; revision: number; error: string }; export type Command = | { type: "APPLY PROFILE"; revision: number; profile: RenderProfile } | { type: "DISABLE EFFECTS" }; export function initialState : State { return { phase: "awaiting-consent", consent: "unknown", preference: "auto", revision: 0, badWindows: 0, hasDegraded: false }; } function lowerTier tier: Tier : Tier | undefined { if tier === "capable" return "balanced"; if tier === "balanced" return "constrained"; return undefined; } function startApply state: State, tier: Tier, degraded: boolean : State, Command { const revision = state.revision + 1; const profile = profileFor tier, state.preference ; return { ...state, phase: "applying", tier, profile, revision, badWindows: 0, hasDegraded: state.hasDegraded || degraded, error: undefined }, { type: "APPLY PROFILE", revision, profile } ; } export function reduce state: State, event: Event : State, Command { switch event.type { case "CONSENT GRANTED": return { ...state, consent: "granted", phase: "probing", error: undefined }, ; case "CONSENT DENIED": return { ...state, consent: "denied", preference: "off", phase: "off", profile: undefined, revision: state.revision + 1, badWindows: 0 }, { type: "DISABLE EFFECTS" } ; case "PROBE COMPLETED": if state.consent == "granted" || state.preference === "off" { return state, ; } return startApply state, event.tier, false ; case "PREFERENCE CHANGED": { if event.preference === "off" { return { ...state, preference: "off", phase: "off", profile: undefined, revision: state.revision + 1, badWindows: 0 }, { type: "DISABLE EFFECTS" } ; } const next = { ...state, preference: event.preference }; if next.consent == "granted" return next, ; if next.tier return { ...next, phase: "probing" }, ; return startApply next, next.tier, false ; } case "FRAME WINDOW": { if state.phase == "running" && state.phase == "degraded" || state.profile || state.tier { return state, ; } // An application-owned starting threshold, not a product benchmark. const belowBudget = event.observedFps < state.profile.targetFps 0.8; const badWindows = belowBudget ? state.badWindows + 1 : 0; if badWindows < 3 { return { ...state, badWindows }, ; } const saferTier = lowerTier state.tier ; if saferTier { return { ...state, phase: "failed", profile: undefined, badWindows: 0, error: "Frame budget was not sustained on the safest profile" }, { type: "DISABLE EFFECTS" } ; } return startApply { ...state, badWindows: 0 }, saferTier, true ; } case "PROFILE APPLIED": // The user may have turned effects off while an apply was in flight. if event.revision == state.revision || state.phase == "applying" { return state, ; } return { ...state, phase: state.hasDegraded ? "degraded" : "running", badWindows: 0 }, ; case "PROFILE FAILED": { if event.revision == state.revision || state.phase == "applying" { return state, ; } const saferTier = state.tier ? lowerTier state.tier : undefined; if saferTier { return startApply { ...state, error: event.error }, saferTier, true ; } return { ...state, phase: "failed", profile: undefined, error: event.error }, { type: "DISABLE EFFECTS" } ; } } } The numeric profile values and the 80% threshold are example application defaults, not Tencent RTC performance guarantees. Calibrate them using measurements from the devices your application actually supports. The more important property is the ordering: php capable - balanced - constrained - effects off GAN and segmentation disappear before basic beauty processing does. The user still gets a valid session rather than an all-or-nothing renderer. Keep platform-specific SDK calls behind a narrow adapter: python import type { Command, Event, RenderProfile } from "./policy.js"; export interface BeautyRenderer { apply profile: RenderProfile : Promise<void ; disable : Promise<void ; } export async function execute command: Command, renderer: BeautyRenderer, dispatch: event: Event = void : Promise<void { if command.type === "DISABLE EFFECTS" { await renderer.disable ; return; } try { await renderer.apply command.profile ; dispatch { type: "PROFILE APPLIED", revision: command.revision } ; } catch error { dispatch { type: "PROFILE FAILED", revision: command.revision, error: error instanceof Error ? error.message : "Unknown renderer error" } ; } } BeautyRenderer.apply is an application-defined port, not a Tencent RTC API name. Its concrete implementation should map the selected profile to the documented Beauty AR configuration for your target platform. That adapter is also the right place to normalize errors. A production implementation should distinguish at least: A permanent configuration error should normally stop immediately rather than trying every performance tier. The generic sample falls back because it cannot know the platform-specific error taxonomy. Do not infer “capable” solely from a device model or user-agent string. Two nominally identical devices can differ because of thermal state, background load, browser behavior, camera configuration, or power settings. A practical probe can combine: Run the probe only after consent, and avoid publishing or retaining camera frames merely to classify the device. The policy needs a tier result, not the images used to produce it. Use a conservative tier when measurement is missing. “Unknown” should not silently mean “capable.” There is another measurement trap: poor remote video can come from the network, encoder, decoder, or receiver. Do not downgrade local Beauty AR solely because a remote participant reports low frame rate. Feed this policy measurements attributable to the local rendering path. Create test/policy.test.ts : python import test from "node:test"; import assert from "node:assert/strict"; import { initialState, reduce, type State } from "../src/policy.js"; function grantAndProbe tier: "constrained" | "balanced" | "capable" { let state = initialState ; state = reduce state, { type: "CONSENT GRANTED" } ; const applying, commands = reduce state, { type: "PROBE COMPLETED", tier } ; return { state: applying, commands }; } test "does not apply a profile before consent", = { const state, commands = reduce initialState , { type: "PROBE COMPLETED", tier: "capable" } ; assert.equal state.phase, "awaiting-consent" ; assert.equal commands.length, 0 ; } ; test "a capable device may receive the GAN profile", = { const { state, commands } = grantAndProbe "capable" ; assert.equal state.phase, "applying" ; assert.equal state.profile?.features.includes "gan" , true ; assert.equal commands 0 ?.type, "APPLY PROFILE" ; } ; test "three bad windows cause one downgrade", = { let { state } = grantAndProbe "capable" ; state = reduce state, { type: "PROFILE APPLIED", revision: state.revision } ; let commands = as ReturnType<typeof reduce 1 ; for let i = 0; i < 3; i++ { state, commands = reduce state, { type: "FRAME WINDOW", observedFps: 10 } ; } assert.equal state.tier, "balanced" ; assert.equal state.phase, "applying" ; assert.equal state.hasDegraded, true ; assert.equal commands 0 ?.type, "APPLY PROFILE" ; assert.equal state.profile?.features.includes "gan" , false ; } ; test "an apply failure tries a safer tier", = { let { state } = grantAndProbe "balanced" ; const failedRevision = state.revision; const next, commands = reduce state, { type: "PROFILE FAILED", revision: failedRevision, error: "renderer initialization failed" } ; assert.equal next.tier, "constrained" ; assert.equal next.phase, "applying" ; assert.equal commands 0 ?.type, "APPLY PROFILE" ; } ; test "a late success cannot resurrect effects after user turns them off", = { let state: State = grantAndProbe "capable" .state; const oldRevision = state.revision; state = reduce state, { type: "PREFERENCE CHANGED", preference: "off" } ; state = reduce state, { type: "PROFILE APPLIED", revision: oldRevision } ; assert.equal state.phase, "off" ; assert.equal state.profile, undefined ; } ; Run the suite: npm test These tests verify the policy’s invariants rather than whether one machine can render a particular effect. An obvious extension is to upgrade again as soon as frame rate recovers. That usually creates a new problem: oscillation. A device may briefly recover after an expensive effect is disabled. If the application immediately restores the effect, frame pressure returns, causing another downgrade. The user sees repeated visual changes while the renderer does unnecessary work. A safer default is: If you do implement automatic recovery, require substantially more good evidence than bad evidence. For example, degradation might require three poor windows while recovery requires a much longer stable interval. Those values still need calibration rather than guesswork. The revision check prevents a late PROFILE APPLIED event from moving the application back to running . The renderer adapter must also release loaded resources and stop processing. Choose the conservative profile. Do not translate missing data into permission to enable segmentation, avatars, or GAN effects. The sample tries the constrained profile. In production, classify errors first. A missing credential or invalid configuration will not be repaired by reducing resolution. Disable Beauty AR while preserving the underlying call or live session. Beauty effects are optional; communication should not depend on them. Graphics resources may no longer be in the state your controller expects. Treat restoration as revalidation: check consent, verify that the revision is still current, and reapply no more than the last approved tier. Keep the constrained profile and explain why richer effects are unavailable. Do not quietly pretend the GAN effect is active, but do not override the safety policy either. GAN-based visual processing can produce effects that would be difficult to implement with simple color adjustments. That demonstrated capability does not answer the product questions around it: Those are application and human decisions, not outputs to delegate to a model. For many developers, the underlying tension is that integrating an advanced effect can now take less code, while being confident in the result requires more judgment. That is not a loss of engineering value. The valuable work has moved toward defining constraints, making degradation visible, and proving that user control survives asynchronous failure. Before shipping, verify all of the following: The goal is not to make every device render the most impressive effect. It is to make every outcome intentional: rich where supported, restrained where necessary, off when requested, and recoverable when rendering fails. Disclosure: I wrote this article in connection with Tencent RTC, and I used the official Tencent RTC Beauty AR documentation as the implementation reference.