اختبار بث الكاميرا — ما يراه الآخر

الصورة التي تراها في معاينة الكاميرا هي عرض التقاط محلي — تغذية الكاميرا كما تسلم عبر getUserMedia() — وليس مخرج المستشعر الخام. الصورة التي يراها مستلم مكالمة الفيديو هي بث مرمز بواسطة المتصفح تم التفاوض عليه وضغطه وربما تخفيض درجته بواسطة WebRTC. يشرح هذا الدليل كيف يعمل تفاوض ترميز WebRTC وكيفية استخدام getStats() لقياس معلمات البث الحقيقية وإصلاح أسباب فقدان الجودة.

تجلس في مكالمة فيديو وعرضك يظهر صورة 1080p حادة وجيدة الإضاءة. تبدو حاداً، الخلفية نظيفة، والتأطير صحيح. ثم يقول زميل إن الفيديو يتجمد ويبدو ضبابياً، وعندما يشاركون شاشتهم ترى نفسك كصورة مكعبة ذات حواف ناعمة كان من الممكن أن تنتجها كاميرا ويب رخيصة من عقد مضى. نفس الكاميرا. نفس الإضاءة. نفس الجهاز. صورة مختلفة.

ما تخطيه معظم أدلة مكالمات الفيديو: تلك الفجوة عادة ليست عطل جزء مادي أو عيب مستشعر — رغم أن درايفر سيء السلوك يمكن أحياناً أن يسببها أيضاً. إنها عادة الفرق بين ما تنتجه الكاميرا وما يرسله المتصفح فعلاً. معاينتك تتغذى من مسار الالتقاط المحلي — الإطار الذي أنتجته الكاميرا كما سلم عبر getUserMedia() — قبل ترميز WebRTC، مما يجعلها عرضاً أكثر تفاؤلاً لما يراه المشاركون الآخرون. قد يتضمن ذلك العرض أيضاً قياساً وتحويل ألوان ومعالجة قيود يطبقها المتصفح، فليس مخرج مستشعر خام. ما يستقبله المشاركون الآخرون هو بث مضغوط تم التفاوض عليه وإعادة ترميزه وتخفيض درجته بواسطة WebRTC في المللي ثواني قبل أن يغادر جهازك.

طبقة الترميز تلك غير مرئية من واجهة المستخدم وصامتة خلال التشغيل العادي. لا شيء في نافذة المكالمة يخبرك بوجودها، لا شيء يبلغ عن قراراتها، ولا شيء في معاينتك يعكسها. مشهد مألوف: مستخدم يقضي ساعات في إعادة تثبيت درايفر الكاميرا لأن مكالمة تظهر صورة ضبابية — ليكتشف عبر chrome://webrtc-internals أن المتصفح كان يفاوض بالهبوط إلى 480p15 بناءً على تقدير البيانات، لا بسبب الكاميرا أو الدرايفر. تشرح هذه الصفحة ما يحدث بين مستشعر الكاميرا وشاشة شريكك في المكالمة، لماذا يخفض المتصفح جودتك بهدوء، و—الأهم—كيف تقيس البث الفعلي الذي يغادر جهازك بدلاً من الوثوق بالمعاينة.

ما لا تظهره معاينتك

مكالمات الفيديو تقوم على خط أنابيب يعمل كلياً خارج وعيك. كل إطار ترسله يمر عبر المراحل التالية:

1. مستشعر الكاميرا يلتقط إطاراً؛ يسلمه المتصفح عبر getUserMedia() بالدقة ومعدل الإطارات المطلوبين، مما قد يتضمن قياساً وتحويل ألوان ومعالجة قيود.
2. المتصفح يتلقى ذلك الإطار عبر واجهة getUserMedia() ويسلمه لمحرك WebRTC. معاينتك المحلية تتغذى من هذه المرحلة — لهذا تبدو دائماً مثالية، بغض النظر عما يحدث بعد ذلك.
3. مرمز WebRTC يضغط الإطار إلى تيار بت باستخدام ترميز متفاوض عليه، بدقة متفاوض عليها ومعدل إطارات ومعدل بت.
4. الإطار المرمز يقسم إلى حزم RTP ويرسل عبر الشبكة، عادة عبر خادم وسائط يناوله للجميع.
5. كل مستقبل يفك ترميز الحزم إلى صورة ويعرضها على شاشته.

معاينتك تضغط على خط الأنابيب في المرحلة الثانية. تعرض الإطار الذي أنتجته الكاميرا كما سلم عبر getUserMedia()، قبل ترميز WebRTC. قد يطبق المتصفح قياساً وتحويل ألوان ومعالجة قيود في هذه المرحلة، لكن لا ضغط WebRTC يطبق. بث شريكك في المكالمة هو ما يخرج من المرحلة الثالثة. بين تلك النقطتين، يقرر المرمز ما يستقبله العالم، ويتخذ ذلك القرار بناءً على ظروف لا تراها أبداً.

يحاور الترميز بصمت ثلاث معلمات، وكل واحدة يمكن أن تتغير منتصف المكالمة دون أي إخطار:

• الدقة — عرض وارتفاع الإطارات المرمزة، التي يمكن أن تنخفض من 1920×1080 إلى 1280×720 أو 640×480 بمفردها.
• معدل الإطارات — كم إطاراً في الثانية ينجو من الترميز، الذي ينخفض عادة أولاً (من 30 إلى 15 أو أقل) لأن خفض معدل الإطارات للنصف يخفض معدل البيانات للنصف دون تغيير الدقة — رغم أن بعض التطبيقات قد تخفض الدقة بدلاً من ذلك.
• معدل البت — كم بت/ثانية يسمح للترميز بإنفاقه، الذي يضع مستوى الضغط الكلي.

هذه القيم الثلاث تحدد كل ما يراه الطرف الآخر. صورة 1080p مضغوطة إلى معدل بت منخفض تبدو ناعمة وممسوحة. بث 30 fps يفاجئك بأنه يعمل عند 10 fps يبدو متذبذباً وغير طبيعي. عندما تفهم أن المعاينة لا تبلغ عن أي من هذه القيم، يذوب لغز المكالمة السيئة بكاميرا ممتازة.

SDP يتفاوض قبل إرسال إطار

التفاوض يبدأ قبل الإطار الأول. عندما تنضم لمكالمة، المنصة ومتصفحك يتبادلان Session Description Protocol (SDP) عرضاً وجواباً. يعلن SDP عن الترميزات وقدرات الوسائط التي يدعمها كل طرف؛ الدقة ومعدل الإطارات الفعليان يفاوض عليهما لاحقاً عبر معلمات الإرسال والاستقبال ويقيدهما تقدير البيانات. اختيار الترميز هو البداية فقط. عندما تكون المكالمة حية، تقدير النطاق الترددي يتولى: يراقب WebRTC الشبكة ويشغل خوارزمية تحكم ازدحام تقيس:

• فقدان الحزم
• زمن الذهاب والإياب
• الإنتاجية

تغذي الخوارزمية هذه القياسات في نموذج يقدر كم بيانات يمكن للشبكة حملها حالياً. ذلك التقدير يصبح معدل بت مستهدف يسلم للترميز، ويكيف الترميز مخرجه ليناسب. الحلقة مستمرة وسريعة: عندما ينخفض التقدير، يعيد الترميز الترميز بمعدل بت أقل في جزء من ثانية.

القيم تقريبية وتعتمد على خوارزمية التحكم بالازدحام. فقدان حزم مستمر فوق حوالي خمسة بالمئة يمكن أن يطلق خفضاً في معدل البت المستهدف، لكن السلوك الدقيق يختلف. بث 1080p بـ 30 fps يحتاج عادة حوالي أربعة إلى ستة ميغابت في الثانية ليبدو نظيفاً. إذا قدّر المقدّر أن ميغابتاً واحدة متاحة، لا يحاول دفع البث عبرها — بل يخفض الهدف، ويستجيب الترميز بخفض الدقة إلى 480p ومعدل الإطارات إلى 15 fps. كل خطوة مدروسة: الهدف هو إبقاء المكالمة حية والصوت مستقراً، وجودة الفيديو أول ما يضحى به. (Google: WebRTC Congestion Control Whitepaper, 2019; RFC 8888: Congestion Control Feedback for RTP).

ثلاثة أنماط فشل يخفيها البث

المعاينة تخفي حالة البث الحقيقية وراء ثلاثة أنماط فشل متكررة. تعلم التعرف على كل واحد بأعراضه، لأن الإصلاح الصحيح يختلف لكل حالة. الثلاثة يشتركون في إشارة واحدة: المعاينة تبقى مثالية طوال الوقت، لأنها تُأخذ قبل المرمز. فقط البث المرمز — وبالتالي شاشات المشاركين الآخرين — تظهر الضرر.

فخ معدل البت

الأعراض: معاينتك مثالية وCPU خامل. الطرف الآخر يرى صورة ضبابية منخفضة الدقة لا تحدد أبداً. التسجيلات المحلية تبدو ممتازة؛ المكالمة تبدو سيئة. التشخيص: قدر المتصفح أن الشبكة لا تستطيع حمل البث الكامل وقيد معدل البت، مجبراً المرمز على تصغير الدقة. القيد هو عرض النطاق الترددي للرفع أو سعة تناول خادم الوسائط، لا كاميرتك. شغل اختبار سرعة وقارن رفعك المقاس مقابل الأربعة إلى ستة ميغابت التي يتطلبها 1080p30.

عتبة الفقدان

الأعراض: الصور الثابتة من المكالمة تبدو جيدة لكن الحركة متقطعة وروبوتية. الصوت يبقى سلساً بينما الفيديو يتلعثم، وتجميدات قصيرة تحدث كل بضع ثوانٍ قبل أن تستأنف الصورة بمعدل إطارات أقل. التشخيص: فقدان الحزم يتجاوز عتبة الخمسة بالمئة بشكل متقطع، فيكرر متحكم الازدحام خفض معدل البت المستهدف والمرمز يdrop الإطارات للمطابقة. معدل الإطارات ينخفض أولاً لأنه أرخص رافعة — الخفض من 30 إلى 15 fps يخفض معدل البيانات للنصف دون تغيير الدقة. افحص تداخل Wi-Fi أو كابل إيثرنت هامشي أو VPN يضيف فقداناً وكموناً.

تجميد الإطار المفتاحي

الأعراض: في أول ثانيتين إلى خمس ثوانٍ بعد انضمامك، أو بعد مشاركة شاشتك، الطرف الآخر يرى صورة متجمدة أو مسحوحة بشدة. ثم تنضبط الصورة وتعمل بشكل طبيعي حتى تغيير المشهد الكبير التالي. التشخيص: ترميز الفيديو يرسل نوعين من الإطارات. الإطارات المفتاحية ترمز الصورة كاملة وتظهر على فاصل ثابت — عادة كل واحدة إلى عشر ثوانٍ. إطارات دلتا ترمز فقط التغييرات منذ الإطار السابق، مما يجعلها ضئيلة. إذا ضاعت حزمة من إطار دلتا، لا يستطيع المستقبل إعادة بناء ذلك الإطار. عندما ينجح طلب، التعافي سريع؛ عندما لا ينجح، تبقى الصورة متجمدة حتى يصل الإطار المفتاحي المجدول التالي. ذلك الانتظار هو التجميد الذي تراه.

قياس البث الحقيقي عبر getStats()

توقف عن التخمين. الأرقام ليست متملقة، لكنها صادقة. تعرض واجهة WebRTC API واجهة إحصائيات تبلغ بالضبط ما يفعله المرمز، وأي صفحة ويب تتحكم فيها يمكنها قراءة اتصال نظيرها الخاص. اتصل بـ getStats() على كائن RTCPeerConnection، ثم رشح التقرير المرجع لإدخال outbound-rtp الذي kind فيه video. على إدخالات media-source و outbound-rtp ستجد القيم المهمة:

• framesPerSecond (على إدخال media-source) — معدل إطارات الكاميرا المسلّم للمرمز. إذا كان أقل من 30 على كاميرا 30 fps، مسار الالتقاط نفسه هو المشكلة — غالباً ما تكون مشكلة تنافس ناقل USB، وهو ما يشرح دليلنا لتنافس ناقل USB كيفية تشخيصه.
• framesPerSecond (على إدخال outbound-rtp) — معدل الإطارات الذي ينتجه المرمز فعلياً. عندما يكون أقل من معدل الإدخال، المرمز يdrop الإطارات.
• frameWidth و frameHeight (على إدخال outbound-rtp) — الدقة المرمزة. قارن ضد إعدادات مكالمتك؛ أي فرق هو خفض صامت.
• bytesSent (على إدخال outbound-rtp) — إجمالي البيانات المرمزة. عين مرتين بفارق ثانية واحسب الفرق × 8 للحصول على معدل البت الحقيقي.
• packetsSent و packetsLost — لاحظ أن packetsLost على إدخال outbound-rtp ليس دائماً مُعبأً؛ نسبة الفقدان تُقرأ بشكل أكثر موثوقية من إدخال remote-inbound-rtp.
• currentRoundTripTime (على إدخال candidate-pair) — تأخير الشبكة. RTT عالٍ مع فقدان يشير لازدحام.

قواعد التفسير بسيطة. إذا كان outbound-rtp framesPerSecond أقل بوضوح من media-source framesPerSecond، المرمز يتخلص من الإطارات تحت الضغط. إذا frameWidth و frameHeight أقل من الدقة التي تكوّنتها، ميزانية الاتصال لم تستطع حملها. إذا bytesSent يترجم إلى معدل بت أقل بكثير مما يتطلبه الترميز لتلك الدقة، الصورة تُسحق — والمعاينة، التي لا ترى المرمز أبداً، ستبدو جيدة طوال الوقت.

لا تحتاج كتابة كود لقراءة هذه القيم. Chrome وEdge يقدمان عارض إحصائيات مدمج عند chrome://webrtc-internals يلتقط كل اتصال WebRTC في المتصفح، بما في ذلك الذي أنشأته منصة مكالمة. افتحه قبل الانضمام لاجتماع، دعه يسجل، وافحص إدخالات outbound-rtp لمرسل الفيديو بعد ذلك.

شغل هذا القياس بينما مكالمتك خاملة في الخلفية، ثم مرة أخرى خلال اجتماع مزدحم، وقارن مجموعتي الأرقام. مقارنة نموذجية: خامل، outbound-rtp framesPerSecond يقرأ 30؛ خلال اجتماع مزدحم يمكن أن ينخفض إلى 18 بينما المعاينة المحلية لا تزال تظهر 30. تلك المقارنة تكشف ما إذا كانت شبكتك الأساسية كافية وما إذا كان التنافس خلال المكالمة هو ما يطلق الخفض. أداة webcam test تظهر دقة ومعدل إطارات مسار الالتقاط المحلي كما تفاوض عليه عبر getUserMedia() — أساس مفيد لما تستطيع كاميرتك تقديمه للمتصفح، لكن ليس قياساً للبث المرمز الصادر، الذي يتطلب اتصال نظير أو صفحة WebRTC internals للمتصفح.

Zoom وMeet وTeams: ثلاث كاميرات مختلفة

نفس الكاميرا، نفس الحاسوب المحمول، ونفس الشبكة يمكن أن تنتج نتائج مرئية مختلفة في تطبيقات مختلفة، لأن كل منصة تطبق سياسة ترميزها الخاصة فوق تطبيق WebRTC للمتصفح.

• Zoom يفضل الاستقرار. قد يحد الدقة ويضحي بجودة الفيديو للحفاظ على الصوت ومشاركة الشاشة مستقرين.
• Google Meet يتكيف مع البيانات المقاسة، مخفضاً الدقة مبكراً ومستعيداً إياها بسرعة عند التحسن.
• Microsoft Teams يطبق خط أنابيب ترميز ومعالجة لاحقة خاصاً به.
• WebRTC الأصلي للمتصفح يرسل البث المتفاوض عليه دون سياسة منصة فوقه. هو الأقرب للحقيقة الأساسية لما يستطيع عتادك وشبكتك تقديمه تحت WebRTC العادي.

النتيجة العملية: مقارنة مكالمة Zoom مقابل مكالمة Meet ليست اختبار كاميرا. هو اختبار قرارات ترميز كل منصة. قس البث الخام أولاً بصفحة WebRTC عادية أو أداة webcam test. إذا كان البث الخام نظيفاً ومنصة واحدة لا تزال تبدو سيئة، سياسة المنصة هي القيد، ولا ترقية عتاد ستغير ذلك.

سبع خطوات لبث نظيف

هذه الخطوات تعزل أسباباً متمايزة. يمكنك التوقف بمجرد ما يبدو البث صحيحاً — لكن قس قبل وبعد كل تغيير لتأكيد أن الإصلاح حرك الأرقام فعلاً.

1. قِس أولاً. افتح chrome://webrtc-internals أو استخدم getStats() على اتصال نظيرك وسجل الدقة ومعدل الإطارات ومعدل البت. إذا كان البث الخام مخفضاً بالفعل، كاميرتك واتصالك هما المشكلة. إذا كان نظيفاً، المنصة هي.
2. تحقق من البيانات. تحتاج 1 Mbps لـ720p و4 Mbps لـ1080p. اختبر من الجهاز الذي تتصل منه، وانتقل لاتصال سلكي إن أمكن؛ فقدان Wi-Fi هو السبب الأكثر شيوعاً للخفض غير المرئي.
3. أصلح الإضاءة. موضوع مضيء جيداً يضغط بشكل أفضل بكثير من موضوع مظلم، لأن المرمز ينفق معدل البت على تفاصيل مرئية لا ضوضاء.
4. عطل قمع ضوضاء الفيديو عندما بيئتك هادئة ومضيئة جيداً. بعض المنصات تطبق تنعيناً عدوانياً في المشاهد منخفضة الإضاءة، مما ينعم التفاصيل الدقيقة.
5. عطل الخلفية الافتراضية. فصل الخلفية يضيف عبئاً على معدل البت الفعال ويستهلك دورات GPU من المرمز. خلفية حقيقية نظيفة بإضاءة متسقة تتفوق على أي خلفية افتراضية.
6. تحقق من الترميز. VP9 يقدم أفضل جودة لكل بت؛ إذا رأيت إسقاط إطارات أو ارتفاع CPU، H.264 يرمز أسرع.
7. اختبر منصة مختلفة. إذا كانت الجودة جيدة على خدمة وضعيفة على أخرى، سياسة ترميز المنصة هي القيد. عدّل توقعاتك أو أداة اجتماعك.

الخلاصة

المعاينة هي الصورة الذاتية المحلية لكاميرتك: عرض مفاجئ لما تستطيع كاميرتك تقديمه للمتصفح. البث هو ما يراه العالم فعلاً — متفاوض عليه ومضغوط ومشكل بظروف الشبكة وسياسة المنصة. هما فيديوان مختلفان لنفس الموضوع، وفقط واحد منهما يهم لكيفية ظهورك. إذا تساءلت يوماً لماذا تبدو كاميرتك ممتازة على شاشتك لكن سيئة في المكالمة، لديك الآن الجواب والأداة لقياسه.

افتح chrome://webrtc-internals. انضم لمكالمتك القادمة. راقب إدخالات outbound-rtp. إذا كانت frameWidth أو framesPerSecond أقل من إعدادات كاميرتك، التخفيض يحدث. السبب عادة متعلق بالبيانات — ما يسمح لمتصفحك بإنفاقه، وما إذا كان اتصالك يستطيع فعلاً حمل البث الذي تظنك ترسله — لكن حمل CPU واختيار المرمز وسياسات المنصات يمكن أيضاً أن تساهم أو تسيطر على التدهور.