वेबकैम स्ट्रीम — दूसरी तरफ क्या दिखता

आप वेबकैम प्रिव्यू में जो देखते हैं वह लोकल कैप्चर व्यू है — getUserMedia() से कैमरा फीड। आपके कॉल प्राप्तकर्ता जो देखते हैं वह ब्राउज़र-एनकोडेड स्ट्रीम है जिसे WebRTC ने नेगोशिएट, कम्प्रेस और संभवतः डाउनग्रेड किया। यह गाइड WebRTC codec नेगोशिएशन, getStats() से वास्तविक स्ट्रीम माप, और गुणवत्ता हानि का कारण ठीक करना समझाता है।

आप वीडियो कॉल में बैठे हैं और आपकी विंडो एक क्रिस्प, अच्छी रोशनी वाली 1080p छवि दिखाती है। आप तेज़ दिखते हैं, बैकग्राउंड साफ है, और फ्रेमिंग सही है। फिर एक सहकर्मी कहता है आपका वीडियो जम रहा है और धुंधला दिखता है, और जब वे अपनी स्क्रीन शेयर करते हैं तो आप खुद को एक ब्लॉकी, सॉफ्ट-एज वाली तस्वीर के रूप में देखते हैं जो एक दशक पुराने बजट वेबकैम से बनी हो। वही कैमरा। वही रोशनी। वही मशीन। एक अलग तस्वीर। यहां वह है जो अधिकांश वीडियो कॉल गाइड छोड़ देते हैं: वह अंतर आमतौर पर हार्डवेयर दोष या सेंसर दोष नहीं है — हालांकि एक खराब ड्राइवर कभी-कभी इसका कारण बन सकता है। यह आमतौर पर आपके कैमरे जो पैदा करता है और आपका ब्राउज़र वास्तव में जो भेजता है, उनके बीच का अंतर है। आपका प्रिव्यू लोकल कैप्चर पाथ से आता है — getUserMedia() द्वारा दिया गया कैमरा फ्रेम — WebRTC एनकोडिंग से पहले, जो इसे आपके वीडियो का एक अनुकूल दृश्य बनाता है, जो अन्य प्रतिभागियों को प्राप्त होता है उससे बेहतर। वह दृश्य ब्राउज़र द्वारा लागू स्केलिंग, कलर कन्वर्ज़न, या कंस्ट्रेंट प्रोसेसिंग शामिल कर सकता है, इसलिए यह रॉ सेंसर आउटपुट नहीं है। अन्य प्रतिभागी जो प्राप्त करते हैं वह एक कंप्रेस्ड स्ट्रीम है जिसे WebRTC द्वारा नेगोशिएट, री-एनकोडेड, रेट-लिमिटेड, और संभवतः डाउनग्रेड किया गया है, वह भी आपकी मशीन छोड़ने से कुछ मिलीसेकंड पहले। वह एनकोडिंग लेयर यूज़र इंटरफ़ेस से अदृश्य है और सामान्य ऑपरेशन के दौरान मूक रहती है। कॉल विंडो में कुछ भी आपको नहीं बताता कि यह मौजूद है, कुछ भी इसके निर्णयों की रिपोर्ट नहीं करता, और आपके प्रिव्यू में कुछ भी उन्हें प्रतिबिंबित नहीं करता। एक परिचित दृश्य: एक उपयोगकर्ता घंटों कैमरा ड्राइवर री-इंस्टॉल करता है क्योंकि कॉल में धुंधली तस्वीर दिखती है — केवल chrome://webrtc-internals से पता चलता है कि ब्राउज़र बैंडविड्थ एस्टिमेशन के आधार पर 480p15 पर नेगोशिएट कर रहा था, कैमरा या ड्राइवर की वजह से नहीं। यह पृष्ठ समझाता है कि कैमरा सेंसर और आपके कॉल पार्टनर की स्क्रीन के बीच क्या होता है, ब्राउज़र चुपचाप आपकी गुणवत्ता क्यों कम करता है, और — सबसे महत्वपूर्ण — अपनी मशीन से निकलने वाली वास्तविक स्ट्रीम को मापना प्रिव्यू पर भरोसा करने के बजाय।

प्रिव्यू आपको क्या नहीं दिखाता

वीडियो कॉलिंग एक पाइपलाइन पर टिकी है जो पूरी तरह आपकी जागरूकता से बाहर चलती है। आप जो हर फ्रेम भेजते हैं वह इन चरणों से गुजरता है:

1. कैमरा सेंसर एक फ्रेम कैप्चर करता है; ब्राउज़र फिर उसे getUserMedia() के माध्यम से अनुरोधित रिज़ॉल्यूशन और फ्रेम रेट पर देता है, जिसमें स्केलिंग, कलर कन्वर्ज़न, और कंस्ट्रेंट प्रोसेसिंग शामिल हो सकती है।
2. ब्राउज़र वह फ्रेम getUserMedia() API के माध्यम से प्राप्त करता है और WebRTC इंजन को देता है। आपका लोकल प्रिव्यू इसी चरण से आता है — इसीलिए यह हमेशा परफेक्ट दिखता है, चाहे आगे क्या भी हो।
3. WebRTC एनकोडर फ्रेम को एक नेगोशिएटेड codec, नेगोशिएटेड रिज़ॉल्यूशन, फ्रेम रेट, और बिट रेट पर कंप्रेस करता है।
4. एनकोडेड फ्रेम RTP पैकेट में विभाजित होता है और नेटवर्क पर भेजा जाता है, आमतौर पर एक मीडिया सर्वर के माध्यम से जो इसे बाकी सबको रिले करता है।
5. हर रिसीवर पैकेट को वापस एक तस्वीर में डिकोड करता है और अपनी स्क्रीन पर रेंडर करता है। आपका प्रिव्यू पाइपलाइन में चरण दो पर टैप करता है। यह कैमरा फ्रेम दिखाता है जैसा getUserMedia() द्वारा दिया गया, WebRTC एनकोडिंग से पहले। ब्राउज़र इस चरण पर स्केलिंग, कलर कन्वर्ज़न, या कंस्ट्रेंट प्रोसेसिंग लागू कर सकता है, लेकिन कोई WebRTC कंप्रेशन नहीं लागू होती। आपके कॉल पार्टनर जो स्ट्रीम देखते हैं वह चरण तीन से निकलती है। उन दो बिंदुओं के बीच, एनकोडर तय करता है कि दुनिया क्या प्राप्त करती है, और यह निर्णय ऐसी स्थितियों पर करता है जो आप कभी नहीं देखते। एनकोडर चुपचाप तीन पैरामीटर नेगोशिएट करता है, और हर एक बिना किसी सूचना के कॉल के बीच बदल सकता है:

• रिज़ॉल्यूशन — एनकोडेड फ्रेम की चौड़ाई और ऊंचाई, जो 1920×1080 से 1280×720 या 640×480 पर अपने आप गिर सकती है।
• फ्रेम रेट — कितने फ्रेम प्रति सेकंड एनकोडिंग से बचते हैं, जो आमतौर पर पहले गिरता है (30 से 15 या कम) क्योंकि फ्रेम रेट आधा करने से डेटा रेट आधा रह जाता है बिना रिज़ॉल्यूशन बदले — हालांकि कुछ इम्प्लीमेंटेशन इसके बजाय रिज़ॉल्यूशन कम कर सकती हैं, codec और प्लेटफॉर्म पर निर्भर।
• बिट रेट — एनकोडर प्रति सेकंड कितने बिट खर्च करने की अनुमति रखता है, जो समग्र कंप्रेशन लेवल तय करता है। ये तीन मान तय करते हैं कि दूसरी तरफ क्या दिखता है। एक 1080p तस्वीर जो कम बिट रेट पर कंप्रेस होती है, सॉफ्ट और स्मीयर्ड दिखती है। एक 30 fps स्ट्रीम जो अचानक 10 fps पर चल रही है, जडरी और अनैचुरल दिखती है। जब आप समझते हैं कि प्रिव्यू इनमें से कोई भी मान रिपोर्ट नहीं करता, तो एक बढ़िया कैमरा होने पर भी खराब कॉल का रहस्य समाप्त हो जाता है।

पहला फ्रेम भेजने से पहले SDP नेगोशिएट करता है

नेगोशिएशन पहला फ्रेम भेजने से पहले शुरू होता है। कॉल में जुड़ने पर, प्लेटफॉर्म और आपका ब्राउज़र Session Description Protocol (SDP) ऑफर और जवाब का आदान-प्रदान करते हैं। SDP प्रत्येक पक्ष द्वारा समर्थित codec और मीडिया क्षमताओं का विज्ञापन करता है। अनौपचारिक परीक्षण में Chrome 125 पर VP9 पहले, फिर H.264, फिर VP8 देखा गया। Safari 17 पर H.264 पहले। वास्तविक codec ब्राउज़र, प्लेटफॉर्म और हार्डवेयर पर निर्भर करता है। सामान्य विकल्प: VP9, H.264, VP8, AV1।

Codec चयन सिर्फ शुरुआत है। कॉल लाइव होने पर, दूसरा तंत्र संभालता है: बैंडविड्थ अनुमान। WebRTC लगातार नेटवर्क पथ को दोनों दिशाओं में निगरानी करता है और congestion control एल्गोरिदम चलाता है जो तीन माप करता है:

• पैकेट लॉस, RTCP फीडबैक से रिसीवर रिपोर्ट करता है।
• राउंड-ट्रिप टाइम, पैकेट भेजने और रसीद पाने के बीच देरी।
• Throughput, डेटा वास्तव में जिस दर पर चलता है।

एल्गोरिदम इन मापों को मॉडल में डालता है जो अनुमान लगाता है कि नेटवर्क वर्तमान में कितना बैंडविड्थ ले सकता है। वह अनुमान टार्गेट बिट रेट बनकर एनकोडर को मिलता है। 1080p 30 fps स्ट्रीम को लगभग 4-6 मेगाबिट/सेकंड चाहिए। यदि केवल 1 मेगाबिट उपलब्ध हो, एनकोडर रिज़ॉल्यूशन 480p और फ्रेम रेट 15 fps पर नीचे लाता है। यह फीडबैक लूप (Google: WebRTC Congestion Control Whitepaper, 2019; RFC 8888: Congestion Control Feedback for RTP) में परिभाषित है।

तीन विफलता पैटर्न जो आपकी स्ट्रीम छिपाती है

प्रिव्यू स्ट्रीम की वास्तविक स्थिति को तीन आवर्ती विफलता पैटर्न के पीछे छिपाता है। हर एक को इसके लक्षणों से पहचानना सीखें, क्योंकि सही समाधान हर मामले में अलग है। तीनों में एक संकेत साझा है: प्रिव्यू पूरे समय परफेक्ट रहता है, क्योंकि यह एनकोडर से पहले सैंपल होता है। केवल एनकोडेड स्ट्रीम — और इसलिए अन्य प्रतिभागियों की स्क्रीन — नुकसान दिखाती है।

बिट रेट ट्रैप

लक्षण: आपका प्रिव्यू परफेक्ट है और आपकी मशीन में CPU आइडल है। दूसरी तरफ एक धुंधली, कम-रिज़ॉल्यूशन तस्वीर दिखती है जो कभी तेज़ नहीं होती, विराम के दौरान भी। लोकल रिकॉर्डिंग उत्कृष्ट दिखती है; कॉल खराब दिखती है। निदान: ब्राउज़र ने अनुमान लगाया कि नेटवर्क पूरी स्ट्रीम ले नहीं सकता और बिट रेट कैप कर दिया, एनकोडर को रिज़ॉल्यूशन सिकोड़ने पर मजबूर करते हुए। बाधा आपका अपलोड बैंडविड्थ या मीडिया सर्वर की रिले क्षमता है, न कि आपका कैमरा। एक स्पीड टेस्ट चलाएं और अपने मापे गए अपलोड की तुलना उन चार से छह मेगाबिट से करें जो 1080p30 को चाहिए। यदि आप एक कनेक्शन दूसरे स्ट्रीमिंग, डाउनलोडिंग, या सिंकिंग डिवाइस के साथ साझा करते हैं, तो वे उसी बजट के लिए प्रतिस्पर्धा कर रहे हैं।

लॉस थ्रेशहोल्ड

लक्षण: कॉल से स्थिर तस्वीरें ठीक दिखती हैं, लेकिन कोई भी गति जडरी और रोबोटिक है। ऑडियो स्मूथ रहता है जबकि वीडियो स्टटर करता है, और हर कुछ सेकंड में छोटे फ्रीज़ होते हैं इससे पहले कि तस्वीर कम फ्रेम रेट पर फिर से शुरू हो। निदान: पैकेट लॉस पांच प्रतिशत थ्रेशहोल्ड को आंतरायिक रूप से पार कर रहा है, इसलिए congestion controller बार-बार टार्गेट बिट रेट काट रहा है और एनकोडर मैच करने के लिए फ्रेम ड्रॉप कर रहा है। फ्रेम रेट पहले गिरता है क्योंकि यह सस्ता लीवर है — 30 से 15 fps कम करने से डेटा रेट आधा रह जाता है बिना रिज़ॉल्यूशन बदले। Wi-Fi interference, मार्जिनल ईथरनेट केबल, या VPN की जांच करें जो लॉस और लेटेंसी जोड़ रहा हो। वीडियो तब तक डिग्रेड होता रहेगा जब तक नेटवर्क पाथ रिपेयर नहीं हो जाता।

कीफ्रेम फ्रीज़

लक्षण: जॉइन करने के बाद या स्क्रीन शेयर करने के बाद पहले दो से पांच सेकंड के लिए, दूसरी तरफ एक फ्रोज़न या भारी स्मीयर्ड तस्वीर दिखती है। फिर तस्वीर फोकस में स्नैप होती है और अगले बड़े सीन परिवर्तन तक सामान्य रहती है। निदान: वीडियो codec दो फ्रेम टाइप भेजते हैं। कीफ्रेम पूरी तस्वीर एनकोड करते हैं और एक निश्चित अंतराल पर दिखते हैं — आमतौर पर हर एक से दस सेकंड प्लेटफॉर्म और कॉन्फ़िगरेशन पर निर्भर। डेल्टा फ्रेम केवल पिछले फ्रेम से बदलाव एनकोड करते हैं, जो उन्हें छोटा बनाता है। यदि डेल्टा फ्रेम का पैकेट खो जाता है, तो रिसीवर उस फ्रेम को रीकंस्ट्रक्ट नहीं कर सकता — यह रीट्रांसमिशन (NACK) मांग सकता है, सेंडर से नया कीफ्रेम (PLI या FIR) मांग सकता है, या एरर को छिपा सकता है। जब अनुरोध सफल होता है, तो रिकवरी तेज़ होती है; जब नहीं, तस्वीर अगले शेड्यूल्ड कीफ्रेम आने तक फ्रोज़न रहती है। वह इंतज़ार ही वह फ्रीज़ है जो आप देखते हैं। छोटे कीफ्रेम अंतराल तेज़ रिकवर करते हैं लेकिन बैंडविड्थ खर्च करते हैं; लंबे अंतराल कुशल हैं लेकिन हर लॉस को अधिक दिखने वाला बनाते हैं। यह माल्फंक्शन नहीं है — यह codec डिज़ाइन के अनुसार काम कर रहा है।

getStats() से वास्तविक स्ट्रीम मापें

अनुमान लगाना बंद करें। आंकड़े आमतौर पर अनुकूल नहीं होते, लेकिन वे सच हैं। WebRTC API एक सांख्यिकी इंटरफ़ेस प्रदान करता है जो ठीक वही रिपोर्ट करता है जो एनकोडर कर रहा है, और कोई भी वेब पेज जो आप नियंत्रित करते हैं अपने पीयर कनेक्शन को पढ़ सकता है। RTCPeerConnection ऑब्जेक्ट पर getStats() कॉल करें, फिर लौटाई गई रिपोर्ट से उस outbound-rtp एंट्री को फिल्टर करें जिसका kind video है। media-source और outbound-rtp एंट्री पर आपको वे मान मिलेंगे जो मायने रखते हैं:

• framesPerSecond (media-source एंट्री पर) — वह फ्रेम रेट जो कैमरा एनकोडर को दे रहा है। यदि यह एक 30 fps कैमरे पर 30 से कम है, तो कैप्चर पाथ खुद समस्या है।
• framesPerSecond (outbound-rtp एंट्री पर) — वह फ्रेम रेट जो एनकोडर वास्तव में पैदा कर रहा है। जब यह इनपुट रेट से कम हो, तो एनकोडर फ्रेम ड्रॉप कर रहा है।
• frameWidth और frameHeight (outbound-rtp एंट्री पर) — एनकोडेड रिज़ॉल्यूशन। अपनी कॉल सेटिंग्स से तुलना करें; कोई भी अंतर एक चुपचाप डाउनग्रेड है।
• bytesSent (outbound-rtp एंट्री पर) — कुल एनकोडेड डेटा। एक सेकंड के अंतराल पर दो बार सैंपल करें और अंतर को 8 से गुणा करें ताकि वास्तविक बिट रेट मिले।
• packetsSent और packetsLost — ध्यान दें कि outbound-rtp एंट्री पर packetsLost हमेशा पॉप्युलेट नहीं होता; लॉस अनुपात remote-inbound-rtp एंट्री से अधिक विश्वसनीय रूप से पढ़ा जाता है, जो रिसीवर परिप्रेक्ष्य रिपोर्ट करता है।
• currentRoundTripTime (candidate-pair एंट्री पर) — नेटवर्क देरी। उच्च RTT लॉस के साथ मिलकर कंजेशन दर्शाता है। अलग-अलग ब्राउज़र थोड़े अलग फील्ड नाम रिपोर्ट कर सकते हैं या कुछ सांख्यिकी को पूरी तरह छोड़ सकते हैं, इसलिए उपलब्ध होने पर ब्राउज़र के WebRTC इंटरनल्स पेज से क्रॉस-चेक करें। व्याख्या नियम सरल हैं। यदि outbound-rtp framesPerSecond, media-source framesPerSecond से दिखता ही कम है, तो एनकोडर दबाव में फ्रेम शेड कर रहा है। यदि frameWidth और frameHeight आपके द्वारा कॉन्फ़िगर किए गए रिज़ॉल्यूशन से कम हैं, तो कनेक्शन बजट उसे ले नहीं सका। यदि bytesSent उस रिज़ॉल्यूशन के लिए codec की आवश्यकता से कहीं कम बिट रेट में ट्रांसलेट होता है, तो तस्वीर कुचली जा रही है — और प्रिव्यू, जो एनकोडर को कभी नहीं देखता, पूरे समय ठीक दिखता रहेगा। इन मानों को पढ़ने के लिए आपको कोड लिखने की ज़रूरत नहीं है। Chrome और Edge एक इन-बिल्ट सांख्यिकी व्यूअर chrome://webrtc-internals पर शिप करते हैं जो ब्राउज़र में हर WebRTC कनेक्शन को कैप्चर करता है, जिसमें वह भी जो कॉल प्लेटफॉर्म ने बनाया। मीटिंग जॉइन करने से पहले इसे खोलें, रिकॉर्ड होने दें, और बाद में वीडियो सेंडर के outbound-rtp एंट्री जांचें। वही फ्रेम रेट, रिज़ॉल्यूशन, बिट रेट, और लॉस आंकड़े वहां मौजूद हैं, साथ ही एक टाइमलाइन ग्राफ जो ठीक दिखाता है कि एनकोडर ने कब अपना आउटपुट बदला। यह एक वास्तविक प्लेटफॉर्म कॉल पर डाउनग्रेड को कार्यरत अवस्था में पकड़ने का सबसे तेज़ तरीका है। यह माप तब चलाएं जब आपकी अपनी कॉल बैकग्राउंड में आइडल हो, फिर एक व्यस्त मीटिंग के दौरान फिर से, और दोनों संख्याओं के सेट की तुलना करें। एक सामान्य तुलना: आइडल, outbound-rtp framesPerSecond 30 पढ़ता है; व्यस्त मीटिंग के दौरान यह 18 पर गिर सकता है जबकि लोकल प्रिव्यू अभी भी 30 दिखाता है। वह तुलना बताती है कि आपका बेसलाइन नेटवर्क पर्याप्त है और कॉल के दौरान कंटेंशन ही डाउनग्रेड को ट्रिगर करता है। हमारा webcam test लोकल कैप्चर ट्रैक की रिज़ॉल्यूशन और फ्रेम रेट दिखाता है जैसा getUserMedia() के माध्यम से नेगोशिएट किया गया — आपका कैमरा ब्राउज़र को क्या दे सकता है इसका एक उपयोगी बेसलाइन, लेकिन outbound WebRTC एनकोडेड स्ट्रीम का माप नहीं, जिसके लिए पीयर कनेक्शन या ब्राउज़र के WebRTC इंटरनल्स पेज की ज़रूरत है।

Zoom, Meet, Teams: तीन अलग कैमरा

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

• Zoom आमतौर पर स्थिरता को प्राथमिकता देता है। वर्ज़न, अकाउंट टाइप, और मीटिंग सेटिंग्स के आधार पर, यह आउटगोइंग रिज़ॉल्यूशन कैप कर सकता है और ऑडियो व ट्रीन शेयर को स्थिर रखने के लिए वीडियो गुणवत्ता का त्याग कर सकता है। एक 1080p-सक्षम कैमरा Zoom पर 720p या उससे कम में ट्रांसमिट कर सकता है।
• Google Meet मापे गए बैंडविड्थ के अनुसार अनुकूलित होने की प्रवृत्ति रखता है, जल्दी रिज़ॉल्यूशन गिराता है और स्थिति सुधरने पर तुरंत वापस लाता है। इसका व्यवहार आपकी वास्तविक नेटवर्क स्थिति का अनुसरण करता है — अच्छे और बुरे दोनों तरीकों से।
• Microsoft Teams अपनी एनकोडिंग और पोस्ट-प्रोसेसिंग पाइपलाइन लागू करता है। वर्ज़न और मीटिंग सेटिंग्स के आधार पर, तस्वीर को रॉ WebRTC नेगोशिएशन से आगे और कंप्रेस किया जा सकता है।
• ब्राउज़र-नेटिव WebRTC, जैसा आप एक सादे वेब पेज में पाते हैं, नेगोशिएटेड स्ट्रीम बिना किसी प्लेटफॉर्म नीति के भेजता है। यह आपके हार्डवेयर और नेटवर्क की प्लेन WebRTC के तहत क्या डिलीवर कर सकते हैं, इसका सबसे करीबी ग्राउंड ट्रुथ है। प्लेटफॉर्म नीतियां वर्ज़न, अकाउंट टाइप, और मीटिंग कॉन्फ़िगरेशन के अनुसार बदलती हैं, इसलिए इन्हें निश्चित नियमों के बजाय सामान्य प्रवृत्तियों के रूप में समझें। व्यावहारिक परिणाम: Zoom कॉल की तुलना Meet कॉल से करना कैमरा टेस्ट नहीं है। यह हर प्लेटफॉर्म के एनकोडिंग निर्णयों का टेस्ट है। पहले एक सादे WebRTC पेज या webcam test टूल से रॉ स्ट्रीम मापें। यदि रॉ स्ट्रीम साफ है और एक प्लेटफॉर्म फिर भी खराब दिखता है, तो प्लेटफॉर्म की नीति ही बाधा है, और कोई हार्डवेयर अपग्रेड इसे नहीं बदलेगा। जब प्लेटफॉर्म कॉल चल रही हो, chrome://webrtc-internals आपको इसके एनकोडर निर्णय लाइव देखने देता है, ताकि आप बता सकें कि डाउनग्रेड प्लेटफॉर्म की नीति है या नेटवर्क का व्यवहार, बिना किसी तरफ के सेल्फ-रिपोर्ट पर भरोसा किए।

साफ स्ट्रीम के लिए सात कदम

ये कदम अलग-अलग कारणों को अलग करते हैं। आप तब रुक सकते हैं जब स्ट्रीम ठीक दिखने लगे — लेकिन हर बदलाव से पहले और बाद में मापें ताकि पुष्टि हो सके कि समाधान ने वास्तव में आंकड़े बदले।

1. पहले मापें। chrome://webrtc-internals खोलें या अपने पीयर कनेक्शन पर getStats() का उपयोग करें और रिज़ॉल्यूशन, फ्रेम रेट, और बिट रेट रिकॉर्ड करें। यदि रॉ स्ट्रीम पहले से डाउनग्रेड है, तो आपका कैमरा और कनेक्शन समस्या है। यदि वह साफ है, तो प्लेटफॉर्म है।
2. बैंडविड्थ जांचें। वीडियो कॉल के लिए कम से कम 720p के लिए 1 Mbps अपलोड और 1080p के लिए लगभग 4 Mbps चाहिए। उसी मशीन से टेस्ट करें जिससे आप कॉल करते हैं, किसी और डिवाइस से नहीं, और नेटवर्क पर अन्य ट्रैफिक के साथ फिर से टेस्ट करें। यदि हो सके तो वायर्ड कनेक्शन पर जाएं; Wi-Fi लॉस अदृश्य डाउनग्रेड का सबसे सामान्य कारण है।
3. रोशनी ठीक करें। एक अच्छी रोशनी वाला विषय एक अंधेरे विषय से कहीं बेहतर कंप्रेस होता है, क्योंकि एनकोडर बिट रेट नॉइज़ के बजाय दिखते विवरण पर खर्च करता है। खिड़की की तरफ मुड़ें या एक सॉफ्ट लाइट स्रोत का उपयोग करें। इसकी कोई कीमत नहीं है और अक्सर किसी भी सेटिंग से बड़ा सुधार देता है।
4. वीडियो नॉइज़ रिडक्शन बंद करें जब आपका वातावरण पहले से शांत और अच्छी तरह रोशनी वाला हो। कुछ प्लेटफॉर्म कम-लाइट सीन में आक्रामक डिनॉइज़िंग लागू करते हैं, जो एनकोडेड स्ट्रीम में सूक्ष्म विवरण को ध्यान देने योग्य रूप से नरम कर सकता है। लोकल प्रिव्यू यह अंतर नहीं दिखाएगा; केवल एनकोडेड स्ट्रीम दिखाएगी। विशिष्ट प्लेटफॉर्म सेटिंग्स जांचें यह पुष्टि करने के लिए कि कौन से नियंत्रण उपलब्ध हैं।
5. वर्चुअल बैकग्राउंड बंद करें। बैकग्राउंड सेगमेंटेशन प्रभावी बिट रेट में ओवरहेड जोड़ता है और एनकोडर से GPU साइकिल खर्च करता है। एक साफ वास्तविक बैकग्राउंड निरंतर रोशनी के साथ किसी भी वर्चुअल बैकग्राउंड से बेहतर है।
6. codec जांचें। यदि आपका CPU संभाल सके, तो VP9 प्रति बिट सर्वोत्तम गुणवत्ता देता है; यदि आपको फ्रेम ड्रॉप या CPU स्पाइक दिखें, तो H.264 तेज़ एनकोड करता है। कुछ प्लेटफॉर्म सेटिंग्स में codec प्रेफरेंस दिखाते हैं।
7. दूसरा प्लेटफॉर्म टेस्ट करें। यदि गुणवत्ता एक सर्विस पर अच्छी है और दूसरी पर खराब, तो प्लेटफॉर्म की एनकोडिंग नीति ही बाधा है। अपनी अपेक्षाएं या अपना मीटिंग टूल तदनुसार समायोजित करें — आपका हार्डवेयर दोषी नहीं है।

निष्कर्ष

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

chrome://webrtc-internals खोलें। अपनी अगली कॉल जॉइन करें। outbound-rtp एंट्री देखें। यदि frameWidth या framesPerSecond आपके कैमरा सेटिंग्स में सेट किए गए मान से कम हैं, तो डाउनग्रेड हो रहा है। कारण आमतौर पर बैंडविड्थ संबंधी है — आपका ब्राउज़र जितना खर्च करने की अनुमति रखता है, और क्या आपका कनेक्शन वास्तव में वह स्ट्रीम ले सकता है जो आप भेजते हुए सोचते हैं — लेकिन CPU लोड, एनकोडर चयन, प्लेटफॉर्म नीतियां, और कंस्ट्रेंट कॉन्फ़िगरेशन भी डिग्रेडेशन में योगदान दे सकते हैं या उस पर हावी हो सकते हैं।