แหล่งสัญญาณ NDI อาจไม่ปรากฏในรายการ ปรากฏแต่เชื่อมต่อไม่ได้ หรือเชื่อมต่อแล้วแต่ไม่มีภาพหรือเสียงที่ใช้งานได้ เริ่มจากอาการที่พบ:
- ไม่พบแหล่งสัญญาณ: ตรวจสอบผู้ส่ง อินเทอร์เฟซ และวิธีค้นหา
- มีชื่อแหล่งสัญญาณ แต่เชื่อมต่อไม่ได้: ตรวจสอบการส่งสื่อ พอร์ต และเส้นทาง
- เชื่อมต่อแล้ว แต่ไม่มีภาพหรือเสียง: ตรวจสอบสื่อที่รับมาและตัวถอดรหัส
ใช้ผู้ส่งและผู้รับคู่เดิมตลอดการตรวจสอบ จดชื่อแหล่งสัญญาณ เวอร์ชัน NDI อินเทอร์เฟซเครือข่าย และเวลาของแต่ละการทดสอบเพื่อเปรียบเทียบผลได้
เมื่อไม่พบแหล่งสัญญาณ NDI ให้พิสูจน์การค้นหาก่อน
ยืนยันว่าแอปพลิเคชันหรืออุปกรณ์ผู้ส่งกำลังทำงานและเปิดเอาต์พุต NDI แล้ว จากนั้นตรวจสอบว่าผู้รับกำลังมองหาอินเทอร์เฟซที่ตั้งใจใช้ และทั้งสองปลายทางอยู่ในกลุ่ม NDI ที่คาดไว้ แหล่งสัญญาณที่ไม่เห็นในแอปหนึ่ง แต่มองเห็นในเครื่องมือวินิจฉัย NDI อาจเป็นปัญหาที่แอปพลิเคชัน รันไทม์ หรือการกำหนดค่า ไม่ใช่ความล้มเหลวของการค้นหาทั้งเครือข่าย
โดยปริยาย NDI ใช้ mDNS สำหรับการค้นหาแบบไม่ต้องกำหนดค่า ที่อยู่ multicast IPv4 คือ 224.0.0.251 บน UDP 5353 และจำกัดอยู่ใน LAN ทางกายภาพหรือตรรกะเดียว บน Windows โปรไฟล์เครือข่ายแบบสาธารณะอาจป้องกันการตอบกลับ mDNS ที่ NDI ต้องใช้ได้ ส่วนเครือข่ายโดเมนที่มีการจัดการ ผู้ดูแลต้องอนุญาตทราฟฟิกการค้นหา ดู เอกสารอ้างอิง NDI mDNS อย่างเป็นทางการ
สำหรับสภาพแวดล้อมที่แยกจากกัน มีการ route หรืออยู่บนคลาวด์ ให้เลือกรูปแบบการค้นหาที่มีเอกสารรองรับ แทนการคาดหวังว่า multicast จะข้ามไปได้เอง รายการโฮสต์แบบกำหนดเองสามารถสอบถามเครื่องระยะไกลผ่าน TCP 5960 ได้ แต่ช่วยเพียงให้ผู้รับพบแหล่งสัญญาณบนเครื่องนั้น ไม่ได้สร้างการเชื่อมต่อสื่อหรือเพิ่มความจุเครือข่าย
กำหนดค่า Discovery Server บนผู้ส่งและผู้รับ
NDI Discovery Server คือรีจิสทรีส่วนกลางสำหรับการติดตั้งที่ไม่ต้องการหรือใช้ mDNS ไม่ได้ โดยค่าเริ่มต้นจะรับฟังที่ TCP 5959 และสามารถผูกบริการกับที่อยู่ที่เลือกหรือกำหนดพอร์ตอื่นได้ ไคลเอนต์ต้องใช้ที่อยู่และพอร์ตของเซิร์ฟเวอร์เดียวกับที่การติดตั้งกำหนดไว้
จุดสำคัญขึ้นอยู่กับบทบาท ผู้ส่งที่ตั้งค่า Discovery Server จะไม่ประกาศผ่าน mDNS ผู้ส่งนั้นจึงมองเห็นได้เฉพาะ finder และ receiver ที่ตั้งค่าสำหรับเซิร์ฟเวอร์เดียวกัน Finder และ receiver ยังใช้ mDNS เพื่อหาเครื่องในเครือข่ายท้องถิ่นที่ไม่ได้ตั้งค่า Discovery Server ได้ ให้ถือว่านี่เป็นการตัดสินใจด้านการออกแบบ ไม่ใช่สวิตช์ที่เปิดเพียงเครื่องเดียวแล้วจบ
NDI 5 ระบุว่าลูกค้าที่รองรับสามารถใช้ที่อยู่ Discovery Server หลายรายการคั่นด้วยจุลภาคได้ ทดสอบผู้ส่ง ผู้รับ และเวอร์ชัน NDI ที่ใช้จริงเมื่อเซิร์ฟเวอร์ขาดหาย: implementation แบบ receiver-listener ที่ใหม่กว่าอาจต้องให้ตรรกะไคลเอนต์ตรวจพบเซิร์ฟเวอร์ล้มเหลวแล้วเชื่อมต่อใหม่ ภาพรวม Discovery Server และ เอกสารอ้างอิงการกำหนดค่า คือแหล่งอ้างอิงสำหรับเวอร์ชันที่ติดตั้ง
ใช้กฎพอร์ตที่ตรงกับโหมด NDI
ตารางต่อไปนี้เป็นตารางตามหน้าที่ ไม่ใช่อนุญาตให้เปิดช่วงพอร์ตแบบไม่จำกัดระหว่างทุกโฮสต์ ใช้กฎตามทิศทาง โซน และจำนวนการเชื่อมต่อของผู้ส่งและผู้รับที่ใช้งานจริง ยืนยันเวอร์ชัน NDI ที่ติดตั้งและโหมดรับที่เลือกก่อนสร้างกฎ least-privilege
| หน้าที่ | กฎพอร์ตทางการ | สิ่งที่ผลลัพธ์ยืนยัน |
|---|---|---|
| การค้นหา mDNS | UDP 5353; IPv4 multicast 224.0.0.251 | มีทราฟฟิกค้นหาบน LAN นั้น ไม่ได้ยืนยันว่าสื่อใช้งานได้ |
| Discovery Server | TCP 5959 โดยปริยาย; กำหนดค่าได้ | ไคลเอนต์เข้าถึงปลายทางรีจิสทรีได้ ไม่ได้ยืนยันว่ามีสตรีม |
| การสอบถามโฮสต์ด้วยตนเอง | TCP 5960 | สามารถสอบถามแหล่งสัญญาณจากโฮสต์ระยะไกลได้ |
| สื่อ TCP พื้นฐาน | TCP 5961 and up; at least one port per connection | ใช้เมื่อโหมดการเชื่อมต่อที่เลือกใช้ TCP พื้นฐาน |
| NDI 5+ Reliable UDP | UDP 5960 and up; shared with TCP, one port per NDI process | การแชร์การเชื่อมต่อทำให้สมมติฐานจำนวนพอร์ตเปลี่ยนไป |
| การรับแบบ Multi-TCP หรือ UDP | TCP/UDP 6960 and up; at least one port per connection | กฎสื่อฝั่งผู้รับสำหรับโหมดนั้น |
| การส่งแบบ Multi-TCP, unicast UDP หรือ multicast UDP | TCP/UDP 7960 and up; at least one port per connection | กฎสื่อฝั่งผู้ส่งสำหรับโหมดนั้น |
เอกสาร NDI ปัจจุบันระบุว่าเวอร์ชัน 4.6 และใหม่กว่าไม่ใช้ ephemeral ports อีกต่อไป ควรอ้างอิง เอกสารพอร์ต NDI ฉบับเต็ม ทุกครั้งที่เปลี่ยนกฎไฟร์วอลล์
ตรวจสอบ subnet และอินเทอร์เฟซเครือข่าย
mDNS มีขอบเขตอยู่ที่ LAN; การ route, multicast relay และพฤติกรรม VPN ไม่ได้ทำให้มันเป็นบริการค้นหาแบบ routed ทั่วไป ใช้ Discovery Server หรือวิธีกำหนดที่อยู่ด้วยตนเองที่ผลิตภัณฑ์นั้นมีเอกสารรองรับ เมื่อแหล่งสัญญาณและผู้รับอยู่บนเครือข่ายควบคุมคนละส่วน
บนโฮสต์ที่มีหลายอินเทอร์เฟซ ให้บันทึกว่าอินเทอร์เฟซใดรับผิดชอบการค้นหาและอินเทอร์เฟซใดส่งสื่อ อะแดปเตอร์จัดการ การเชื่อมต่อ Wi-Fi หรือ VPN อาจทำให้แหล่งสัญญาณปรากฏจากเครือข่ายผิด หรือทำให้การตอบกลับออกไปตามเส้นทางที่ผู้รับใช้ไม่ได้ กำหนดที่อยู่ของอินเทอร์เฟซสื่อให้คงที่ หลีกเลี่ยงชื่อเครื่องซ้ำ และกำหนดลำดับความสำคัญของอินเทอร์เฟซให้แน่นอนก่อนงาน
มีชื่อแหล่งสัญญาณ แต่ไม่มีภาพหรือเสียง
แหล่งสัญญาณที่อยู่ในรายการหมายความว่าผู้รับได้รับประกาศแหล่งสัญญาณหรือรายการรีจิสทรี ไม่ได้พิสูจน์ว่า transport ที่เลือกเปิดได้ เส้นทางขากลับได้รับอนุญาต หรือผู้รับถอดรหัสวิดีโอได้ ตรวจสอบ URL และพอร์ตของแหล่งสัญญาณที่ใช้งาน สถานะการเชื่อมต่อ โหมดรับ การมีอยู่ของวิดีโอและเสียง รวมถึงเอาต์พุตที่แสดงจริง
เครื่องมือ NDI Discovery รุ่นปัจจุบันแสดงผู้ส่งที่ลงทะเบียน ที่อยู่/พอร์ตของแหล่งสัญญาณ และข้อมูลติดตามผู้รับ รวมถึงสถานะการเชื่อมต่อ โหมดรับ และการมีวิดีโอหรือเสียง ใช้ข้อมูลนี้เลือกการตรวจสอบถัดไป การทดสอบ TCP ไปที่พอร์ต 5959 ยืนยันเพียงว่าเข้าถึง Discovery Server ได้ ไม่ได้ยืนยันเซสชันสื่อ NDI
ตรวจสอบว่า mDNS มาถึงอินเทอร์เฟซ Linux นี้หรือไม่
sudo tcpdump -ni <media-interface> udp port 5353ผลที่คาดหวัง: เห็นแพ็กเก็ต mDNS ขณะการค้นหาทำงานบนอินเทอร์เฟซนั้น แพ็กเก็ตเหล่านี้ยืนยันทราฟฟิกการค้นหาที่อินเทอร์เฟซนี้ ไม่ใช่การเข้าถึงพอร์ตสื่อที่เลือก ทำ packet capture และวินิจฉัยไฟร์วอลล์โดยมีสิทธิ์อนุญาตตามที่เครือข่ายใช้งานจริงกำหนดเท่านั้น
ตรวจสอบการเข้าถึง Discovery Server จาก Windows
Test-NetConnection <discovery-server> -Port 5959ผลที่คาดหวัง: เชื่อมต่อ TCP ไปยังที่อยู่และพอร์ตเซิร์ฟเวอร์ที่ตั้งค่าไว้สำเร็จ ซึ่งยืนยันว่ามี TCP listener ที่เข้าถึงได้ ตรวจสอบการลงทะเบียน การเป็นสมาชิกกลุ่ม และการส่งสื่อในแอปพลิเคชัน NDI
ตรวจสอบแหล่งสัญญาณที่ค้นพบใน Callaba
Callaba Cloud NDI ให้ผู้ปฏิบัติงานกำหนดค่าการค้นหา อินเทอร์เฟซ และอะแดปเตอร์ได้ และเวิร์กโฟลว์อุปกรณ์ที่ค้นพบจะแสดงรายการปัจจุบันได้ จึงช่วยแยกรายการอุปกรณ์ที่บันทึกไว้จากแหล่งสัญญาณที่ instance ที่เลือกค้นพบอยู่ในขณะนั้น ตรวจสอบแหล่งสัญญาณที่เลือกที่ผู้รับปลายทางด้วย ไม่ใช่เฉพาะในรายการ
เมื่อแหล่งสัญญาณเป็นข้อมูลปัจจุบันและยืนยันเส้นทางสื่อแล้ว ให้กำหนดค่า NDI adapter หรืองานปลายทางที่งานผลิตต้องใช้จริง ตรวจสอบเอาต์พุตแยกต่างหากที่ผู้รับเป้าหมาย; ผลการค้นหาเป็นข้อมูลประกอบการตัดสินใจ ไม่ใช่การทดสอบการยอมรับ
บันทึกการกำหนดค่าที่ใช้งานได้
- ไม่พบแหล่งสัญญาณ: ยืนยันเอาต์พุตผู้ส่ง กลุ่ม NIC ที่เลือก และการตั้งค่า mDNS หรือ Discovery Server
- มีชื่อแหล่งสัญญาณ แต่ไม่มีเซสชัน: บันทึกที่อยู่แหล่งสัญญาณ โหมด transport และกฎสื่อที่ใช้งาน; ตรวจสอบไฟร์วอลล์และ routing ของปลายทางทั้งสองทิศทาง
- มีเซสชัน แต่ไม่มีเฟรมที่ใช้ได้: ตรวจสอบโหมดรับ bitrate การมีวิดีโอ/เสียง ความเข้ากันได้ของการถอดรหัส และเอาต์พุตที่แสดงจริง
- ก่อนยอมรับงาน: ทำซ้ำเส้นทางที่สำเร็จบนอินเทอร์เฟซใช้งานจริง แล้วบันทึกการกำหนดค่า ชื่อแหล่งสัญญาณ และหลักฐานไว้ใน runbook
ขั้นตอนถัดไป
ใช้ Cloud NDI เพื่อกำหนดค่าเส้นทางการค้นหาและอินเทอร์เฟซที่ต้องการ จากนั้นอ่าน เอกสารอ้างอิงอุปกรณ์ที่ค้นพบ เมื่อเวิร์กโฟลว์ต้องตรวจสอบรายการอุปกรณ์ ให้คงการทดสอบยอมรับของงานผลิตไว้ที่ผู้รับปลายทาง: ภาพเคลื่อนไหว เสียงตามคาด และเส้นทางเอาต์พุตที่เลือก
