Cài đặt trình phát luồng Splayer UDP cho giao thức truyền phát của Bộ thu COFDM Vcan1776-RX

Cài đặt trình phát Luồng UDP trên bộ phát và thu video không dây COFDM HDMI

Trình phát luồng UDP là giải pháp tốt nhất cho bộ mã hóa video analog CVBS có độ trễ thấp nhất. Bộ thu video không dây COFDM Phần mềm mặc định Vcan1776-RX hỗ trợ trình phát RTSP. Một số khách hàng cần sử dụng giao thức UDP.

Địa chỉ IP và số cổng có thể được cấu hình trên trang web, http://192.168.0.215 (mặc định)

1. Sau khi nâng cấp firmware, đầu nhận sẽ khôi phục các thông số mặc định của nhà sản xuất (tần số trung tâm: 320MHz, băng thông không dây: 6MHz, địa chỉ IP cổng mạng: 192.168.0.215), khách hàng cần sửa đổi tần số trung tâm và băng thông thông qua Công cụ bảng cấu hình tham số, và Máy phát tiết kiệm liên tục.

2. Khách hàng truy cập máy chủ web của người nhận thông qua trang web (HTTP://192.168.0.215), và sửa đổi địa chỉ IP của chính nó cũng như cài đặt địa chỉ IP của đầu PC Windows được kết nối với bộ thu:

Ghi chú: Trong số đó, IP cục bộ là IP riêng của người nhận, và IP từ xa là ip cuối của PC Windows đang kết nối. Khách hàng có thể cấu hình nó theo tình hình thực tế của mình. Lưu ý rằng việc sửa đổi sẽ chỉ có hiệu lực sau khi khởi động lại máy thu.

Tải xuống trình phát UDP người chơi

3. Tải xuống trình phát UDP người chơi.
   • Splayer_v4.2_2020.6.6
   • https://drive.google.com/file/d/1ihzUhfnx2Wo3zLO8UAs1aUQeLswonJD-/view?usp=sharing
   • Splayer_v4.3_2022.10.22
   • https://drive.google.com/file/d/1PQc-LZ55qGnjeMsjkHYSloHfY3NEUsGH/view?usp=drive_link
   • Splayer_v4.3.1_2024.4.16
   • https://drive.google.com/file/d/1uv7GqP8P4r6qGOWJ5gYn0b8bZ4ptL8H6/view?usp=drive_link
   • Splayer_QT_V1.0 cho Win10 hoặc Win11
   • https://drive.google.com/file/d/1VAegQjd-PmIL2XbJf7K8dnujMxhoIuhd/view?usp=drive_link
   • Splayer_QT_V1.1.1 cho Win10 hoặc Win11
   • https://drive.google.com/file/d/1YMr2xxurGnbIBjFihc7f77afrdbOcc6l/view?usp=drive_link
   • Splayer_QT_V2.0
   • https://drive.google.com/file/d/1sASbARCL1lXAIsVKqkmEObRGPREbaSES/view?usp=drive_link
4. Mở trình phát Splayer trên PC Windows, nhấp vào nút cài đặt ở góc dưới bên phải, và trang cài đặt sẽ bật lên:

Ghi chú:

1. Có thể thấy số cổng Port được đặt thành 1234, được mã hóa cứng bởi chương trình phát trực tuyến UDP của máy thu và không thể sửa đổi;
2. Ở cột Giải mã, định cấu hình theo thuộc tính luồng video hiện tại, chẳng hạn như cấu hình luồng video có độ trễ thấp H264 như trên;

4. Sau khi thiết lập và nhấn vào “Xác nhận” nút để lưu các thông số, nhấp vào nút phát ở góc dưới bên trái. Sau khi PC Windows nhận được luồng đẩy UDP, nó sẽ giải mã và phát ngay lập tức.

Cài đặt trình phát luồng UDP ở trên phù hợp với kiểu máy bên dưới.

Nó hỗ trợ trình phát Linux VLC như thế nào? Phát luồng có độ trễ thấp trong Linux?

Câu hỏi: Bây giờ luồng UDP không phát với trình phát VLC. Tôi cần phát luồng UDP này trong Linux và tôi cố gắng hiểu chi tiết về luồng này. Bất kỳ tập lệnh hoặc phím hoặc những thứ khác?

Tôi muốn tạo trình phát của riêng mình trong Linux và tôi muốn hiểu chi tiết về luồng video UDP này từ bộ giải điều chế.

Nếu đó là luồng video UDP thông thường, sau đó hỏi tại sao nó không chơi với studio VLC hoặc OBS.

Trả lời: Đối với model Vcan1726-RX, Chúng tôi có hai phần sụn cho tùy chọn, Phần sụn đầu tiên dành cho trình phát RTSP hỗ trợ trình phát VLC, nhưng một số khách hàng đề cập rằng nó có độ trễ dài, vì vậy chúng tôi đã tạo phần sụn thứ hai, UDP phát sóng tại Splayer, hỗ trợ độ trễ thấp hơn.

Luồng âm thanh và video UDP này là định dạng tùy chỉnh của chúng tôi, nên VLC không thể giải thích được. Nếu khách hàng của bạn muốn mở trình phát của riêng họ (dưới Linux), hiện tại có hai lựa chọn:

1. Cập nhật quyền truy cập luồng RTSP mặc định (firmware đầu tiên cho máy nghe nhạc RTSP)
2. Chúng tôi cung cấp thư viện và quy trình DEMUX tương ứng (chúng ta cần hiểu môi trường Linux của khách hàng để biên dịch tệp thư viện phù hợp)
3. Đây là “Thư viện và quy trình DEMUX” được viết bởi các kỹ sư của chúng tôi trên Ubuntu 14.04 64hệ thống bit

Loại thứ hai quá khó đối với khách hàng bình thường, và chúng tôi không biết khả năng phát triển của trình phát của chính khách hàng của bạn.

Bởi vì một số khách hàng gặp phải vấn đề về độ trễ thấp ở trình phát VLC của hệ điều hành Windows, bất kể chúng tôi đã thử nghiệm ở đây như thế nào, chúng tôi không tìm thấy vấn đề này. Lúc đó, bạn đã sử dụng Windows để kiểm tra. Có lẽ nếu nó được đổi thành Linux, sẽ không có vấn đề phát trực tuyến RTSP. Vui lòng thử kiểm tra mẫu Vcan1726 với phiên bản firmware đầu tiên trên Linux. Có lẽ đây không phải là vấn đề trên hệ điều hành Linux.

Câu hỏi: Bạn có thể xây dựng hình ảnh docker cho ứng dụng này không? Cổng nào được sử dụng cho luồng đến, và một cổng khác cho luồng đi với một số codec được sử dụng rộng rãi (h264)?

Splayer và UDP Stream Player là gì?

SPlayer là trình phát đa phương tiện hỗ trợ nhiều định dạng video khác nhau, bao gồm cả phát trực tuyến UDP.

Truyền phát UDP là phương thức gửi dữ liệu video qua internet bằng Giao thức gói dữ liệu người dùng (UDP), đây là một giao thức nhanh và đơn giản, không đảm bảo việc phân phối hoặc thứ tự của các gói.

Truyền phát UDP có thể được sử dụng để phát video trực tiếp hoặc truyền video có độ trễ thấp, nhưng nó cũng có thể bị mất gói hoặc hỏng.

Theo kết quả tìm kiếm trên web, SPlayer có thể phát luồng UDP bằng cách làm theo các bước sau:

• Mở SPlayer và nhấp vào “Mở URL” nút ở góc trên bên phải.
• Nhập URL của luồng UDP ở định dạng udp://@ip: hải cảng, trong đó ip là địa chỉ IP của máy chủ và cổng là số cổng của luồng. Ví dụ, udp://@224.0.0.1:1234.
• Bấm vào “ĐƯỢC RỒI” và đợi luồng tải.

Splayer hoạt động tốt như thế nào cho Win10?

Câu hỏi: Chúng tôi không thể khởi động Splayer 4.2 and 4.3 dưới Windows 10. Bạn có thể cung cấp cho chúng tôi phiên bản chính xác của Splayer dành cho Windows không 10 and 11?

4.2 bắt đầu và kết thúc vào lúc này. 4.3 bắt đầu với thông báo lỗi.

Tên ứng dụng bị lỗi: Splayer.exe, phiên bản: 1.0.0.1, dấu thời gian: 0x646d83e2
Tên module bị lỗi: dvb_demux.dll, phiên bản: 1.0.0.1, dấu thời gian: 0x5fe5bdbf
Mã ngoại lệ: 0xc0000005
Bù lỗi: 0x0001484a
Id quá trình bị lỗi: 0x3888
Lỗi thời gian bắt đầu ứng dụng: 0x01da1164b89c78eb
Đường dẫn ứng dụng bị lỗi: C:\Users\admin\Downloads\Splayer_v4.3_2022.10.22\Splayer.exe
Đường dẫn mô-đun bị lỗi: C:\Users\admin\Downloads\Splayer_v4.3_2022.10.22\dvb_demux.dll
Id báo cáo: 4af19407-045e-48e5-a0f7-86fc90c6b3d3
Tên đầy đủ của gói bị lỗi:
ID ứng dụng liên quan đến gói bị lỗi:

Trả lời: Vui lòng thử sử dụng Splayer_qt_v1.0.zip của chúng tôi (103.5Mb).

Nhận xét: Phiên bản mới của SPlayer hoạt động tốt tại chỗ có vấn đề với Win 10! Cảm ơn!

Câu hỏi: Chúng tôi nhận thấy độ trễ thời gian tăng lên khi phát video từ chương trình Reciver by Splayer (luồng UDP).

Nếu nói chi tiết – Bộ thu kết nối trực tiếp bằng cáp ethernet với PC. PC và máy thu nằm trong cùng một mạng cục bộ. Khi chúng tôi khởi động Splayer, độ trễ thời gian là bình thường và số lượng chính xác hiển thị cho chúng tôi 330 mili giây, nhiều hơn một chút so với đầu ra HDMI mà chúng tôi đã quan sát thấy về 270 mili giây. Nó tốt. Nhưng nếu chúng ta đợi vài phút mà không có bất kỳ thay đổi nào ở nơi làm việc, chúng ta sẽ quan sát thấy độ trễ thời gian tăng liên tục, đạt đến mức 1-1,5 giây không được chấp nhận trong ứng dụng của khách hàng.
Hôm qua mình đã test trên Win 10, và Win11 trên các PC khác nhau với cách tắt phức tạp Win Brandmauer với Splayer qt (phiên bản cuối cùng từ bạn), và Splayer 4.3 (phiên bản cũ). Tôi lặp lại vấn đề này mỗi lần trong bất kỳ cấu hình nào.
Xin hãy giúp tôi khắc phục vấn đề này. Chúng tôi cần độ trễ thời gian liên tục kể từ khi chơi Splayer, có thể không nhiều hơn 350 mili giây.

Trả lời: Một vấn đề như vậy không nên xảy ra, bởi vì trình phát không có bộ nhớ đệm ở chế độ có độ trễ thấp, và độ trễ hoàn toàn phụ thuộc vào khả năng giải mã của PC. Các kỹ sư sẽ thiết lập môi trường và thử nghiệm vào thứ Hai tuần sau.

Một điểm nữa là yêu cầu khách hàng kiểm tra cài đặt tốc độ làm mới màn hình máy tính xách tay của họ. Ví dụ, nếu máy ảnh đầu vào 1080p60, thì tốc độ làm mới màn hình laptop của khách hàng cũng phải là 60Hz. Nếu không thì, màn hình hiển thị sẽ quá chậm, điều này cũng sẽ gây ra tắc nghẽn dữ liệu và gây ra sự chậm trễ.

Người chơi Slayer có độ trễ lớn, giải mã chậm hoặc hiển thị chậm, tất cả là do PC gây ra.

Mã hóa camera HDMI Giải mã bộ thu HDMI, xuất ra màn hình, và kiểm tra độ trễ phát lại trên máy tính của trình phát Splayer

Chúng tôi không tìm thấy vấn đề bạn đề cập.

Có thể thấy màn hình trình phát Splayer hiện tại và đầu ra HDMI của đầu thu đều nhất quán, và độ trễ giữa chúng là rất thấp.

Bạn có thể vui lòng hỏi khách hàng, độ phân giải và tốc độ khung hình của đầu vào máy ảnh là bao nhiêu? Giả sử camera của khách hàng là 1080p60, bạn cũng có thể thực hiện hai bước sau để khắc phục sự cố thêm:

1. Hãy để khách hàng thay đổi camera ở tốc độ khung hình thấp hơn để thử nghiệm, chẳng hạn như 1080p50/30;
2. Bạn có thể đặt tham số phân đoạn mã hóa để cho phép mã hóa khung hình xuống. Ví dụ, gửi lệnh ATSO0,30_ qua cổng tham số, và đầu ra mã hóa 1080p30 để thử nghiệm.

Ghi chú:

1. Splayer được phát triển đặc biệt cho giao thức phát trực tuyến tùy chỉnh/độc quyền của chúng tôi và hiện không hỗ trợ phân tích cú pháp hoặc phát lại các giao thức MPEG-TS tiêu chuẩn.
2. Splayer hiện chỉ khả dụng trên Windows. Phiên bản Linux và Android chưa được phát triển và không được hỗ trợ ở giai đoạn này.
3. Ngoài ra, không phải giao thức mpeg-ts làm tăng độ trễ. Ngay cả khi nó được chuyển sang giao thức tùy chỉnh của chúng tôi, độ trễ sẽ không giảm (giao thức tùy chỉnh của chúng tôi chủ yếu thực hiện kiểm tra CRC trên tất cả các gói dữ liệu, trong khi giao thức mpeg-ts thì không, đó là sự khác biệt lớn nhất giữa các giao thức). Tác động lớn nhất đến độ trễ là quá trình xử lý giải mã và hiển thị video trong trình phát. Trình phát Splayer của chúng tôi sẽ được tối ưu hóa cho các tình huống ứng dụng truyền hình ảnh.
4. Ngay cả khi khách hàng nhận được thư viện demux của chúng tôi và trích xuất các luồng âm thanh và video, nó vẫn phải tự giải mã và hiển thị video. Khách hàng bình thường này không có khả năng này. Hầu hết khách hàng sẽ chỉ sử dụng trình phát nguồn mở (chẳng hạn như dựa trên gstreamer), và độ trễ video của những trình phát nguồn mở này sẽ không tốt. Nếu bạn muốn độ trễ video tốt, về cơ bản bạn phải phát triển trình phát của riêng mình.
5. Nếu khách hàng khăng khăng đòi thư viện demux và nói rằng anh ta có khả năng xử lý việc giải mã và phát lại video tiếp theo, Tôi cũng có thể hợp tác với bạn (nhưng chúng tôi chỉ cung cấp thư viện demux và các quy trình trong Linux/android, và không cung cấp hỗ trợ liên quan đến giải mã và hiển thị tiếp theo)
6. Giao thức tùy chỉnh của chúng tôi chủ yếu tăng cường xác minh CRC để xử lý tốt hơn các lỗi truyền, giúp ngăn chặn các sự cố giải mã video không mong muốn hoặc thậm chí là sự cố trình phát do gói dữ liệu bị hỏng. Bản thân giao thức giải mã không gây ra độ trễ đáng kể, cho dù đó là giao thức tùy chỉnh của chúng tôi hay giao thức MPEG-TS tiêu chuẩn. Các yếu tố chính ảnh hưởng đến độ trễ thực chất là giai đoạn giải mã và kết xuất sau đó. Nói chung:
   • Vì phát trực tuyến UDP và giải mã/kết xuất trình phát là các quá trình không đồng bộ, hầu hết người chơi giới thiệu một lượng đệm nhất định trước khi bắt đầu phát lại. Bộ đệm càng lớn, độ trễ càng cao.
     Ví dụ, Trình phát đa phương tiện VLC thường sử dụng bộ đệm tương đối lớn, và kích thước bộ đệm của nó thậm chí có thể tăng linh hoạt trong quá trình phát lại. Ngược lại, Splayer cố tình giữ bộ đệm phát lại ở mức rất nhỏ để giảm thiểu độ trễ.
   • Giải mã video và hiển thị khung hình cũng là các quá trình không đồng bộ. Nếu kết xuất không thể theo kịp thời gian, khung hình video được giải mã có thể tích lũy trong hàng đợi kết xuất, giới thiệu độ trễ bổ sung tương tự như bộ đệm tiền giải mã. Splayer cũng được tối ưu hóa trong lĩnh vực này để giảm tích lũy khung hình và duy trì khả năng phát lại có độ trễ thấp.
7. Giao thức tùy chỉnh của chúng tôi cũng bao gồm một số tối ưu hóa bổ sung, đó là lý do tại sao cuối cùng chúng tôi quyết định áp dụng nó thay vì tiếp tục với giao thức MPEG-TS tiêu chuẩn (mà ban đầu chúng tôi đã sử dụng lúc đầu):
   • So với giao thức MPEG-TS tiêu chuẩn, giao thức tùy chỉnh của chúng tôi giảm chi phí giao thức dư thừa và cải thiện việc sử dụng băng thông không dây. Điều này đặc biệt quan trọng đối với các liên kết không dây bị hạn chế về băng thông như hệ thống truyền video COFDM..
   • Giao thức tùy chỉnh của chúng tôi cung cấp tính linh hoạt cao hơn cho việc ghép các loại dữ liệu khác nhau. Ngoài video và âm thanh, nó có thể đóng gói dữ liệu cổng nối tiếp một cách thuận tiện và các luồng dữ liệu khác do người dùng xác định, làm cho nó linh hoạt hơn và dễ dàng mở rộng hơn MPEG-TS tiêu chuẩn.
   • Giao thức tùy chỉnh của chúng tôi hỗ trợ mã hóa và giải mã AES tích hợp trực tiếp trong lớp giao thức. Điều này đặc biệt hữu ích cho các liên kết không dây vốn không hỗ trợ mã hóa AES, chẳng hạn như kết nối Wi-Fi tiêu chuẩn.
   • Ngoài ra, giao thức tùy chỉnh của chúng tôi được thiết kế đặc biệt cho các tình huống truyền có độ trễ thấp và độ tin cậy cao, cho phép tối ưu hóa chặt chẽ hơn trên toàn bộ đường truyền và phát lại so với giao thức tiêu chuẩn có mục đích chung.

Liên quan đến

1. Bạn có muốn lấy Dữ liệu UART từ bảng mã hóa HDMI CVBS Video UART DATA không?
2. SDK trình phát UDP có độ trễ thấp dành cho Windows x64

Q: Hệ thống có hỗ trợ multicast không? Tôi có thể xuất một luồng ra nhiều IP không?

A: Yes. Hệ thống hỗ trợ UDP multicast, cho phép một luồng được gửi đồng thời đến nhiều máy thu mà không cần sao chép luồng trên mỗi IP.Để sử dụng tính năng phát đa hướng, thiết lậpIP từ xa ở phía người gửi tới một địa chỉ multicast, Ví dụ224.0.0.23. Tất cả người nhận tham gia cùng một nhóm multicast bằng cùng một địa chỉ. Về phía người nhận, cấu hình cùng một IP multicast:

• người chơi: đặt IP nhóm thành224.0.0.23
• VLC: mởudp://@224.0.0.23:8090

Multicast cho phép truyền phát một-nhiều trong cùng một mạng. IP thiết bị thực tế không quan trọng; thay vì, việc phân phối phụ thuộc vào sự hỗ trợ multicast của mạng và các thiết bị tham gia cùng một nhóm.Ghi chú: Điều kiện mạng có thể ảnh hưởng đến hiệu suất. Môi trường có VPN, máy ảo, nhiều bộ điều hợp mạng, hoặc các thiết bị chuyển mạch không hỗ trợ IGMP có thể ảnh hưởng đến khả năng thu phát đa hướng.

Đa phương tiện

Đơn hướng

Q: Nếu có nhiều bảng multicast bộ mã hóa trong cùng một mạng, chúng ta có nên thay đổi cổng trên mỗi bo mạch để tránh xung đột?

A: Không nhất thiết. Có hai cách hợp lệ để đảm bảo rằng nhiều luồng bộ mã hóa không xung đột trên cùng một mạng:

1. Sử dụng các địa chỉ IP multicast UDP khác nhau cho mỗi luồng bộ mã hóa.
2. Sử dụng số cổng UDP khác nhau cho mỗi luồng bộ mã hóa.

Truyền phát UDP được phân biệt bởi sự kết hợp của địa chỉ IP (unicast hoặc multicast) and số cổng. Cùng nhau, họ xác định danh tính luồng UDP duy nhất trên mạng.

Trên bảng mã hóa, cái Cài đặt luồng UDP bao gồm:

• IP từ xa: Xác định địa chỉ IP đích (nếu địa chỉ multicast được sử dụng, luồng trở thành luồng phát đa hướng UDP).
• Cổng Tx: Xác định số cổng truyền.

Sự kết hợp của IP từ xa + Cổng Tx xác định luồng UDP duy nhất.

Để tránh xung đột khi triển khai nhiều bảng multicast bộ mã hóa trong cùng một mạng, bạn có thể chỉ định các địa chỉ IP multicast khác nhau, các cổng UDP khác nhau, hoặc sử dụng cả hai tùy theo yêu cầu thiết kế mạng.

Q: Làm cách nào để có được địa chỉ IP multicast cho hệ thống của tôi?

A: Địa chỉ IP Multicast không được gán tự động; chúng được chọn từ phạm vi phát đa hướng tiêu chuẩn 224.0.0.0 ĐẾN 239.255.255.255. Trong thực tế, những địa chỉ này phải được quản trị viên mạng lên kế hoạch và phân bổ để đảm bảo không có xung đột với các dịch vụ hoặc thiết bị multicast hiện có trên mạng.

Q: Bảng mã hóa cần xuất video qua cả giao diện HDMI và AV, nhưng cả hai luồng đều sử dụng cùng một địa chỉ UDP. Làm cách nào chúng ta có thể chơi hoặc chuyển đổi giữa chúng?

A: Khi luồng HDMI và AV được truyền qua cùng một địa chỉ UDP, họ thường không bị ngăn cách bởi các cổng mạng, nhưng bởi số nhận dạng luồng nội bộ, tương tự như một MPEG-TS (Luồng vận chuyển) kết cấu.

Nó hoạt động như thế nào

• Cả hai đầu vào HDMI và AV đều được ghép thành một luồng UDP duy nhất
• Mỗi nguồn video được gán một ID luồng duy nhất (e.g., PID / ID dịch vụ)
• Người nhận thực hiện phân kênh dựa trên các ID này, thay vì tách biệt theo IP hoặc cổng
• Điều này cho phép nhiều kênh video cùng tồn tại trong một luồng UDP

Cách Splayer xử lý việc này

Với chúng tôi người chơi 2.0 Trình phát UDP, hệ thống hỗ trợ kiến ​​trúc này nguyên bản:

• Giải mã đồng thời nhiều luồng video từ một địa chỉ UDP
• Phân tách luồng dựa trên ID nội bộ (Ánh xạ dịch vụ/PID MPEG-TS)
• Chuyển đổi thời gian thực giữa các nguồn HDMI và AV mà không cần thay đổi cài đặt mạng
• Phát lại đa kênh linh hoạt bằng một nguồn đầu vào UDP duy nhất

Thiết kế này đơn giản hóa việc triển khai bằng cách giữ một cấu hình UDP, trong khi vẫn kích hoạt xử lý video đa đầu vào và chuyển đổi liền mạch.

Bạn có thể tải xuống người chơi 2.0 Trình phát UDP đây: người chơi 2.0 Tải xuống trình phát UDP