Một nguồn NDI có thể không có trong danh sách, có tên nhưng không kết nối được, hoặc đã kết nối mà không có hình hay tiếng dùng được. Hãy bắt đầu từ triệu chứng:
- Thiếu nguồn: kiểm tra phía gửi, giao diện và phương thức khám phá.
- Nguồn đã có trong danh sách nhưng không kết nối: kiểm tra truyền media, cổng và tuyến.
- Đã kết nối nhưng không có hình hoặc tiếng: kiểm tra media nhận được và bộ giải mã.
Dùng cùng một phía gửi và nhận trong toàn bộ quá trình kiểm tra. Ghi lại tên nguồn, phiên bản NDI, giao diện mạng và thời điểm từng lần thử để so sánh kết quả.
Khi thiếu nguồn NDI, hãy chứng minh việc khám phá trước
Xác nhận ứng dụng hoặc thiết bị gửi đang chạy và đã bật đầu ra NDI. Sau đó kiểm tra phía nhận đang dùng đúng giao diện và hai đầu thuộc nhóm NDI dự kiến. Một nguồn không hiện trong một ứng dụng nhưng hiện trong công cụ chẩn đoán NDI có thể là vấn đề ứng dụng, runtime hoặc cấu hình, chứ không phải lỗi khám phá trên toàn mạng.
Mặc định, NDI dùng mDNS để khám phá không cần cấu hình. Địa chỉ multicast IPv4 của nó là 224.0.0.251 trên UDP 5353, và chỉ giới hạn trong một LAN vật lý hoặc logic. Trên Windows, hồ sơ mạng Public có thể chặn phản hồi mDNS mà NDI cần; trên mạng miền được quản lý, quản trị viên phải cho phép lưu lượng khám phá. Xem tài liệu mDNS NDI chính thức.
Với môi trường biệt lập, định tuyến hoặc đám mây, hãy chọn kiến trúc khám phá đã được tài liệu hóa thay vì giả định multicast sẽ đi qua. Một mục host thủ công có thể truy vấn máy từ xa trên TCP 5960, nhưng chỉ giúp phía nhận tìm nguồn trên máy đó. Nó không thiết lập kết nối media hay tạo thêm dung lượng mạng.
Cấu hình Discovery Server trên phía gửi và nhận
NDI Discovery Server là sổ đăng ký tập trung cho các hệ thống không muốn hoặc không thể dùng mDNS. Cổng lắng nghe mặc định là TCP 5959; dịch vụ có thể gắn với địa chỉ đã chọn hoặc cấu hình cổng khác. Các client phải dùng đúng địa chỉ và cổng máy chủ mà triển khai quy định.
Điểm quan trọng phụ thuộc vào vai trò. Một phía gửi đã cấu hình Discovery Server sẽ không quảng bá qua mDNS; nó chỉ hiện với finder và receiver cấu hình cho máy chủ đó. Finder và receiver vẫn có thể dùng mDNS cho máy cục bộ không cấu hình Discovery Server. Đây là lựa chọn thiết kế, không phải nút bật cho một máy rồi bỏ quên.
NDI 5 có tài liệu về các địa chỉ Discovery Server cách nhau bằng dấu phẩy cho client được hỗ trợ. Hãy thử đúng phía gửi, nhận và phiên bản NDI khi máy chủ mất kết nối: các triển khai receiver-listener mới hơn có thể cần logic client phát hiện máy chủ lỗi rồi kết nối lại. Tổng quan Discovery Server và tài liệu cấu hình là nguồn chuẩn cho phiên bản đã cài.
Dùng quy tắc cổng phù hợp với chế độ NDI
Bảng dưới đây theo chức năng, không phải cho phép mở một dải không giới hạn giữa mọi máy. Áp dụng quy tắc theo chiều, vùng mạng và số kết nối của phía gửi/nhận đang triển khai. Xác nhận phiên bản NDI đã cài và chế độ nhận đã chọn trước khi đặt quy tắc đặc quyền tối thiểu.
| Chức năng | Quy tắc cổng chính thức | Kết quả chứng minh điều gì |
|---|---|---|
| Khám phá mDNS | UDP 5353; IPv4 multicast 224.0.0.251 | Có lưu lượng khám phá trên LAN đó, không phải media dùng được. |
| Discovery Server | TCP 5959 mặc định; có thể cấu hình | Client đến được đầu cuối sổ đăng ký, không phải đã có luồng. |
| Truy vấn host thủ công | TCP 5960 | Có thể truy vấn nguồn từ host từ xa. |
| Media TCP cơ bản | TCP 5961 and up; at least one port per connection | Dùng khi chế độ kết nối được chọn dùng TCP cơ bản. |
| NDI 5+ Reliable UDP | UDP 5960 and up; shared with TCP, one port per NDI process | Chia sẻ kết nối làm thay đổi giả định về số lượng cổng. |
| Nhận Multi-TCP hoặc UDP | TCP/UDP 6960 and up; at least one port per connection | Quy tắc media phía nhận cho chế độ đó. |
| Gửi Multi-TCP, unicast UDP hoặc multicast UDP | TCP/UDP 7960 and up; at least one port per connection | Quy tắc media phía gửi cho chế độ đó. |
Tài liệu NDI hiện hành nói rằng bản 4.6 trở lên không còn dùng ephemeral ports. Cần tham chiếu tài liệu đầy đủ về cổng NDI trong mọi thay đổi firewall.
Kiểm tra subnet và các giao diện mạng
mDNS có ranh giới LAN; định tuyến, multicast relay và cách VPN hoạt động không biến nó thành dịch vụ khám phá được định tuyến chung. Dùng Discovery Server hoặc cách định địa chỉ thủ công có tài liệu của sản phẩm khi nguồn và phía nhận thuộc các mạng được kiểm soát khác nhau.
Trên máy nhiều card mạng, hãy ghi giao diện nào xử lý khám phá và giao diện nào mang media. Card quản trị, Wi-Fi hoặc VPN có thể khiến nguồn xuất hiện từ mạng sai hoặc phản hồi đi qua tuyến phía nhận không dùng được. Cấp địa chỉ ổn định cho giao diện media, tránh trùng tên máy và cố định ưu tiên giao diện trước sự kiện.
Nguồn có trong danh sách nhưng không có hình hoặc tiếng
Một nguồn được liệt kê chỉ có nghĩa phía nhận đã nhận quảng bá nguồn hoặc mục sổ đăng ký. Điều đó không chứng minh truyền tải đã chọn mở được, đường về được phép, hay phía nhận giải mã được video. Kiểm tra URL và cổng nguồn đang hoạt động, trạng thái kết nối, chế độ nhận, sự hiện diện video/âm thanh và đầu ra đã render.
Công cụ NDI Discovery hiện tại có thể hiển thị phía gửi đã đăng ký, địa chỉ/cổng nguồn và dữ liệu giám sát phía nhận gồm trạng thái kết nối, chế độ nhận, sự hiện diện video hoặc âm thanh. Dùng bằng chứng đó để chọn bước kiểm tra tiếp theo. Dò TCP tới cổng 5959 chỉ chứng minh có thể tới Discovery Server, không chứng minh phiên media NDI.
Kiểm tra mDNS có đến giao diện Linux này không
sudo tcpdump -ni <media-interface> udp port 5353Kết quả mong đợi: gói mDNS xuất hiện khi khám phá đang hoạt động trên giao diện đó. Các gói này xác nhận lưu lượng khám phá tại giao diện, không phải quyền truy cập vào các cổng media đã chọn. Chỉ chạy bắt gói và chẩn đoán firewall khi có quyền cần thiết trên mạng sản xuất đó.
Kiểm tra khả năng tới Discovery Server từ Windows
Test-NetConnection <discovery-server> -Port 5959Kết quả mong đợi: kết nối TCP thành công tới địa chỉ và cổng máy chủ đã cấu hình. Điều này xác nhận có TCP listener truy cập được. Hãy kiểm tra đăng ký, thành viên nhóm và phân phối media trong ứng dụng NDI.
Kiểm tra nguồn đã khám phá trong Callaba
Callaba Cloud NDI cho phép người vận hành cấu hình khám phá, giao diện và adapter; quy trình thiết bị đã khám phá có thể cho thấy danh mục hiện tại. Điều đó giúp phân biệt mục thiết bị đã lưu với nguồn mà instance được chọn đang khám phá. Hãy kiểm tra nguồn đã chọn ở phía nhận cuối cùng cũng như trong danh mục.
Khi nguồn là dữ liệu hiện tại và đường media đã được xác minh, hãy cấu hình adapter NDI hoặc công việc phía sau mà sản xuất thực sự cần. Kiểm tra đầu ra riêng tại phía nhận mục tiêu; kết quả khám phá là đầu vào cho quyết định đó, không phải kiểm tra nghiệm thu.
Ghi lại cấu hình hoạt động
- Thiếu nguồn: chứng minh đầu ra phía gửi, nhóm, NIC đã chọn và cấu hình mDNS hoặc Discovery Server.
- Nguồn có trong danh sách nhưng không có phiên: ghi địa chỉ nguồn, chế độ truyền tải và quy tắc media đang dùng; kiểm tra firewall và định tuyến hai chiều ở các đầu cuối.
- Có phiên nhưng không có khung dùng được: kiểm tra chế độ nhận, bitrate, sự hiện diện video/âm thanh, tương thích giải mã và đầu ra thực tế đã render.
- Trước khi nghiệm thu: lặp lại đường đi thành công trên giao diện sản xuất và ghi cấu hình, tên nguồn cùng bằng chứng vào runbook.
Các bước tiếp theo
Dùng Cloud NDI để cấu hình đường khám phá và giao diện dự kiến, rồi đọc tài liệu tham chiếu thiết bị đã khám phá khi quy trình cần kiểm tra danh mục. Giữ bài kiểm tra nghiệm thu sản xuất tại phía nhận cuối: hình chuyển động, âm thanh mong đợi và đường đầu ra đã chọn.
