تقارير مرسل RTCP، والارتعاش، وفقدان الحزم: قراءة حالة الدفق دون مشاهدة الفيديو

عندما يبحث المهندسون عن "ارتعاش RTSP"، أو "فقدان حزمة RTP"، أو "تقرير مرسل RTCP"، فإنهم عادة ما يحاولون الإجابة على سؤال عملي: "هل البث غير صحي، أم أن اللاعب يعاني فقط؟ تشغيل الفيديو هو أحد الأعراض المتأخرة. تظهر أدلة RTP وRTCP في وقت سابق ومن الأسهل الدفاع عنها في حالة الدعم." RTCP هو رفيق التحكم لـ RTP. يمكنه حمل تقارير المرسل وتقارير المستقبل وأعداد الحزم ومعلومات التوقيت وملاحظات الجودة. لا تكشف كل كاميرا عن سلوك RTCP الغني، ولا تقوم كل عملية نشر بإعادة توجيهها بشكل صحيح، ولكن عندما يكون RTCP موجودًا، فإنه يوفر سياقًا مهمًا لا يوفره التشغيل الأولي.

لماذا يهم RTCP في تشخيصات الكاميرا

يحمل RTP حزم الوسائط. يساعد RTCP في وصف حالة جلسة الوسائط. بالنسبة لبث كاميرا RTSP، يمكن أن تساعد أدلة RTCP في الإجابة على ما يلي:

• هل المرسل على قيد الحياة بعد "PLAY"؟
• كم عدد حزم RTP التي أبلغ عنها المرسل؟
• هل تتماشى الطوابع الزمنية لـ RTP مع توقيت ساعة الحائط؟
• هل تسليم الحزم ثابت أم متقطع؟
• هل هناك غضب واضح؟
• هل استمر RTP أثناء فشل فك تشفير الفيديو؟
• هل يتضمن مسار الوسائط RTCP على الإطلاق؟

إذا نجح التحكم في RTSP ووصل RTP، ولكن توقف الفيديو، فيمكن أن يساعد RTCP في فصل توقيت الشبكة عن جاهزية برنامج الترميز.

تقارير المرسل هي دليل التوقيت

يمكن لتقرير مرسل RTCP ربط الطابع الزمني لـ RTP بقيمة زمنية مطلقة على نمط NTP. تساعد هذه العلاقة أجهزة الاستقبال على مزامنة التدفقات والتفكير في سلوك الساعة. في عمليات التشخيص، قد تكون الحسابات الدقيقة أقل أهمية من وجود التقارير واتساقها.

ملاحظات مفيدة:

• يظهر تقرير المرسل بعد بدء تشغيل الوسائط
• يزداد عدد الحزم والثمانيات
• تعيين الطابع الزمني لـ RTP متسق
• الفاصل الزمني للتقرير معقول
• تتوقف التقارير عندما يتوقف RTP
• تستمر التقارير حتى في حالة فشل وحدة فك التشفير

إذا توقف RTCP مع RTP، فقد تتم مقاطعة مسار المرسل أو الوسائط. إذا استمر RTCP ولكن فشل فك تشفير الفيديو، فافحص أدلة الحمولة والترميز.

الارتعاش ليس مثل فقدان الحزمة

يعني Jitter وصول الحزم بتوقيت متغير. فقدان الحزمة يعني أن الحزم مفقودة. كلاهما يمكن أن يسبب تلعثمًا واضحًا، لكنهما يؤديان إلى إصلاحات مختلفة.

تُظهر أرقام تسلسل RTP الحزم المفقودة. تُظهر الطوابع الزمنية لـ RTP وأوقات الوصول اختلافًا في التوقيت. قد تضيف تقارير RTCP تعليقات على مستوى الجلسة. لا ينبغي للتقرير المناسب أن يقول فقط "شبكة سيئة". يجب أن يوضح ما إذا كانت المشكلة هي الخسارة أو الارتعاش أو تسليم الاندفاع أو RTCP المحظور أو حدود فك تشفير برنامج الترميز.

بالنسبة للكاميرات، يمكن أن يأتي الارتعاش من:

• تباين الوصلة الصاعدة لشبكة Wi-Fi
• التشفير الكاميرا مثقلة
• تأخير إعادة توجيه NVR
• مسار التبديل مزدحم
• مسار VPN أو WAN
• سلوك التخزين المؤقت من جانب العميل

يمكن أن يأتي فقدان الحزمة من:

• يسقط UDP
• سلوك جدار الحماية/NAT
• شبكة مثقلة
• الكاميرا ترسل الضغط العازلة
• قيود نقطة الالتقاط

الإصلاحات مختلفة.

يعد فقدان RTCP دليلًا أيضًا

تقوم بعض عمليات النشر بحظر RTCP حتى عند تدفق RTP. بعض الكاميرات لا ترسل RTCP مفيدًا. بعض العملاء لا يطلبون ذلك أو يتلقونه بشكل واضح. لا يعني فقدان RTCP أن البث معطل تلقائيًا، ولكن يجب تسجيله.

إذا تم التفاوض على RTP عبر UDP، فافحص كلاً من الوسائط وتحكم في حركة المرور المصاحبة. إذا تم استخدام RTSP عبر TCP مشذّر، فافحص بيانات تعريف القناة المشذّرة. يعد التقرير الذي يقول "RTP مرئي، RTCP غائب" أكثر فائدة من الحقل الفارغ.

حيث يناسب مفتش RTSP

تم تصميم RTSP Inspector لأدلة البروتوكول، وليس للعرض السلبي. ينتمي RTCP إلى نفس قصة أساليب RTSP، وSDP، واستمرارية تسلسل RTP، ونوع الحمولة، وبيانات تعريف برنامج الترميز، وتصدير التقارير.

بالنسبة لعمليات البحث التي تعتمد على RTCP، يجب أن يساعد RTSP Inspector في الإجابة على ما يلي:

• هل وصل RTP بعد "PLAY"؟
• هل ظهرت تقارير مرسل RTCP؟
• هل زاد عدد الحزم؟
• هل تتوافق فجوات الارتعاش أو التسلسل مع حالات الفشل الواضحة؟
• هل فشل جاهزية برنامج الترميز على الرغم من تسليم الوسائط؟
• هل غيّر وضع النقل الملف الصحي؟

وهذا يمنح بائع الكاميرات أو مهندس الشبكات أو مطور VMS نقطة انطلاق ملموسة. "تلعثم الدفق" هو ​​أحد الأعراض. "زادت فجوات تسلسل RTP والارتعاش بعد اللعب بينما ظل التحكم في RTSP على قيد الحياة" دليل على ذلك.