क्लाइंट-साइड बैकग्राउंड रिमूवल के लिए ब्राउज़र सपोर्ट और परफ़ॉर्मेंस

ब्राउज़र को क्या देना होता है

क्लाइंट-साइड बैकग्राउंड रिमूवर वेब पेज के अंदर चलता है, इसलिए उसे जो भी क्षमता चाहिए वह ब्राउज़र से मिलनी चाहिए, इंस्टॉल नहीं की जा सकती। चार चीज़ें ज़रूरी हैं, और इनमें से कोई एक भी न हो तो डिवाइस टूल नहीं चला सकता।

WebAssembly मॉडल को ब्राउज़र के अपने सैंडबॉक्स में चलाता है, जिससे क्लाइंट-साइड टूल की फ़ुटेज आपके डिवाइस पर ही रहती है; bgremover.ai इसकी जगह फ़ुटेज हमारे GPU सर्वर पर अपलोड करता है, जैसा बैकग्राउंड रिमूवल कैसे काम करता है में बताया गया है। इनफ़रेंस ज़्यादातर मैट्रिक्स मल्टिप्लिकेशन है, इसलिए इसे GPU चाहिए: WebGL इसे ग्राफ़िक्स API से देता है, WebGPU कंप्यूट API से।

दोनों में से कोई न हो तो इनफ़रेंस CPU पर चला जाता है। तैयार फ्रेम को फ़ाइल में एनकोड करने के लिए भी कुछ चाहिए: MediaRecorder, जो ज़्यादा जगह चलता है, या WebCodecs, जो ज़्यादा बारीक कंट्रोल देता है। चौथी ज़रूरत, डिकोड फ्रेम के लिए मेमोरी, को सबसे ज़्यादा कम आंका जाता है।

तीन एक्ज़ीक्यूशन पाथ

WebGL असल डिज़ाइन नहीं, एक जुगाड़ है: यह API त्रिकोण बनाने के लिए बना था, और टेक्सचर से डेटा ले जाने में समय लगता है। फिर भी यही प्रैक्टिकल डिफ़ॉल्ट है। WASM मेन थ्रेड के लिए होड़ करता है जब तक काम किसी वर्कर में न जाए, और BEN2 को FP16 WebGPU चाहिए, यानी सिर्फ़ नए डेस्कटॉप GPU।

यह पसंद से नहीं, उपलब्धता से तय होता है: सिर्फ़ WebGPU वाला टूल जहां चलता है वहां तेज़ है, और बाकी हर जगह गायब।

पहली बार चलाने में ज़्यादा समय क्यों लगता है

1. 1 मॉडल एक बार डाउनलोड होता है

   किसी भी फ्रेम के प्रोसेस होने से पहले।

2. 2 यह शुरू होकर वार्म अप होता है

   फिर पहला फ्रेम प्रोसेस होता है।

3. 3 अगले क्लिप में दोनों स्टेप नहीं होते

   कैश से आता है, इसलिए सिर्फ़ इनिशियलाइज़ेशन बचता है।

इसलिए क्लाइंट-साइड टूल को मॉडल पेज लोड होते ही नहीं, बल्कि यूज़र के किसी एक्शन पर लोड करना चाहिए: पेज खुलते ही मेगाबाइट्स का WebAssembly आने से, पढ़ने आए हर व्यक्ति को पेज टूटा हुआ लगेगा।

डिकोड फ्रेम का हिसाब

डिकोड किया गया वीडियो फ्रेम बिना कंप्रेशन के पिक्सल होता है, इसलिए मेमोरी पर सबसे ज़्यादा असर रेज़ोल्यूशन का होता है।

ये आंकड़े हिसाब हैं, माप नहीं, और कंप्रेस्ड फ़ाइल साइज़ से सही अंदाज़ा नहीं मिलता। सारे फ्रेम एक साथ डिकोड करने की ज़रूरत नहीं होती, लेकिन पाइपलाइन एक वर्किंग सेट रखती है: डिकोड हो रहा फ्रेम, सेगमेंट हो रहा फ्रेम, उसका मास्क, कंपोज़िट, और एनकोडर का बफ़र।

कुछ फ्रेम को 4K पर 33 MB से गुणा करें, तो टैब का बजट मायने रखने लगता है, खासकर फ़ोन पर। अगर लंबा हाई-रेज़ोल्यूशन क्लिप फ़ेल हो या टैब रीलोड हो जाए, तो लंबाई नहीं, रेज़ोल्यूशन घटाएं: हर साइड आधी करने से मेमोरी एक-चौथाई हो जाती है।

प्रोसेसिंग का समय किससे तय होता है

ये संबंध हैं, संख्याएं नहीं: एक लैपटॉप पर नापा गया समय फ़ोन के बारे में कुछ नहीं बताता।

• फ्रेम की संख्याअवधि गुणा फ़्रेम रेट; 60 fps, 30 fps का दोगुना है।
• रेज़ोल्यूशनडिकोड, कंपोज़िट और एनकोड पर असर; इनफ़रेंस वही रहता है।
• एक्ज़ीक्यूशन पाथएक ही मशीन पर WebGPU, WebGL और WASM-SIMD अलग चलते हैं।
• डिवाइस का प्रकारडेस्कटॉप, लैपटॉप और फ़ोन के GPU तीन अलग मशीनें हैं।
• मॉडल का चुनावमैटिंग हर फ्रेम पर MediaPipe से ज़्यादा महंगी है।
• गर्मी की स्थितिगर्म फ़ोन पर लगातार GPU काम थ्रॉटल हो जाता है।

ब्राउज़र सपोर्ट टेबल

साइट के यूनिवर्सल सपोर्ट का दावा करने से पहले यहां हर ब्राउज़र की जांच होनी चाहिए। बिना टेस्ट के हम सिर्फ़ आर्किटेक्चर के बारे में दावा कर सकते हैं: क्लाइंट-साइड टूल को WebAssembly और एक GPU पाथ चाहिए, WebGPU नहीं। bgremover.ai को WebCodecs चाहिए, जिससे वह अपलोड तैयार करता है और एक्सपोर्ट बनाता है।

मोबाइल की सच्ची तस्वीर

क्लाइंट-साइड टूल के लिए, MediaPipe selfie segmentation का छोटा साइज़ ही मोबाइल ब्राउज़र को मुमकिन बनाता है। कम मेमोरी वाले कुछ मेगाबाइट फ़ोन के टैब बजट में आ जाते हैं; डेस्कटॉप-GPU वाला मॉडल नहीं। bgremover.ai अपना मॉडल GPU सर्वर पर चलाकर इस समस्या से बचता है; क्लिप को डिकोड और एनकोड फ़ोन ही करता है।

हर ब्राउज़र पर टेस्ट किए बिना हम यूनिवर्सल मोबाइल सपोर्ट का दावा नहीं करेंगे। मोबाइल ज़्यादा मुश्किल है: हर टैब के लिए कम मेमोरी, टैब का जल्दी बंद होना, गर्मी से थ्रॉटलिंग। कम रेज़ोल्यूशन पर छोटे क्लिप भरोसेमंद रास्ता हैं, और फ़ोटो बैकग्राउंड रिमूवर में फ़ोटो सिर्फ़ एक फ्रेम का खर्च है।

अक्सर पूछे जाने वाले सवाल