نشر واللعب
توجد ميزتان WebRTC من جانب الخادم في دفق الفيديو: النشر والتشغيل. في حالة النشر ، يتم التقاط دفق الفيديو من كاميرا الويب وينتقل من المستعرض إلى الخادم. في حالة التشغيل ، ينتقل الدفق في الاتجاه المعاكس - من الخادم إلى المتصفح ، ويتم فك تشفيره وتشغيله في عنصر متصفح HTML5 <video> على شاشة الجهاز.
UDP و TCP
يمكن نقل الفيديو عبر بروتوكولي النقل: TCP أو UDP. في حالة UDP ، تعمل ملاحظات RTCP NACK بنشاط ، والتي تحمل معلومات حول الحزم المفقودة ، وبالتالي ، فإن تحديد تدهور قناة UDP هو مهمة بسيطة إلى حد ما ويقلل من حساب NACK (ACK سلبي) لتحديد الجودة. كلما زاد عدد تعليقات NACK و PLI (مؤشر فقدان الصورة) ، زادت الخسائر الحقيقية وأسوأ جودة القناة
TCP دون NACK
في هذه المقالة ، سنكون أكثر اهتمامًا ببروتوكول TCP. عند استخدام WebRTC عبر TCP ، لا يتم إرسال تعليقات NACK RTCP ، وإذا كانت كذلك ، فهي لا تعكس الصورة الحقيقية للخسائر ، ولا يمكن تحديد جودة القناة بواسطة التعليقات. كما تعلم ، بروتوكول TCP هو بروتوكول نقل مع تسليم مضمون. لهذا السبب ، في حالة تدهور القناة ، سيتم إرسال الحزم على الشبكة على مستوى بروتوكول النقل. سيتم تسليمها عاجلاً أم آجلاً ، ولكن لن يتم إنشاء NACK لهذه الخسائر ، لأنه لم تكن هناك خسائر في الواقع. الحزم سوف تصل في وقت متأخر في وقت متأخر. ببساطة لن يتم تجميع الحزم المتأخرة في إطارات الفيديو وسيتم إسقاطها بواسطة depacketizer ، ونتيجة لذلك سيرى المستخدم شيئًا كهذا مليئًا بالتحف:
على التقيمات ، كل شيء سيكون على ما يرام ، ولكن سيكون هناك القطع الأثرية في الصورة. فيما يلي لقطات شاشة لحركة مرور 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. يتلقى المستعرض مثل هذه الرسالة ويقلل من معدل بت مشفر الفيديو للقيم الموصى بها - هكذا تعمل الحماية من الحمل الزائد للقناة وتدهور تيار الإدخال. وبالتالي ، على جانب الخادم ، تم بالفعل تطبيق آلية لحساب معدل البت. يتم تنفيذ تحديد المتوسط والانتثار من خلال مرشح كالمان. يتيح لك ذلك إزالة معدل البت الحالي في أي وقت بدقة عالية وتصفية الانحرافات القوية.
من المحتمل أن يكون لدى القارئ سؤال - "ما الذي ستعطيه معرفة معدل البت الذي يراه الخادم على البث الوارد؟". سيعطي هذا تفهمًا بالضبط لما يدخله الفيديو مع معدل البت على الخادم ، وقد تم تحديد القيمة. لتقييم جودة القناة ، مطلوب مكون إضافي.
معدل البت السابق ولماذا هو مهم
تظهر إحصائيات دفق WebRTC للنشر مع تحديد معدل بت دفق الفيديو الذي يخرج المتصفح. كما هو الحال في نكتة ملتوية: المسؤول ، فحص الجهاز: "من جانبي ، طار الرصاص. المشاكل على جانبك .. ". تتمثل فكرة التحقق من جودة القناة في مقارنة معدلين للبت: 1) معدل البت الذي يرسله المتصفح 2) معدل البت الذي يتلقاه الخادم فعليًا.
المشرف يطلق الرصاص ويحسب سرعة رحيلهم في المنزل. يحسب الخادم السرعة التي يتم استلامها بها في المنزل. يوجد مشارك آخر في هذا الحدث ، TCP هو superhero موجود في الوسط بين المسؤول والخادم ويمكن أن يبطئ الرموز النقطية بشكل عشوائي. على سبيل المثال ، يمكنها إزالة 10 رصاصات عشوائية من مائة لمدة ثانيتين ، ثم السماح لها بالطيران مرة أخرى. هنا مثل هذه المصفوفة.
على جانب المستعرض ، نأخذ معدل البت الحالي من إحصائيات WebRTC ، ثم نملس الرسم البياني باستخدام مرشح Kalman في تطبيق JavaScript وعند الحصول على نسخة سلسة من معدل بت متصفح العميل. الآن لدينا كل ما نحتاجه تقريبًا: يخبرنا معدل البت للعميل كيف تترك حركة المرور المتصفح ، ويخبر معدل البت في الخادم كيف يرى الخادم حركة المرور هذه ومعدل البت الذي يتلقاه. من الواضح ، إذا ظل معدل البت للعميل مرتفعًا ، وبدأ معدل البت في الخادم في التراجع فيما يتعلق بالعميل ، وهذا يعني أنه لم يتم نقل جميع "الرصاص" وأن الخادم لا يرى فعليًا جزءًا من حركة المرور التي تم إرسالها إليه. بناءً على ذلك ، نستنتج أن هناك خطأ ما في القناة وأن الوقت قد حان لتحويل المؤشر إلى اللون الأحمر.
المزيد في المستقبل
ترتبط الرسوم البيانية ، ولكن تحولت قليلا في الوقت بالنسبة لبعضها البعض. للحصول على ارتباط كامل ، من الضروري دمج المخططات الزمنية من أجل مقارنة معدل البت بين العميل والخادم في نفس الوقت على البيانات التاريخية. يبدو desync شيء مثل هذا:
ويبدو وكأنه مخطط متزامن مع الوقت.
تجريب
القضية صغيرة ، لا يزال لاختبار. ننشر دفق الفيديو ، ونفتح ونراقب مخطط معدلات البت المنشورة: على جانب المتصفح وعلى جانب الخادم. وفقًا للرسوم البيانية ، نرى تطابقًا مثاليًا تقريبًا. يسمى المؤشر الكمال.
بعد ذلك ، نبدأ في إفساد القناة. للقيام بذلك ، يمكنك استخدام أدوات " winShaper " المجانية هذه على نظام Windows أو " Network Link Conditioner " على نظام MacOS. إنها تسمح لك بربط القناة بالقيمة المحددة. على سبيل المثال ، إذا علمنا أن تيار 640 × 480 يمكن أن يتسارع إلى 1 ميغابت في الثانية ، فقم بربطه إلى 300 كيلو بايت. في الوقت نفسه ، نتذكر أننا نعمل مع TCP. نحن نتحقق من نتيجة الاختبار - تظهر الرسوم البيانية علاقة عكسية ويقع المؤشر في BAD. في الواقع ، يواصل المستعرض إرسال البيانات ويزيد معدل البت ، في محاولة لدفع جزء جديد من حركة المرور إلى الشبكة. تستقر هذه البيانات على الشبكة في شكل إعادة إرسال ولا تصل إلى الخادم ، ونتيجة لذلك ، يعرض الخادم الصورة المعاكسة ويقول إن معدل البت الذي يراه قد انخفض. حقا سيء.
لقد أجرينا الكثير من الاختبارات التي توضح التشغيل الصحيح للمؤشر . والنتيجة هي ميزة تسمح لك بإبلاغ المستخدم من حيث النوعية والكفاءة بالمشاكل التي تحدث في القناة لنشر البث وللتشغيل (تعمل وفقًا لنفس المبدأ). نعم ، من أجل هذا المصباح PERFECT-BAD الأخضر والأحمر ، قمنا بتسييج هذه الحديقة بأكملها. لكن الممارسة تدل على أن هذا المؤشر مهم للغاية وأن غيابه وسوء فهمه للحالة الحالية يمكن أن يدمر حياة مستخدم عادي لخدمة بث الفيديو عبر WebRTC.
مراجع
WCS 5.2 - خادم وسائط لتطوير تطبيقات الويب والفيديو المحمولة
وثائق مراقبة جودة قناة WebRTC للنشر والتشغيل
REMB - إدارة معدل البت جانب الخادم
NACK - التحكم في الحزم المفقودة من جانب الخادم