نشر واللعب
توجد وظيفتان رئيسيتان لتشغيل WebRTC على جانب الخادم في مجال بث الفيديو: النشر والتشغيل. في حالة النشر ، يتم التقاط دفق الفيديو من كاميرا الويب وينتقل من المستعرض إلى الخادم. في حالة التشغيل ، ينتقل الدفق في الاتجاه المعاكس ، من الخادم إلى المستعرض ، ويتم فك تشفيره وتشغيله في عنصر HTML5 <video> بالمتصفح على شاشة الجهاز.
UDP و TCP
يمكن نقل الفيديو عبر بروتوكولي النقل: TCP أو UDP. في حالة UDP ، تعمل التغذية المرتدة لـ NACK RTCP بشكل نشط ، حيث تحمل المعلومات حول الحزم المفقودة ، نظرًا لأنه من السهل جدًا اكتشاف تدهور قناة UDP ، فإن الأمر يرجع إلى حساب NACK (سلبية ACK) لتحديد الجودة. كلما زاد عدد تعليقات NACK و PLI (مؤشر فقد الصورة) ، زادت الخسائر الحقيقية ، وكلما انخفضت جودة القناة.
TCP دون NACK
في هذه المقالة ، سوف نركز أكثر على بروتوكول TCP. عند استخدام WebRTC عبر TCP ، لا يتم إرسال تعليقات NACK RTCP ، وحتى إذا تم إرسالها ، فإنها لا تعكس الصورة الحقيقية للخسائر ، ولا يبدو من الممكن تحديد جودة القناة بواسطة التعليقات. كما هو معروف ، TCP هو بروتوكول نقل مع التسليم المضمون. لهذا السبب ، في حالة تدهور جودة القناة ، سيتم إرسال باقي الحزم الموجودة في الشبكة على مستوى بروتوكول النقل. سيتم تسليمها عاجلاً أم آجلاً ، ولكن لن يتم إنشاء NACK لهذه الخسائر لأنه في الواقع لم تكن هناك خسائر. نتيجة لذلك ، ستصل الحزم إلى وجهتها مع تأخير. لن تتجمع الحزم المؤجلة ببساطة في إطارات الفيديو وسيتم التخلص منها بواسطة أداة إزالة الإغراق ، ونتيجة لذلك سيرى المستخدم صورة مثل هذه ، مليئة بالآثار:
سوف تظهر التقيمات أن كل شيء على ما يرام ، لكن الصورة ستحتوي على قطع أثرية. يمكنك أدناه رؤية لقطات لحركة مرور Wireshark والتي توضح سلوك البث الجاري نشره على قنوات TCP و UDP المضغوطة ، بالإضافة إلى لقطات من إحصائيات Google Chrome. في لقطات الشاشة ، يمكنك ملاحظة أنه في حالة TCP ، لا ينمو قياس NACK على عكس UDP ، على الرغم من أن حالة القناة سيئة للغاية.
TCP
UDP
لماذا الدفق عبر TCP على الإطلاق إذا كان هناك UDP
هذا سؤال معقول لطرحه. الجواب هو ، لدفع قرارات كبيرة من خلال القناة. على سبيل المثال ، في حالة VR (الواقع الافتراضي) قد تبدأ الدفق من 4k. لا يبدو أنه من الممكن دفع دفق بمثل هذا القرار ومع معدل بتات يبلغ حوالي 10 ميجابت في الثانية في قناة عادية دون خسائر ، يبث الخادم حزم UDP ويبدأ في الضياع في الشبكة في مجموعات ، ثم الباقي منهم يبدأ ليتم إرسالها ، وهلم جرا. كميات كبيرة من حزم الفيديو المهملة تفسد الفيديو ، والنتيجة النهائية هي أن الجودة تصبح رديئة للغاية. هذا هو السبب في استخدام WebRTC عبر TCP لتقديم الفيديو في شبكات للأغراض العامة وبدقة عالية ، مثل Full HD و 4k ، من أجل استبعاد خسائر حزم الشبكة على حساب الزيادة الطفيفة في زمن انتقال الاتصالات.
RTT لتحديد جودة القناة
لذلك ، لا يوجد مقياس لإخبارك بالتأكيد أن القناة في حالة سيئة للغاية. يحاول بعض المطورين الاعتماد على مقياس RTT ولكنه بعيد عن أن يكون قادرًا على العمل في جميع المتصفحات ، ولا يعطي نتائج دقيقة.
يمكنك العثور أدناه على توضيح لاعتماد جودة القناة على RTT وفقًا لمشروع callstat
الحل القائم على REMB
لقد قررنا اتباع نهج مختلف قليلاً لهذه المشكلة. هناك REMB يعمل على جانب الخادم ، الذي يحسب معدل البت الوارد لجميع التدفقات الواردة ، ويحسب انحرافه عن الوسط ، ويقترح أن المتصفح يقلل معدل البت في حالة تشتت كبير ، وإرسال أوامر REMB المتخصصة عبر RTCP بروتوكول. يتلقى المستعرض مثل هذه الرسالة ويقلل من معدل تشفير الفيديو للقيم الموصى بها: هذه هي الطريقة التي تعمل بها الحماية من الحمل الزائد للقناة وتدهور التدفق الوارد. بهذه الطريقة ، تم بالفعل تطبيق آلية حساب معدل البت على جانب الخادم. لقد تم تحقيق المتوسط وتحديد التشتت عبر مرشح Kalman. هذا يسمح للحصول على معدل البت الحالي في أي لحظة من الوقت بدقة عالية وتصفية أي انحرافات كبيرة.
سيكون لدى القارئ بالتأكيد هذا السؤال ، "كيف سيساعدني ذلك في معرفة معدل البت الذي يمكن أن يراه الخادم للدفق الوارد فيه؟" هذا سيسمح لك فقط بفهم أن هناك مقطع فيديو يأتي إلى الخادم مع قيمة معدل البت الذي كان من الممكن تحديد. لتقييم جودة القناة ، ستكون هناك حاجة إلى مكون إضافي.
معدل البت القادم ، ولماذا هو مهم
تظهر إحصائيات دفق WebRTC للنشر مع تحديد معدل بت دفق الفيديو من المتصفح. كما تقول نكتة قديمة ، يقول مسؤول الموقع عند التحقق من بندقيته الهجومية: "من جانبي ، طار الرصاص. المشكلات موجودة في جانبك ... "تتضمن فكرة التحقق من جودة القناة مقارنة اثنين من معدل البت: 1) معدل البت الذي أرسله المتصفح ، 2) معدل البت الذي تلقاه الخادم بالفعل.
يقوم المسؤول عن الموقع بإطلاق الرصاص ويحسب السرعة التي يطير بها على جانبه. يحسب الخادم السرعة التي يتم استلامها بها من جانبه. هناك مشارك آخر في هذا الحدث ، وهو TCP ، وهو بطل خارق يقع في الوسط بين المشرف والخادم ويمكنه إيقاف الرصاص بشكل عشوائي. على سبيل المثال ، يمكن إيقاف 10 رصاصات عشوائية من 100 لمدة 2 ثانية ، ثم السماح لهم بالطيران مرة أخرى. هذه هي المصفوفة التي نراها هنا.
على جانب المستعرض ، نأخذ معدل البت الحالي من إحصائيات WebRTC ، ثم ننسف الرسم البياني باستخدام مرشح Kalman في تطبيق JavaScript ، ونحصل على نسخة سلسة من معدل بت متصفح العميل في نهاية العملية. الآن لدينا كل ما نحتاج إليه تقريبًا: يخبرك معدل البت للعميل عن كيفية خروج حركة المرور من المتصفح ، ويبلغنا معدل البت في الخادم كيف يتم رؤية حركة المرور من قبل الخادم ، وبأي معدل بت يتم تلقيه. من الواضح أنه إذا بقي معدل البت للعميل مرتفعًا وبدأ معدل البت في الخادم يتقلص بالنسبة إلى معدل البت للعميل ، فهذا يعني أن جميع الرموز النقطية "لم تصل إلى الهدف" ولا يمكن للخادم رؤية جزء من حركة المرور فعليًا التي تم إرسالها إليها. على هذا الأساس ، يمكننا أن نستنتج أن هناك خطأ ما في القناة وأنه حان الوقت لتغيير لون المؤشر إلى اللون الأحمر.
وهناك المزيد
ترتبط الرسوم البيانية ولكنها تتغير قليلاً في الوقت بالنسبة لبعضها البعض. من أجل الترابط الكامل ، من الضروري مطابقة الرسوم البيانية مع الوقت لمقارنة معدل البت بين العميل والخادم في نفس الوقت مع البيانات التاريخية. يبدو عدم التزامن كالتالي:
وهذا ما يشبه الرسم البياني المتزامن مع الوقت.
دعونا اختباره
لدينا القليل من اليسار للقيام به ، علينا فقط اختباره. دعنا ننشر دفق فيديو ، وفتحه ، وننظر إلى الرسم البياني لمعدل البت المنشور: على جانب المتصفح وعلى جانب الخادم. الرسوم البيانية تظهر عمليا مباراة مثالية. وهذا هو اسم المؤشر ، الكمال.
ثم ، دعونا نبدأ في تلف القناة. للقيام بذلك ، يمكننا استخدام الأدوات المجانية التالية: winShaper لـ Windows أو Network Link Conditioner لـ MacOS. أنها تسمح لضغط القناة إلى قيمة محددة مسبقا. على سبيل المثال ، إذا علمنا أن تيارًا من 640 × 480 يمكن أن يصل إلى سرعة 1 ميغابت في الثانية ، فلنضغطها على 300 كيلو بايت. عند القيام بذلك ، يجب ألا ننسى أننا نعمل مع TCP. دعنا نتحقق من نتيجة اختبارنا: هناك علاقة عكسية في الرسوم البيانية ، والمؤشر ينزلق إلى BAD. في الواقع ، يواصل المستعرض إرسال البيانات ويزيد معدل البت في محاولة دفع جزء جديد من حركة المرور إلى الشبكة. تتراكم هذه البيانات في الشبكة في شكل عمليات إعادة إرسال وفشل في الوصول إلى الخادم ، ونتيجة لذلك يوضح الخادم صورة معكوسة ويقول إن معدل البت الذي يمكن أن يراه قد انخفض. في الواقع ، انها سيئة.
لقد أجرينا العديد من الاختبارات التي توضح التشغيل الصحيح للمؤشر . نتيجةً لذلك ، لدينا ميزة تجعل من الممكن إبلاغ المستخدم بشكل موثوق وفوري بأي مشكلات في القناة سواء بالنسبة للنشر واللعب المباشر (العمل وفقًا لنفس المبدأ). نعم ، كل هذه الضجة كانت لهذا المصباح الأخضر والأحمر ، PERFECT-BAD. لكن الممارسة تدل على أن هذا المؤشر مهم للغاية ، وغيابه ، إلى جانب الفشل في فهم الوضع الحالي ، يمكن أن يخلق مشاكل كبيرة للمستخدم العادي لخدمة بث الفيديو WebRTC.
الروابط
WCS 5.2 هو خادم وسائط متدفق لتطوير تطبيقات الويب والهاتف المحمول
ناشر ومشغل قناة مراقبة الجودة
REMB - مستقبلات الحد الأقصى لمعدل البت المستخدم للتحكم في عرض النطاق الترددي
NACK - اعتراف سلبي يستخدم لحزم التحكم المفقودة وإعادة الإرسال