منافذ NDI والاكتشاف: استكشاف المصادر والفيديو المفقودين وإصلاحهما

قد يكون مصدر NDI غائباً من القائمة، أو ظاهراً من دون القدرة على الاتصال، أو متصلاً من دون صورة أو صوت قابلين للاستخدام. ابدأ بالعرض الذي تراه:

• المصدر مفقود: تحقّق من المُرسِل والواجهة وطريقة الاكتشاف.
• المصدر مدرج، ولا يوجد اتصال: تحقّق من نقل الوسائط والمنافذ والمسار.
• متصل، لكن لا صورة أو صوت: افحص الوسائط المستلمة ووحدة فك الترميز.

استخدم المُرسِل والمستقبِل نفسيهما خلال الفحوص. دوّن أسماء المصادر وإصدارات NDI وواجهات الشبكة ووقت كل اختبار، كي تستطيع مقارنة النتائج.

عند غياب مصدر NDI، أثبت الاكتشاف أولاً

أكّد أن تطبيق أو جهاز المُرسِل يعمل وأن خرج NDI فيه مفعّل. ثم تحقّق من أن المستقبِل يبحث على الواجهة المقصودة وأن نقطتي النهاية تنتميان إلى مجموعة NDI المتوقعة. قد تكون مشكلة المصدر الغائب في تطبيق واحد لكنه ظاهر في أداة تشخيص NDI مشكلة تطبيق أو runtime أو إعدادات، لا فشلاً في الاكتشاف على مستوى الشبكة كلها.

يستخدم NDI افتراضياً mDNS للاكتشاف من دون إعداد. عنوان البث المتعدد IPv4 له هو 224.0.0.251 على UDP 5353، وهو محدود بشبكة LAN مادية أو منطقية واحدة. في Windows، قد يمنع ملف تعريف الشبكة Public استجابات mDNS التي يحتاجها NDI؛ وفي شبكات النطاق المُدارة، يجب أن يسمح المسؤول بحركة الاكتشاف. راجع مرجع NDI الرسمي لـ mDNS.

بالنسبة إلى بيئة معزولة أو مُوجّهة أو سحابية، اختر تصميماً موثقاً للاكتشاف بدلاً من افتراض أن البث المتعدد سيعبرها. يستطيع إدخال مضيف يدوي الاستعلام عن جهاز بعيد عبر TCP 5960، لكنه يساعد المستقبِل فقط على العثور على المصادر على ذلك الجهاز. ولا يؤسس اتصال الوسائط ولا ينشئ سعة شبكية.

اضبط Discovery Server على المُرسِل والمستقبِل

NDI Discovery Server هو سجل مركزي للتثبيتات التي يكون فيها mDNS غير مرغوب فيه أو غير متاح. المستمع الافتراضي له هو TCP 5959، ويمكن ربط الخدمة بعنوان محدد أو ضبطها لمنفذ آخر. يجب أن تستخدم العملاء عنوان الخادم والمنفذ نفسيهما اللذين يقصدهما النشر.

التفصيل المهم خاص بالدور. فالمُرسِل المضبوط مع Discovery Server لا يعلن عبر mDNS؛ ويكون هذا المُرسِل مرئياً لأدوات العثور والمستقبِلات المضبوطة لذلك الخادم. ويمكن لأدوات العثور والمستقبِلات أيضاً استخدام mDNS للأجهزة المحلية غير المضبوطة مع Discovery Server. تعامل مع ذلك بوصفه اختياراً تصميمياً، لا مفتاح تبديل تطبقه على مضيف واحد ثم تنساه.

توثّق NDI 5 عناوين Discovery Server مفصولة بفواصل للعملاء المدعومين. اختبر المُرسِل والمستقبِل وإصدار NDI الدقيقين عند فقدان الخادم: قد تتطلب تطبيقات المستقبِل-المستمع الأحدث منطق عميل لاكتشاف الخادم الفاشل وإعادة الاتصال. إن نظرة عامة على Discovery Server ومرجع إعداداته هما المصدر الموثوق للإصدار المثبّت.

استخدم قاعدة المنفذ المطابقة لنمط NDI

الآتي جدول وظيفي واحد، وليس إذناً بالسماح بنطاق غير مقيّد بين كل مضيف. طبّق القاعدة في الاتجاه والمنطقة وعدد الاتصالات المستخدمة لدى المُرسِل والمستقبِل المنشورين. أكّد إصدار NDI المثبّت ونمط الاستقبال المحدد قبل وضع قاعدة أقل الصلاحيات.

تقول وثائق NDI الحالية إن الإصدارات 4.6 والأحدث لم تعد تستخدم المنافذ المؤقتة. يجب أن يرافق مرجع منافذ NDI الكامل أي تغيير في جدار الحماية.

تحقّق من الشبكات الفرعية وواجهات الشبكة

لـ mDNS حد شبكة LAN؛ ولا تجعل منه التوجيه ومرحلات البث المتعدد وسلوك VPN خدمة اكتشاف مُوجّهة عامة. استخدم Discovery Server أو أسلوب العنونة اليدوية الموثق للمنتج المشارك عندما يكون المصدر والمستقبِل على شبكات مضبوطة منفصلة.

على مضيف متعدد المنافذ، دوّن الواجهة التي تملك الاكتشاف والتي تحمل الوسائط. قد يجعل محول إدارة أو اتصال Wi-Fi أو VPN مصدراً يظهر من شبكة خاطئة أو يجعل الردود تخرج بمسار لا يستطيع المستقبِل استخدامه. امنح واجهة الوسائط عنونة ثابتة، وتجنب أسماء الأجهزة المكررة، واجعل تفضيل الواجهة حتمياً قبل الحدث.

المصدر مدرج لكن لا صورة أو صوت

يعني المصدر المدرج أن المستقبِل حصل على إعلان مصدر أو إدخال سجل. ولا يثبت أن النقل المحدد يمكن أن يفتح، أو أن مسار العودة مسموح، أو أن المستقبِل يستطيع فك ترميز الفيديو. افحص عنوان URL والمنفذ للمصدر النشط، وحالة الاتصال، ونمط الاستقبال، ووجود الفيديو، ووجود الصوت، والخرج المعروض.

يمكن لأداة NDI Discovery الحالية عرض المُرسِلات المسجّلة وعنوان/منفذ المصدر وبيانات مراقبة المستقبِل، بما فيها حالة الاتصال ونمط الاستقبال ووجود الفيديو أو الصوت. استخدم ذلك الدليل لاختيار الفحص التالي. يثبت اختبار TCP للمنفذ 5959 إمكانية الوصول إلى Discovery Server فقط؛ ولا يثبت جلسة وسائط NDI.

تحقّق مما إذا كان mDNS يصل إلى واجهة Linux هذه

sudo tcpdump -ni <media-interface> udp port 5353

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

تحقّق من إمكانية الوصول إلى Discovery Server من Windows

Test-NetConnection <discovery-server> -Port 5959

النتيجة المتوقعة: اتصال TCP ناجح بعنوان الخادم والمنفذ المضبوطين. هذا يؤكد مستمع TCP يمكن الوصول إليه. تحقّق من التسجيل وعضوية المجموعة وتسليم الوسائط في تطبيق NDI.

تحقّق من المصادر المكتشفة في Callaba

يوفر Callaba Cloud NDI للمشغّل مكاناً لضبط الاكتشاف والواجهات والمحولات، ويمكن لسير عمل الأجهزة المكتشفة فيه إظهار المخزون الحالي. يفيد ذلك في الفصل بين إدخال جهاز محفوظ ومصدر مكتشف حالياً بواسطة المثيل المحدد. تحقّق من المصدر المختار في المستقبِل النهائي وكذلك في المخزون.

بعد أن يصبح المصدر حديثاً ويُتحقق من مسار الوسائط، اضبط محول NDI أو المهمة اللاحقة التي يحتاجها الإنتاج فعلاً. افحص خرجه منفصلاً في المستقبِل الهدف؛ فنتيجة الاكتشاف مدخل لذلك القرار، وليست اختبار القبول.

سجّل الإعداد العامل

1. المصدر مفقود: أثبت خرج المُرسِل والمجموعة وبطاقة الشبكة المختارة وإعداد mDNS أو Discovery Server.
2. المصدر مدرج، لا جلسة: سجّل عنوان المصدر ونمط النقل وقاعدة الوسائط النشطة؛ وافحص جدار حماية نقطة النهاية والتوجيه في الاتجاهين.
3. جلسة، لا إطارات قابلة للاستخدام: افحص نمط الاستقبال ومعدل البت ووجود الفيديو/الصوت وتوافق فك الترميز والخرج المعروض فعلياً.
4. قبل القبول: كرر المسار الناجح على واجهات الإنتاج وسجّل الإعداد واسم المصدر والدليل في دليل التشغيل.

الخطوات التالية

استخدم Cloud NDI لضبط مسار الاكتشاف والواجهة المقصود، ثم اقرأ مرجع الأجهزة المكتشفة عندما يحتاج سير العمل إلى فحص المخزون. أبقِ اختبار قبول الإنتاج عند المستقبِل النهائي: صورة متحركة وصوت متوقع ومسار الخرج المختار.