ویب کیم سٹریم ٹیسٹ — حقیقت کیا ہے

آپ اپنے ویب کیم پری ویو میں جو دیکھتے ہیں وہ لوکل کیپچر ویو ہے — getUserMedia() کے ذریعے ڈیلیورڈ کیمرا فیڈ — خام سینسر آؤٹ پٹ نہیں۔ آپ کے ویڈیو کال وصول کنندہ جو دیکھتا ہے وہ براؤزر-اینکوڈڈ سٹریم ہے جسے WebRTC نے خاموشی سے negotiate، compress اور ممکنہ طور پر downgrade کیا ہے۔ یہ گائیڈ WebRTC codec negotiation کیسے کام کرتا ہے، RTCPeerConnection پر getStats() کا استعمال کرکے اصل سٹریم پیرامیٹرز کیسے ناپنے ہیں، اور کوالٹی نقصان کی عام وجوہات کو کیسے ٹھیک کرنا ہے بیان کرتا ہے۔ نوٹ کریں کہ اس سائٹ کا ویب کیم ٹول صرف لوکل کیپچر ٹریک اور براؤزر فریم ریٹ چیک کرتا ہے؛ یہ آؤٹ باؤنڈ WebRTC اینکوڈڈ سٹریم کو نہیں ماپتا۔

ویڈیو کال میں بیٹھے ہیں، آپ کی ونڈو 1080p کی crisp، اچھی روشنی والی تصویر دکھاتی ہے۔ آپ sharp لگ رہے ہیں، بیک گراؤنڈ صاف ہے، framing درست ہے۔ پھر ایک ساتھی کہتا ہے کہ آپ کا ویڈیو مسلسل freeze ہو رہا ہے اور دھندلا لگ رہا ہے، اور جب وہ اپنی screen share کرتے ہیں تو آپ خود کو blocky، نرم کناروں والی تصویر میں دیکھتے ہیں جو دہائی پرانا budget webcam بھی پیدا کرتا۔ وہی کیمرا۔ وہی روشنی۔ وہی مشین۔ ایک مختلف تصویر۔

یہ وہ بات ہے جو زیادہ تر ویڈیو کال گائیڈز چھوڑ دیتی ہیں: یہ فاصلہ عام طور پر ہارڈویئر fault یا سینسر defect نہیں ہے — اگرچہ کبھی کبھی misbehave والا driver بھی اس کا سبب بن سکتا ہے۔ یہ عام طور پر آپ کے کیمرا کی پیداوار اور آپ کے براؤزر کی دراصل بھیجی گئی چیز کے درمیان فرق ہے۔ آپ کا پری ویو لوکل کیپچر پاتھ سے فیڈ ہوتا ہے — getUserMedia() کے ذریعے ڈیلیورڈ کیمرا فریم — WebRTC اینکوڈنگ سے پہلے، جو اسے آپ کے ویڈیو کا دوسرے شرکاء کو ملنے والے view سے زیادہ favourable بناتا ہے۔ وہ view میں براؤزر کی طرف سے لگائی گئی اسکیلنگ، کلر کنورژن یا کنسٹرینٹ پروسیسنگ شامل ہو سکتی ہے، اس لیے یہ خام سینسر آؤٹ پٹ نہیں۔ دوسرے شرکاء جو وصول کرتے ہیں وہ کمپریسڈ سٹریم ہے جسے WebRTC نے آپ کی مشین سے نکلنے سے پہلے مل سیکنڈز میں negotiate، re-encode، rate-limit اور ممکنہ طور پر downgrade کیا ہے۔

یہ اینکوڈنگ لیئر user interface سے غیر مرئی ہے اور normal operation کے دوران خاموش رہتی ہے۔ کال ونڈو میں کچھ بھی آپ کو نہیں بتاتا کہ یہ موجود ہے، کچھ بھی اس کے فیصلوں کی اطلاع نہیں دیتا، اور آپ کے پری ویو میں کچھ بھی ان کو reflect نہیں کرتا۔ ایک جانا پہچانا منظر: ایک user گھنٹوں کیمرا driver دوبارہ install کرتا ہے کیونکہ کال دھندلی تصویر دکھاتی ہے — صرف chrome://webrtc-internals کے ذریعے دریافت کرنے کے لیے کہ براؤزر بینڈوڈتھ estimation کی بنیاد پر 480p15 پر negotiate کر رہا تھا، کیمرا یا driver کی وجہ سے نہیں۔ یہ page بیان کرتا ہے کہ کیمرا سینسر اور آپ کے کال پارٹنر کی screen کے درمیان کیا ہوتا ہے، براؤزر خاموشی سے آپ کی کوالٹی کیوں کم کرتا ہے، اور — سب سے اہم — پری ویو پر بھروسہ کرنے کے بجائے اپنی مشین سے نکلنے والی اصل سٹریم کو کیسے ناپیں۔

آپ کا پری ویو آپ کو کیا نہیں دکھاتا

ویڈیو کالنگ ایک pipeline پر مبنی ہے جو بالکل آپ کے awareness کے باہر چلتی ہے۔ آپ جو ہر فریم بھیجتے ہیں وہ درج ذیل مراحل سے گزرتا ہے:

1. کیمرا سینسر ایک فریم capture کرتا ہے؛ براؤزر پھر اسے getUserMedia() کے ذریعے درخواست شدہ ریزولوشن اور فریم ریٹ پر ڈیلیور کرتا ہے، جس میں اسکیلنگ، کلر کنورژن اور کنسٹرینٹ پروسیسنگ شامل ہو سکتی ہے۔
2. براؤزر اس فریم کو getUserMedia() API کے ذریعے وصول کرتا ہے اور WebRTC engine کو دیتا ہے۔ آپ کا لوکل پری ویو اس stage سے فیڈ ہوتا ہے — اسی لیے یہ ہمیشہ perfect لگتا ہے، اس سے قطع نظر کہ اگلا کیا ہوتا ہے۔
3. WebRTC encoder فریم کو negotiate شدہ codec، ریزولوشن، فریم ریٹ اور بٹ ریٹ پر bitstream میں compress کرتا ہے۔
4. اینکوڈڈ فریم کو RTP packets میں تقسیم کیا جاتا ہے اور نیٹ ورک پر بھیجا جاتا ہے، عام طور پر media server کے ذریعے جو اسے سب کو relay کرتا ہے۔
5. ہر وصول کنندہ packets کو decode کر کے تصویر میں تبدیل کرتا ہے اور اپنی screen پر render کرتا ہے۔

آپ کا پری ویو pipeline میں stage دو پر tap کرتا ہے۔ یہ وہ فریم دکھاتا ہے جو کیمرا نے getUserMedia() کے ذریعے ڈیلیور کیا، WebRTC اینکوڈنگ سے پہلے۔ براؤزر اس stage پر اسکیلنگ، کلر کنورژن یا کنسٹرینٹ پروسیسنگ لاگو کر سکتا ہے، لیکن کوئی WebRTC کمپریشن نہیں لگائی جاتی۔ آپ کے کال پارٹنر جو سٹریم دیکھتے ہیں وہ stage تین سے نکلتی ہے۔ ان دو نکاتوں کے درمیان، encoder فیصلہ کرتا ہے کہ دنیا کیا وصول کرتی ہے، اور یہ فیصلہ ان حالات کی بنیاد پر کرتا ہے جو آپ کبھی نہیں دیکھتے۔

اینکوڈر خاموشی سے تین پیرامیٹرز negotiate کرتا ہے، اور ہر ایک بغیر کسی notification کے mid-call تبدیل ہو سکتا ہے:

• Resolution — اینکوڈڈ فریمز کی چوڑائی اور اونچائی، جو 1920×1080 سے 1280×720 یا 640×480 تک خود بخود گر سکتی ہے۔
• Frame rate — فی سیکنڈ کتنے فریمز اینکوڈنگ سے بچ جاتے ہیں، جو عام طور پر پہلے گرتی ہے (30 سے 15 یا اس سے کم) کیونکہ فریم ریٹ آدھا کرنے سے ڈیٹا ریٹ بغیر ریزولوشن تبدیل کیے آدھا ہو جاتا ہے — اگرچہ کچھ implementations codec اور پلیٹ فارمنگ پر منحصر ریزولوشن کم کر سکتی ہیں۔
• Bit rate — اینکوڈر کو فی سیکنڈ کتنے bits خرچ کرنے کی اجازت ہے، جو مجموعی کمپریشن level مقرر کرتا ہے۔

یہ تین اقدار دوسری طرف جو کچھ بھی دکھائی دیتا ہے اس کا تعین کرتی ہیں۔ کم بٹ ریٹ پر کمپریس شدہ 1080p تصویر soft اور smeared لگتی ہے۔ 30 fps کی سٹریم اچانک 10 fps پر چلتی ہوئی juddery اور non-naturalistic لگتی ہے۔ جب آپ سمجھ جاتے ہیں کہ پری ویو ان قدروں میں سے کچھ بھی رپورٹ نہیں کرتا، تو عشitable کیمرا کے ساتھ糟糕 کال کا mystery ختم ہو جاتا ہے۔

SDP آپ کے پہلے فریم بھیجنے سے پہلے negotiate کرتا ہے

Negotiation پہلے فریم بھیجنے سے پہلے شروع ہوتا ہے۔ جب آپ کال میں شامل ہوتے ہیں، پلیٹ فارم اور آپ کا براؤزر Session Description Protocol (SDP) offer اور answer کا تبادلہ کرتے ہیں۔ SDP ہر طرف کی supported codecs اور media capabilities کا اعلان کرتا ہے؛ اصل ریزولوشن اور فریم ریٹ پھر send اور receive parameters کے ذریعے مزید negotiate کیے جاتے ہیں اور betweenڈوڈتھ estimation کے ذریعے constrained ہوتے ہیں۔ غیر رسمی testing میں Chrome 125 پر Windows 10 (مئی 2024)، SDP answer میں پہلے VP9، پھر H.264، پھر VP8 offer کیا گیا؛ Safari 17 پر macOS 14 (اسی مدت)، H.264 پہلے آیا۔ یہ مشاہدات فی براؤزر ایک ہی مشین پر controlled نیٹ ورک حالات کے بغیر کیے گئے، اس لیے یہ موجود variation کو illustrate کرتے ہیں نہ کہ universal order define کرتے ہیں۔ اصل منتخب شدہ codec براؤزر، پلیٹ فارم، SDP parameters اور ہارڈویئر capabilities پر منحصر ہے۔ عام choices میں VP9، H.264، VP8 اور AV1 شامل ہیں، لیکن تمام پلیٹ فارمز پر کوئی single fixed preference order نہیں ہے۔

Codec selection صرف شروعات ہے۔ ایک بار کال live ہو جاتی ہے، دوسرا mechanism سنبھالتا ہے: betweenڈوڈتھ estimation۔ WebRTC مسلسل دونوں سمتوں میں نیٹ ورک path monitor کرتا ہے اور ایک congestion control algorithm چلاتا ہے — عام طور پر Google Congestion Control — جو rolling basis پر تین measurements کرتا ہے:

• Packet loss، جو receiver کی طرف سے RTCP feedback messages کے ذریعے رپورٹ کیا جاتا ہے۔
• Round-trip time، packet بھیجے جانے اور اس کی پہنچ کی تصدیق وصول کرنے کے درمیان تاخیر۔
• Throughput، وہ effective rate جس پر ڈیٹا دراصل کنکشن cross کرتا ہے۔

algorithm ان measurements کو ایک model میں فیڈ کرتا ہے جو اندازہ لگاتا ہے کہ نیٹ ورک فی الحال کتنا betweenڈوڈتھ carry کر سکتا ہے۔ وہ estimate target bit rate بن جاتی ہے جو encoder کو دی جاتی ہے، اور encoder اپنا آؤٹ پٹ اس کے مطابق ڈھالتا ہے۔ یہ loop مسلسل اور تیز ہے: جب estimate گرتی ہے، encoder ایک سیکنڈ کے کسر میں کم بٹ ریٹ پر re-encode کرتا ہے۔

Thresholds approximate ہیں اور استعمال شدہ مخصوص congestion control algorithm پر منحصر ہیں۔ تقریباً پانچ فیصد سے زیادہ مسلسل پیکٹ لاس target بٹ ریٹ میں کمی کا سبب بن سکتا ہے، لیکن exact behavior — rate کتنی گرتی ہے، ریزولوشن یا فریم ریٹ بھی تبدیل ہوتا ہے یا نہیں، اور کس لاس level پر — algorithm، codec اور پلیٹ فارم کے حساب سے مختلف ہوتا ہے۔ لاس فیصد سے مخصوص آؤٹ پٹ ریزولوشن تک کوئی universal mapping نہیں ہے۔ یہ فیصلے چلانے والا feedback loop (Google: WebRTC Congestion Control Whitepaper, 2019; RFC 8888: Congestion Control Feedback for RTP) میں define کیا گیا ہے۔ 30 fps پر 1080p سٹریم کو clean لگنے کے لیے تقریباً چار سے چھ میگابٹ فی سیکنڈ اپ لوڈ betweenڈوڈتھ درکار ہوتی ہے، اگرچہ یہ codec، اینکوڈنگ settings اور scene complexity پر منحصر ہے۔ اگر estimator یہ نتیجہ نکالتا ہے کہ صرف ایک میگابٹ دستیاب ہے، تو یہ سٹریم کو زبردستی نہیں گزرنے دیتا — یہ target گر دیتا ہے، اور encoder ریزولوشن 480p اور فریم ریٹ 15 fps پر کم کرنے سے جواب دیتا ہے۔ اگر estimate مزید گرتی ہے، تصویر دوبارہ خراب ہوتی ہے، یہاں تک کہ 320×240 talking head تک۔ ہر قدم deliberate ہے: هدف کال کو زندہ رکھنا اور آڈیو مستحکم رکھنا ہے، اور ویڈیو کوالٹی یہ حاصل کرنے کے لیے پہلے sacrificed ہونے والی چیز ہے۔

آپ کی سٹریم چھپائی ہوئی تین ناکامی کے patterns

پری ویو سٹریم کی اصل حالت کو تین recurring ناکامی کے patterns کے پیچھے چھپاتا ہے۔ ہر ایک کو اس کی علامات سے پہچاننا سیکھیں، کیونکہ ہر کیس کے لیے صحیح fix مختلف ہے۔ تینوں ایک tell share کرتے ہیں: پری ویو پورا وقت perfect رہتا ہے، کیونکہ یہ encoder سے پہلے sample کیا جاتا ہے۔ صرف thisکوڈڈ سٹریم — اور اس طرح دوسرے شرکاء کی screens — نقصان دکھاتی ہے۔

بٹ ریٹ ٹریپ

علامات: آپ کا پری ویو perfect ہے اور آپ کی مشین میں idle CPU ہے۔ دوسری طرف blurry، low-resolution تصویر دکھائی دیتی ہے جو کبھی sharp نہیں ہوتی، حتیٰ کہ pause کے دوران بھی۔ لوکل recordings بہترین لگتی ہیں؛ کال خراب لگتی ہے۔

تشخیص: براؤزر نے اندازہ لگایا ہے کہ نیٹ ورک full سٹریم carry نہیں کر سکتا اور اس نے بٹ ریٹ cap کر دی ہے، جس سے encoder ریزولوشن کم کرنے پر مجبور ہے۔ restriction آپ کی اپ لوڈ betweenڈوڈتھ یا media server کی relay capacity ہے، آپ کا کیمرا نہیں۔ Speed test چلائیں اور اپنی measured اپ لوڈ کو 1080p30 کے ضرورت مند چار سے چھ میگابٹ سے compare کریں۔ اگر آپ streaming، downloading یا syncing کرنے والے دیگر devices کے ساتھ connection share کرتے ہیں، تو وہ اسی budget کے لیے compete کر رہے ہیں۔

لاس تھریشولڈ

علامات: کال سے still images ٹھیک لگتی ہیں، لیکن کوئی بھی motion juddery اور robotic لگتی ہے۔ آڈیو smooth رہتی ہے جبکہ ویڈیو stutter کرتی ہے، اور ہر چند سیکنڈ میں مختصر freezes ہوتی ہیں اس سے پہلے کہ تصویر کم فریم ریٹ پر دوبارہ شروع ہو۔

تشخیص: پیکٹ لاس مسلسل پانچ فیصد threshold کو کراس کر رہا ہے، اس لیے congestion controller بار بار target بٹ ریٹ کم کر رہا ہے اور encoder اس کے مطابق فریمز drop کر رہا ہے۔ فریم ریٹ سب سے پہلے گرتی ہے کیونکہ یہ سستا ترین لیور ہے — 30 سے 15 fps تک کم کرنے سے ڈیٹا ریٹ بغیر ریزولوشن تبدیل کیے آدھا ہو جاتا ہے۔ Wi-Fi interference، marginal Ethernet cable، یا VPN کے لاس اور latancy شامل کرنے کے لیے چیک کریں۔ نیٹ ورک path ٹھیک ہونے تک ویڈیو مسلسل خراب ہوتی رہے گی۔

کی فریم فریز

علامات: شامل ہونے کے بعد پہلے دو سے پانچ سیکنڈ تک، یا screen share کرنے کے بعد، دوسری طرف frozen یا شدہ smeared تصویر دکھائی دیتی ہے۔ پھر تصویر focus میں آتی ہے اور اگلی بڑی scene تبدیلی تک normal behaving کرتی ہے۔

تشخیص: ویڈیو codecs دو فریم types بھیجتے ہیں۔ Keyframes پوری تصویر encode کرتے ہیں اور fixed interval پر ظاہر ہوتے ہیں — عام طور پر پلیٹ فارم اور کنفیگریشن کے حساب سے ہر ایک سے دس سیکنڈ میں۔ Delta frames صرف پچھلی فریم سے تبدیلیاں encode کرتے ہیں، جو انہیں چھوٹا بناتا ہے۔ اگر delta frame کا packet lost ہو جاتا ہے، تو receiver اس فریم کو reconstruct نہیں کر سکتا — یہ retransmission (NACK) request کر سکتا ہے، sender سے fresh keyframe (PLI یا FIR) مانگ سکتا ہے، یا انتظار کے دوران error conceal کر سکتا ہے۔ جب request کامیاب ہوتی ہے، recovery تیز ہے؛ جب نہیں ہوتی، تصویر اگلے scheduled keyframe کے آنے تک frozen رہتی ہے۔ وہ انتظار آپ کو جو freeze دکھائی دیتا ہے وہ یہی ہے۔ مختصر keyframe intervals تیزی سے recover کرتے ہیں لیکن بینڈوڈتھ خرچ کرتے ہیں؛ لمبے intervals efficient ہیں لیکن ہر loss مزید نمایاں بناتے ہیں۔ یہ malfunction نہیں ہے — یہ codec کا design کے مطابق کام کرنا ہے۔

getStats() سے اصل سٹریم ناپنا

اندازہ لگانا بند کریں۔ numbers افلاتنگ نہیں ہیں، لیکن true ہیں۔ WebRTC API ایک statistics interface expose کرتا ہے جو بالکل encoder کیا کر رہا ہے رپورٹ کرتا ہے، اور آپ کا کنٹرول والا ہر web page اپنا peer connection پڑھ سکتا ہے۔ RTCPeerConnection object پر getStats() call کریں، پھر وصول شدہ report میں اس outbound-rtp entry کو filter کریں جس کی kind video ہے۔ media-source اور outbound-rtp entries پر آپ کو اہم اقدار ملیں گی:

• framesPerSecond (media-source entry پر) — کیمرا encoder کو جو فریم ریٹ ڈیلیور کر رہا ہے۔ اگر 30 fps کیمرا پر یہ 30 سے نیچے ہے، تو capture پاتھ خود problem ہے — اکثر یہ ایک USB بینڈوڈتھ تنازع مسئلہ ہوتا ہے، جسے ہمارا USB بینڈوڈتھ تنازع گائیڈ تشخیص کرنے کا طریقہ بتاتا ہے۔
• framesPerSecond (outbound-rtp entry پر) — encoder دراصل جو فریم ریٹ پیدا کر رہا ہے۔ جب یہ input rate سے کم ہے، تو encoder فریمز drop کر رہا ہے۔
• frameWidth اور frameHeight (outbound-rtp entry پر) — thisکوڈڈ ریزولوشن۔ اپنی کال settings سے compare کریں؛ کوئی بھی فرق ایک silent downgrade ہے۔
• bytesSent (outbound-rtp entry پر) — total thisکوڈڈ ڈیٹا۔ ایک سیکنڈ فرق پر دو بار sample کریں اور difference × 8 حساب کریں تاکہ real bit rate ملے۔
• packetsSent اور packetsLost — نوٹ کریں کہ outbound-rtp entry پر packetsLost ہمیشہ populate نہیں ہوتا؛ loss ratio مزید قابل اعتماد طور پر remote-inbound-rtp entry سے پڑھی جاتی ہے، جو receiver perspective رپورٹ کرتی ہے۔
• currentRoundTripTime (candidate-pair entry پر) — نیٹ ورک delay۔ زیادہ RTT کے ساتھ loss congestion کی نشاندہی کرتا ہے۔

مختلف براؤزرز تھوڑا مختلف field names رپورٹ کر سکتے ہیں یا کچھ statistics مکمل طور پر چھوڑ سکتے ہیں، اس لیے available ہونے پر براؤزر کے WebRTC internals page کے ساتھ cross-check کریں۔

تشریح کے قواعد simple ہیں۔ اگر outbound-rtp framesPerSecond visibly طور پر media-source framesPerSecond سے نیچے ہے، تو encoder دباؤ میں فریمز shed کر رہا ہے۔ اگر frameWidth اور frameHeight آپ کی configured ریزولوشن سے نیچے ہیں، تو connection budget اسے carry نہیں کر سکتی۔ اگر bytesNet بٹ ریٹ میں translate ہوتی ہے جو codec کی اس ریزولوشن کی ضرورت سے کہیں کم ہے، تو تصویر crush ہو رہی ہے — اور پری ویو، جو encoder کو کبھی نہیں دیکھتا، پورا وقت ٹھیک لگتی رہے گی۔

آپ کو ان قدروں کو پڑھنے کے لیے code لکھنے کی ضرورت نہیں۔ Chrome اور Edge میں built-in statistics viewer chrome://webrtc-internals پر ships ہوتا ہے جو براؤزر میں ہر WebRTC connection capture کرتا ہے، بشمول وہ جو کال پلیٹ فارم نے بنائی۔ meeting میں شامل ہونے سے پہلے اسے کھولیں، record ہونے دیں، اور بعد میں ویڈیو sender کے لیے outbound-rtp entries inspect کریں۔ وہی فریم ریٹ، ریزولوشن، بٹ ریٹ اور loss numbers وہاں ہیں، ساتھ ہی timeline graph جو بالکل دکھاتی ہے کہ encoder نے اپنا آؤٹ پٹ کب تبدیل کیا۔ یہ real platform call پر downgrade کو act میں پکڑنے کا سب سے تیز way ہے۔

یہ measurement اس وقت چلائیں جب آپ کی اپنی کال background میں idle ہے، پھر busy meeting کے دوران دوبارہ، اور دونوں sets کے numbers compare کریں۔ ایک typical comparison: idle، outbound-rtp framesPerSecond 30 پڑھتا ہے؛ busy meeting کے دوران یہ 18 پر گر سکتا ہے جبکہ لوکل پری ویو پھر بھی 30 دکھاتا ہے۔ وہ comparison reveal کرتی ہے کہ آپ کا baseline نیٹ ورک adequate ہے یا نہیں اور کال کے دوران contention ہی downgrade کا trigger ہے یا نہیں۔ ہماری ویب کیم ٹیسٹ getUserMedia() کے ذریعے negotiate شدہ لوکل کیپچر ٹریک کا ریزولوشن اور فریم ریٹ دکھاتی ہے — آپ کا کیمرا براؤزر کو کیا ڈیلیور کر سکتا ہے اس کے لیے ایک useful baseline، لیکن آؤٹ باؤنڈ WebRTC thisکوڈڈ سٹریم کی measurement نہیں، جس کے لیے peer connection یا براؤزر کا WebRTC internals page درکار ہے۔

Zoom، Meet، Teams: تین مختلف کیمرے

وہی کیمرا، وہی laptop، اور وہی نیٹ ورک مختلف applications میں نمایاں طور پر مختلف results پیدا کر سکتے ہیں، کیونکہ ہر پلیٹ فارم براؤزر کی WebRTC implementation کے اوپر اپنی thisکوڈنگ policy لاگو کرتا ہے۔

• Zoom عام طور پر stability کو priority دیتا ہے۔ version، account type اور meeting settings کے حساب سے، یہ outgoing ریزولوشن cap کر سکتا ہے اور آڈیو اور screen share stable رکھنے کے لیے ویڈیو کوالٹی sacrifice کر سکتا ہے۔ 1080p-capable کیمرا Zoom پر 720p یا اس سے کم transmit کر سکتا ہے۔
• Google Meet measured betweenڈوڈتھ کے مطابق adapt کرنے کا رجحان رکھتا ہے، جلدی ریزولوشن کم کرتا ہے اور conditions بہتر ہونے پر جلدی restore کرتا ہے۔ اس کا behavior آپ کی actual نیٹ ورک state کو follow کرتا ہے، بہتر اور برے دونوں طرح۔
• Microsoft Teams اپنا thisکوڈنگ اور post-processing pipeline لاگو کرتا ہے۔ version اور meeting settings کے حساب سے، تصویر raw WebRTC negotiation سے آگے مزید compress ہو سکتی ہے۔
• Browser-native WebRTC، جو آپ کو bare web page میں ملتی ہے، negotiate شدہ سٹریم بغیر کسی platform policy کے بھیجتی ہے۔ یہ اس بات کے ground truth کے قریب ترین ہے کہ آپ کا ہارڈویئر اور نیٹ ورک plain WebRTC تحت کیا ڈیلیور کر سکتے ہیں۔ Platform policies version، account type اور meeting configuration کے حساب سے مختلف ہوتی ہیں، اس لیے انہیں fixed rules کے بجائے general tendencies کے طور پر treat کریں۔

عملی نتیجہ: Zoom کال کو Meet کال سے compare کرنا کیمرا ٹیسٹ نہیں ہے۔ یہ ہر پلیٹ فارم کی thisکوڈنگ decisions کا ٹیسٹ ہے۔ پہلے plain WebRTC page یا ویب کیم ٹیسٹ ٹول سے raw سٹریم measure کریں۔ اگر raw سٹریم clean ہے اور ایک پلیٹ فارم پھر بھی خراب لگتا ہے، تو پلیٹ فارم کی policy restriction ہے، اور کوئی ہارڈویئر upgrade اسے تبدیل نہیں کرے گا۔ جب platform call progress میں ہو، chrome://webrtc-internals آپ کو اس کے encoder decisions live دیکھنے دیتا ہے، تاکہ آپ دیکھ سکیں کہ downgrade پلیٹ فارم کی policy ہے یا نیٹ ورک کا behavior، بغیر کسی طرف کی self-report پر بھروسہ کیے۔

کلین سٹریم کے سات قدم

یہ steps الگ الگ اسباب isolate کرتی ہیں۔ آپ اس وقت رک سکتے ہیں جب سٹریم ٹھیک لگنے لگے — لیکن ہر تبدیلی سے پہلے اور بعد میں measure کریں تاکہ تصدیق ہو کہ fix نے واقعی numbers move کیے۔

1. پہلے measure کریں۔ chrome://webrtc-internals کھولیں یا اپنے peer connection پر getStats() استعمال کریں اور ریزولوشن، فریم ریٹ اور بٹ ریٹ record کریں۔ اگر raw سٹریم پہلے سے downgrade ہے، تو آپ کا کیمرا اور کنکشن problem ہے۔ اگر clean ہے، تو پلیٹ فارم ہے۔
2. بینڈوڈتھ چیک کریں۔ ویڈیو کالز کے لیے کم از کم 720p کے لیے 1 Mbps اپ لوڈ اور 1080p کے لیے تقریباً 4 Mbps درکار ہے۔ جس مشین سے call کرتے ہیں وہاں سے test کریں، کسی دوسرے device سے نہیں، اور نیٹ ورک پر دیگر traffic کے ساتھ retest کریں۔ اگر ہو سکے تو wired connection پر move کریں؛ Wi-Fi loss invisible downgrades کی سب سے عام وجہ ہے۔
3. روشنی ٹھیک کریں۔ اچھی روشتی ہوئی subject dark سے dramatically بہتر compress ہوتی ہے، کیونکہ encoder بٹ ریٹ noise کے بجائے visible تفصیل پر خرچ کرتا ہے۔ کھڑکی کی طرف look کریں یا soft light source استعمال کریں۔ یہ کچھ بھی نہیں costing اور اکثر کسی بھی setting سے بڑی improvement پیدا کرتا ہے۔
4. ویڈیو نائز ریڈکشن بند کریں جب آپ کا ماحول پہلے سے quiet اور well-lit ہو۔ کچھ پلیٹ فارمز کم روشنی والے مناظر میں aggressive denoising لاگو کرتے ہیں، جو thisکوڈڈ سٹریم میں باریک تفصیل کو نمایاں طور پر soften کر سکتا ہے۔ لوکل پری ویو یہ فرق نہیں دکھائے گا؛ صرف thisکوڈڈ سٹریم دکھائے گی۔ دستیاب controls کی تصدیق کے لیے مخصوص پلیٹ فارم settings چیک کریں۔
5. ورچوئل بیک گراؤنڈ بند کریں۔ Background segmentation مؤثر بٹ ریٹ میں overhead شامل کرتا ہے اور encoder سے GPU cycles consume کرتا ہے۔ مستقل روشنی کے ساتھ صاف حقیقی بیک گراؤنڈ کسی بھی virtual سے بہتر ہے۔
6. Codec چیک کریں۔ اگر آپ کا CPU handle کر سکتا ہے، VP9 فی بٹ بہترین کوالٹی ڈیلیور کرتا ہے؛ اگر آپ کو frame drops یا CPU spikes دکھائی دیتی ہیں، تو H.264 تیزی سے thisکوڈ کرتا ہے۔ کچھ پلیٹ فارمز settings میں codec preference expose کرتے ہیں۔
7. مختلف پلیٹ فارم ٹیسٹ کریں۔ اگر کوالٹی ایک service پر اچھی اور دوسرے پر خراب ہے، تو پلیٹ فارم کی thisکوڈنگ policy restriction ہے۔ اپنی expectations یا meeting tool کو اس کے مطابق adjust کریں — آپ کا ہارڈویئر fault نہیں ہے۔

نتیجہ

پری ویو آپ کے کیمرا کی local self-image ہے: یہ favororable view ہے کہ آپ کا کیمرا براؤزر کو کیا ڈیلیور کر سکتا ہے۔ سٹریم وہ ہے جو دنیا دراصل دیکھتی ہے — negotiate شدہ، compress شدہ، اور نیٹ ورک حالات اور platform policy کے ذریعے shaped۔ یہ اسی subject کی دو مختلف ویڈیوز ہیں، اور ان میں سے صرف ایک اس بات کے لیے اہم ہے کہ آپ کیسے perceive ہوتے ہیں۔ اگر آپ نے کبھی wonder کیا ہے کہ آپ کا کیمرا آپ کی screen پر بہترین کیوں لگتا ہے لیکن کال میں خراب کیوں لگتا ہے، تو آپ کے پاس اب جواب اور اس کو ناپنے کا ٹول ہے۔

chrome://webrtc-internals کھولیں۔ اپنی اگلی کال میں شامل ہوں۔ outbound-rtp entries watch کریں۔ اگر frameWidth یا framesPerSecond آپ کی کیمرا settings میں set کردہ سے کم ہیں، تو downgrade ہو رہی ہے۔ وجہ عام طور پر بینڈوڈتھ سے متعلق ہے — آپ کا براؤزر کتنا خرچ کرنے کی اجازت رکھتا ہے، اور آپ کا کنکشن دراصل وہ سٹریم carry کر سکتا ہے جو آپ سمجھتے ہیں کہ بھیج رہے ہیں — لیکن CPU load، encoder selection، platform policies اور constraint configuration بھی degradation میں contribute یا dominate کر سکتے ہیں۔