מקור NDI יכול להיעדר מהרשימה, להופיע אך לא להיות מסוגל להתחבר, או להתחבר ללא תמונה או קול שימושיים. התחילו בתסמין שאתם רואים:
- המקור חסר: בדקו את השולח, הממשק ושיטת הגילוי.
- המקור מופיע, אין חיבור: בדקו את תעבורת המדיה, הפורטים והנתיב.
- מחובר, אך אין תמונה או אודיו: בדקו את המדיה שהתקבלה ואת המפענח.
השתמשו באותו שולח ומקבל לאורך הבדיקות. רשמו את שמות המקורות, גרסאות NDI, ממשקי הרשת והזמן של כל בדיקה, כדי שתוכלו להשוות את התוצאות.
כשמקור NDI חסר, הוכיחו קודם את הגילוי
ודאו שהיישום או ההתקן השולח פועל ושפלט ה-NDI שלו מופעל. לאחר מכן בדקו שהמקבל מחפש בממשק המיועד וששתי נקודות הקצה שייכות לקבוצת ה-NDI הצפויה. מקור שחסר ביישום אחד אך נראה בכלי אבחון NDI עשוי להצביע על בעיית יישום, runtime או תצורה, ולא על כשל גילוי כלל-רשתי.
כברירת מחדל, NDI משתמש ב-mDNS לגילוי ללא תצורה. כתובת ה-multicast של IPv4 היא 224.0.0.251 ב-UDP 5353, והיא מוגבלת לרשת LAN פיזית או לוגית אחת. ב-Windows, פרופיל רשת Public עלול למנוע את תגובות ה-mDNS שנדרשות ל-NDI; ברשתות דומיין מנוהלות, מנהל המערכת חייב לאפשר את תעבורת הגילוי. ראו את הפניה הרשמית של NDI ל-mDNS.
בסביבה מבודדת, מנותבת או עננית, בחרו תכנון גילוי מתועד במקום להניח ש-multicast יעבור בה. רשומת מארח ידנית יכולה לשאול מחשב מרוחק ב-TCP 5960, אך היא רק מסייעת למקבל למצוא את המקורות שעל אותו מחשב. היא אינה יוצרת קישוריות מדיה ואינה מוסיפה קיבולת רשת.
הגדירו Discovery Server בשולח ובמקבל
NDI Discovery Server הוא רישום מרכזי להתקנות שבהן mDNS אינו רצוי או אינו זמין. ברירת המחדל של המאזין היא TCP 5959, ואפשר לקשור את השירות לכתובת שנבחרה או להגדירו לפורט אחר. לקוחות חייבים להשתמש באותה כתובת שרת ופורט שהפריסה מיועדת להם.
הפרט החשוב תלוי בתפקיד. שולח שמוגדר עם Discovery Server אינו מפרסם באמצעות mDNS; שולח זה גלוי ל-finders ולמקבלים שהוגדרו עבור אותו שרת. finders ומקבלים יכולים גם להשתמש ב-mDNS עבור מכונות מקומיות שאינן מוגדרות עם Discovery Server. התייחסו לכך כהחלטת תכנון, ולא כמתג שמפעילים במארח אחד ושוכחים ממנו.
NDI 5 מתעד כתובות Discovery Server מופרדות בפסיקים עבור לקוחות נתמכים. בדקו את השולח, המקבל וגרסת ה-NDI המדויקים בעת אובדן שרת: יישומי receiver-listener חדשים יותר עשויים לדרוש לוגיקת לקוח שמזהה שרת כושל ומתחברת מחדש. סקירת Discovery Server והפניית התצורה שלו הם מקור האמת לגרסה המותקנת.
השתמשו בכלל הפורטים המתאים למצב NDI
הטבלה הבאה היא טבלה תפקודית אחת, ולא הרשאה לפתוח טווח בלתי מוגבל בין כל מארח. החילו את הכלל בכיוון, באזור ובמספר החיבורים שבהם משתמשים השולח והמקבל בפריסה. ודאו את גרסת ה-NDI המותקנת ואת מצב הקבלה הנבחר לפני יצירת כלל של הרשאה מזערית.
| פונקציה | כלל הפורט הרשמי | מה התוצאה מוכיחה |
|---|---|---|
| גילוי mDNS | UDP 5353; IPv4 multicast 224.0.0.251 | תעבורת גילוי קיימת באותה LAN, לא שהמדיה שמישה. |
| Discovery Server | TCP 5959 כברירת מחדל; ניתן להגדרה | לקוח יכול להגיע לנקודת הקצה של הרישום, לא שיש לו זרם. |
| שאילתת מארח ידנית | TCP 5960 | אפשר לשאול מארח מרוחק לגבי מקורות. |
| מדיית TCP בסיסית | TCP 5961 ומעלה; לפחות פורט אחד לכל חיבור | השתמשו בכך כשמצב החיבור הנבחר משתמש ב-TCP בסיסי. |
| NDI 5+ Reliable UDP | UDP 5960 ומעלה; משותף עם TCP, פורט אחד לכל תהליך NDI | שיתוף החיבורים משנה את הנחת הספירה. |
| קבלת Multi-TCP או UDP | TCP/UDP 6960 ומעלה; לפחות פורט אחד לכל חיבור | כלל מדיה בצד המקבל עבור מצב זה. |
| שליחת Multi-TCP, unicast UDP או multicast UDP | TCP/UDP 7960 ומעלה; לפחות פורט אחד לכל חיבור | כלל מדיה בצד השולח עבור מצב זה. |
התיעוד העדכני של NDI אומר שגרסאות 4.6 ואילך אינן משתמשות עוד בפורטים ארעיים. יש לצרף את הפניית הפורטים של NDI המלאה לכל שינוי בחומת אש.
בדקו תת-רשתות וממשקי רשת
ל-mDNS יש גבול LAN; ניתוב, ממסרי multicast והתנהגות 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 או את המשימה בהמשך הדרך שההפקה באמת זקוקה לה. בדקו את הפלט שלו בנפרד במקבל היעד; תוצאת גילוי היא קלט להחלטה זו, ולא מבחן הקבלה.
תעדו את התצורה העובדת
- מקור חסר: הוכיחו את פלט השולח, הקבוצה, כרטיס הרשת שנבחר ותצורת mDNS או Discovery Server.
- המקור מופיע, אין סשן: תעדו כתובת מקור, מצב תעבורה וכלל מדיה פעיל; בדקו את חומת האש והניתוב של נקודת הקצה בשני הכיוונים.
- סשן, אין פריימים שימושיים: בדקו מצב קבלה, קצב סיביות, נוכחות וידאו/אודיו, תאימות פענוח והפלט המוצג בפועל.
- לפני קבלה: חזרו על הנתיב המוצלח בממשקי הייצור ותעדו תצורה, שם מקור וראיות עבור ספר הנהלים.
השלבים הבאים
השתמשו ב-Cloud NDI כדי להגדיר את נתיב הגילוי והממשק המיועדים, ואז קראו את הפניית ההתקנים שהתגלו כאשר תהליך העבודה זקוק לבדיקת מלאי. השאירו את מבחן קבלת הייצור במקבל הסופי: תמונה מתקדמת, אודיו צפוי ונתיב הפלט שנבחר.
