Browser-Unterstützung und Leistung bei clientseitiger Hintergrundentfernung

Was der Browser bereitstellen muss

Ein clientseitiger Hintergrundentferner läuft in einer Webseite, also muss jede Fähigkeit, die er braucht, vom Browser bereitgestellt werden, statt installiert zu werden. Vier davon zählen, und ein Gerät, dem auch nur eine fehlt, kann das Tool nicht ausführen.

WebAssembly führt das Modell in der browsereigenen Sandbox aus, wodurch das Material eines clientseitigen Tools auf deinem Gerät bleibt; bgremover.ai lädt es stattdessen auf unsere GPU-Server hoch, wie So funktioniert Video-Hintergrundentfernung erklärt. Inferenz ist größtenteils Matrixmultiplikation und will deshalb eine GPU: WebGL macht sie über eine Grafik-API zugänglich, WebGPU über eine Compute-API.

Ohne beides fällt die Inferenz auf die CPU zurück. Außerdem muss etwas die fertigen Frames in eine Datei codieren: MediaRecorder, der breiter verfügbare Weg, oder WebCodecs, der feinere. Die vierte Anforderung, Speicher für decodierte Frames, wird am meisten unterschätzt.

Drei Ausführungswege

WebGL ist eher ein Behelf als ein Konzept: Die API wurde gebaut, um Dreiecke zu zeichnen, und Daten über Texturen zu schieben kostet Zeit. Trotzdem bleibt sie der praktische Standard. WASM konkurriert um den Haupt-Thread, sofern die Arbeit nicht in einen Worker wandert, und BEN2 braucht FP16-WebGPU, also nur aktuelle Desktop-GPUs.

Hier entscheidet die Verfügbarkeit, nicht die Vorliebe: Ein Tool, das nur WebGPU umsetzt, ist schnell, wo es läuft, und überall sonst nicht vorhanden.

Warum der erste Durchlauf langsamer ist

1. 1 Das Modell wird einmal heruntergeladen

   Bevor irgendein Frame verarbeitet wird.

2. 2 Es initialisiert sich und wärmt sich auf

   Dann läuft der erste Frame durch.

3. 3 Spätere Clips überspringen beides

   Aus dem Cache geladen, es bleibt nur die Initialisierung.

Ein clientseitiges Tool sollte das Modell deshalb erst bei einer Nutzeraktion laden, nicht beim Seitenaufruf: Megabytes an WebAssembly, die beim Ankommen hereinströmen, würden die Seite für alle kaputt wirken lassen, die nur lesen wollten.

Die Rechnung mit decodierten Frames

Ein decodierter Video-Frame besteht aus unkomprimierten Pixeln – die Auflösung bestimmt also den Speicherbedarf.

Diese Zahlen sind Rechnung, keine Messungen, und die komprimierte Dateigröße ist ein schlechter Anhaltspunkt. Nichts muss alle Frames gleichzeitig decodieren, aber die Pipeline hält einen Arbeitssatz vor: den Frame, der gerade decodiert wird, den, der segmentiert wird, seine Maske, das Composite und den Puffer des Encoders.

Multipliziere ein paar Frames mit 33 MB bei 4K, und das Budget eines Tabs wird relevant, besonders auf dem Handy. Wenn ein langer, hochauflösender Clip fehlschlägt oder der Tab neu lädt, reduziere die Auflösung statt der Länge: Halbierst du jede Abmessung, viertelt sich der Speicherbedarf.

Was die Verarbeitungszeit bestimmt

Das sind Zusammenhänge, keine Zahlen: Eine auf einem Laptop gemessene Zeit sagt nichts über ein Handy aus.

• Anzahl der FramesDauer mal Bildrate; 60 fps sind doppelt so viel wie 30 fps.
• AuflösungBestimmt Decodieren, Compositing und Codieren; die Inferenz bleibt gleich.
• AusführungswegWebGPU, WebGL und WASM-SIMD unterscheiden sich auf ein und demselben Rechner.
• GeräteklasseDesktop-, Laptop- und Handy-GPUs sind drei verschiedene Maschinen.
• Wahl des ModellsMatting kostet pro Frame mehr als MediaPipe.
• WärmezustandAnhaltende GPU-Last auf einem warmen Handy wird gedrosselt.

Matrix der Browser-Unterstützung

Bevor die Website universelle Unterstützung behauptet, gehört hier eine Prüfung pro Browser hin. Was wir ungetestet sagen können, ist architektonisch: Ein clientseitiges Tool braucht WebAssembly und einen GPU-Weg, nicht WebGPU. bgremover.ai braucht WebCodecs, um den Upload vorzubereiten und den Export zu erstellen.

Die ehrliche Lage auf Mobilgeräten

Für ein clientseitiges Tool ist der geringe Ressourcenbedarf der MediaPipe-Selfie-Segmentierung das, was mobile Browser überhaupt erst möglich macht. Ein paar Megabyte mit bescheidenem Speicherbedarf passen ins Tab-Budget eines Handys; ein Modell für Desktop-GPUs nicht. bgremover.ai umgeht das, indem es sein Modell auf GPU-Servern laufen lässt; das Handy decodiert und codiert den Clip aber trotzdem.

Universelle Unterstützung auf Mobilgeräten behaupten wir erst, wenn wir pro Browser getestet haben. Mobil ist schwieriger: weniger Speicher pro Tab, aggressives Entladen, thermische Drosselung. Kürzere Clips mit geringerer Auflösung sind der zuverlässige Weg, und Standbilder über den Bild-Hintergrundentferner kosten nur einen Frame.

Häufige Fragen