Splayer COFDM接收器Vcan1776-RX串流協定的UDP串流播放器設定

UDP流播放器在COFDM HDMI無​​線視頻發射器和接收器上設置

UDP流播放器是最低延遲CVBS模擬視頻編碼器的最佳解決方案. COFDM無線視頻接收器VCAN1776-RX默認固件支持RTSP播放器. 一些客戶需要使用UDP協議.

可以在網頁上配置IP地址和端口號, HTTP://192.168.0.215 (默認)

Splayer UDP stream player setting for stream protocol of COFDM Receiver Vcan1776-RX 1
  1. 升級固件後, 接收端將恢復出廠默認參數 (中心頻率: 320兆赫, 無線帶寬: 6兆赫, 網絡端口IP地址: 192.168.0.215), 客戶需要通過 參數配置板工具, 和發射器保存一致.
  1. 客戶通過網頁訪問接收器Web服務器 (HTTP://192.168.0.215), 並修改其自己的IP地址以及連接到接收器的Windows PC端的IP地址的設置:

注意: 他們之中, 本地IP是接收器自己的IP, 遠程IP是對接Windows PC結束IP. 客戶可以根據他的實際情況進行配置. 請注意，修改僅在重新啟動接收器後才生效.

下載UDP播放器 斯佩爾

  1. 下載UDP播放器 斯佩爾.
  2. 在Windows PC上打開Splayer播放器, 單擊右下角的設置按鈕, 設置頁將彈出:
Splayer UDP stream player setting for stream protocol of COFDM Receiver Vcan1776-RX 2

注意:

  1. 可以看出，端口端口號設置為 1234, 它是由接收器的UDP流媒體編碼的，無法修改;
  2. 在解碼列中, 根據當前的視頻流屬性進行配置, 例如H264低延遲視頻流配置如上;
  1. 設置並單擊 “確認” 保存參數的按鈕, 單擊左下角的播放按鈕. Windows PC接收到UDP推動流之後, 它將立即解碼並播放.
UDP stream player setting for wireless video transmitter and receiver
無線視頻發射器和接收器的UDP流播放器設置

以上UDP流播放器設置適合以下模型.

它如何支持Linux VLC播放器? 在Linux下玩低延遲流?

題: 現在UDP流不在VLC播放器中. 我需要在Linux下播放此UDP流，然後嘗試了解此流的細節. 任何腳本，鑰匙或其他東西?

我想在Linux下製作自己的播放器，我想從解調器中了解此UDP視頻流的詳細信息.

如果是常規的UDP視頻流, 然後質疑為什麼它不與VLC或Obs Studio一起玩.

回答: 用於型號VCAN1726-RX, 我們有兩個可選的固件, RTSP播放器的第一個固件支持VLC播放器, 但是一些客戶提到它的延遲很長, 所以我們製作了第二個固件, UDP在Splayer廣播, 支持較低的延遲.

此UDP音頻和視頻流是我們的自定義格式, 因此VLC無法解釋. 如果您的客戶想打開自己的玩家 (在Linux下), 當前有兩個選擇:

  1. 更新到默認的RTSP流訪問 (RTSP播放器的第一個固件)
  2. 我們提供相應的Demux庫和例程 (我們需要了解客戶的Linux環境，以編譯合適的庫文件)
  3. 這是 “Demux庫和例程” 由我們的工程師在Ubuntu下撰寫 14.04 64位系統

對於普通客戶來說，第二種非常困難, 而且我們不知道您自己的客戶玩家的發展功能.

因為有些客戶遇到了Windows OS VLC播放器的低延遲問題, 無論我們在這裡如何測試, 我們沒有發現這個問題. 當時, 您使用Windows測試. 也許如果將其更改為Linux, 不會有RTSP流問題. 請嘗試在Linux上使用第一個版本的固件測試VCAN1726樣品. 也許這不是Linux OS上的問題.

題: 您可以為此應用構建Docker映像嗎? 哪個端口用於傳入流, 以及帶有一些廣泛使用編解碼器的外向流的另一個端口 (H264)?

什麼是Splayer和UDP流播放器?

Splayer是支持各種視頻格式的媒體播放器, 包括UDP流.

UDP流是一種使用用戶數據報協議通過Internet發送視頻數據的方法 (UDP), 這是一個快速而簡單的協議，不能保證數據包的交付或順序.

UDP流可以用於實時視頻廣播或低延遲視頻傳輸, 但這也可能遭受數據包丟失或腐敗的困擾.

根據網絡搜索結果, Splayer可以使用以下步驟播放UDP流:

  • 打開Splayer，然後單擊 “開啟網址” 右上角的按鈕.
  • 輸入格式UDP的UDP流的URL://@ip: 港口, 其中IP是服務器的IP地址，端口是流的端口號. 例如, UDP://@224.0.0.1:1234.
  • 單擊 “好” 按鈕並等待流加載.

Splayer如何很好地適合Win10?

題: 我們無法開始爆發器 4.2 和 4.3 在窗戶下 10. 您能否為我們提供正確版本的Windows Splayer 10 和 11?

4.2 目前開始和關閉. 4.3 從錯誤消息開始.

故障應用程序名稱: splayer.exe, 版: 1.0.0.1, 時間戳記: 0X646D83E2
故障模塊名稱: dvb_demux.dll, 版: 1.0.0.1, 時間戳記: 0X5FE5BDBF
異常代碼: 0XC0000005
故障偏移: 0X0001484A
故障過程ID: 0X3888
故障申請開始時間: 0X01DA1164B89C78EB
故障應用路徑: C:\Users\admin\Downloads\Splayer_v4.3_2022.10.22\Splayer.exe
故障模塊路徑: C:\Users\admin\Downloads\Splayer_v4.3_2022.10.22\dvb_demux.dll
報告ID: 4AF19407-045E-48E-A0F7-86FC90C6B3D3
故障包全名:
故障包裝相關的應用程序ID:

回答: 請嘗試使用我們的splayer_qt_v1.0.zip (103.5MB).

反饋: 新版本的Splayer在問題網站上效果很好 10! 謝謝你！

題: 我們發現播放Reciver的視頻時的時間延遲增加了Splayer程序 (UDP流).

如果詳細說話 – 接收器直接與以太網電纜連接到PC. PC和接收器在同一本地網絡中. 當我們啟動濺射器時，時間延遲是正常的，精確的計數向我們展示了 330 MSEC, 從HDMI輸出中，這是我們觀察到的一點點 270 MSEC. 這很好. 但是，如果我們等待幾分鐘而沒有任何改變工作場所的任何變化，我們會觀察到時間延遲的持續增加 1-1,5 SEC在客戶申請中不可接受.
昨天我自己贏了 10, 在不同的PC上Win11與Splayer QT的複雜關閉贏得Brandmauer (您的最後版本), 和splayer 4.3 (舊版). 我每次以任何配置重複此問題.
請幫助我解決這個問題. 我們需要從播放器播放中持續不斷的時間延遲時間，這可能不超過 350 MSEC.

回答: 這樣的問題不應該發生, 因為播放器在低延遲模式下沒有緩存, 延遲完全取決於PC的解碼能力. 工程師將設置環境並在下週一進行測試.

另一點是要求客戶檢查其筆記本電腦顯示器的刷新率設置. 例如, 如果相機輸入1080P60, 然後，客戶的筆記本電腦顯示器的刷新率也必須為60Hz. 除此以外, 顯示器太慢, 這也會導致數據擁堵並引入延遲.

殺手球員有很大的延遲, 解碼很慢，或者顯示速度很慢, 都是由PC引起的.

HDMI攝像機編碼HDMI接收器解碼, 輸出顯示, 和計算機播放延遲測試

Splayer UDP stream player setting for stream protocol of COFDM Receiver Vcan1776-RX 3
Splayer UDP stream player setting for stream protocol of COFDM Receiver Vcan1776-RX 4

我們沒有發現您提到的問題.

可以看出，當前的Splayer播放器屏幕和接收器HDMI輸出是一致的, 它們之間的延遲非常低.

你能問客戶嗎, 相機輸入的分辨率和幀速率是多少? 假設客戶的相機為1080p60, 您也可以執行以下兩個步驟以進一步解決問題:

  1. 讓客戶將相機更改為較低的幀速率進行測試, 例如1080P50/30;
  2. 您可以設置編碼段參數以使其使其下框架編碼. 例如, 通過參數端口發送ATSO0,30_命令, 和用於測試的編碼輸出1080P30.

注意:

  1. Splayer is specifically developed for our proprietary/custom streaming protocol and currently does not support parsing or playback of standard MPEG-TS protocols.
  2. Splayer is currently available only on Windows. Linux and Android versions have not been developed yet and are not supported at this stage.
  3. 此外, it is not the mpeg-ts protocol that causes the delay to increase. Even if it is switched to our custom protocol, the delay will not be reduced (our custom protocol mainly performs CRC checks on all data packets, while the mpeg-ts protocol does not, which is the biggest difference between the protocols). The biggest impact on latency is the processing of video decoding and display in the player. Our own player Splayer will be optimized for image transmission application scenarios.
  4. Even if the customer gets our demux library and extracts the audio and video streams, it still has to do the video decoding and display by itself. This ordinary customer does not have this ability. Most customers will only use open source players (such as based on gstreamer), and the video delay of these open source players will not be good. If you want good video delay, you basically have to develop your own player.
  5. If the customer insists on the demux library and says that he has the ability to deal with the subsequent video decoding and playback, I can also cooperate with you (but we only provide the demux library and routines under Linux/android, and do not provide subsequent decoding and display-related support)
  6. Our custom protocol mainly enhances CRC verification to better handle transmission errors, which helps prevent unexpected video decoding issues or even player crashes caused by corrupted data packets. The demuxing protocol itself does not introduce significant latency, whether it is our custom protocol or the standard MPEG-TS protocol. The main factors affecting latency are actually the decoding and rendering stages afterward. 一般來說:
    • Since UDP streaming and player decoding/rendering are asynchronous processes, most players introduce a certain amount of buffering before starting playback. The larger the buffer, the higher the latency.
      例如, VLC media player typically uses relatively large buffering, and its buffer size may even increase dynamically during playback. 相比之下, Splayer keeps the playback buffer intentionally very small to minimize latency.
    • Video decoding and frame rendering are also asynchronous processes. If rendering cannot keep up in time, decoded video frames may accumulate in the rendering queue, which introduces additional latency similar to pre-decoding buffering. Splayer is also optimized in this area to reduce frame accumulation and maintain low-latency playback.
  7. Our custom protocol also includes several additional optimizations, which is why we ultimately decided to adopt it instead of continuing with the standard MPEG-TS protocol (which we originally used at the beginning):
    • Compared with the standard MPEG-TS protocol, our custom protocol reduces redundant protocol overhead and improves wireless bandwidth utilization. This is particularly important for bandwidth-constrained wireless links such as COFDM video transmission systems.
    • Our custom protocol provides greater flexibility for multiplexing different types of data. 除了視訊和音訊, it can conveniently encapsulate serial port data and other user-defined data streams, making it more flexible and easier to extend than standard MPEG-TS.
    • Our custom protocol supports integrated AES encryption and decryption directly within the protocol layer. This is especially useful for wireless links that do not natively support AES encryption, such as standard Wi-Fi connections.
    • 此外, our custom protocol is designed specifically for low-latency and high-reliability transmission scenarios, allowing tighter optimization across the entire transmission and playback pipeline compared with a general-purpose standard protocol.

相對的

  1. 您想從HDMI CVBS視頻UART數據編碼板獲取UART數據嗎?
  2. 適用於 Windows x64 的低延遲 UDP 播放器 SDK

Q: 系統是否支援組播? 我可以將一個流輸出到多個IP嗎?

一個: 是. 系統支援UDP組播, allowing one stream to be delivered to multiple receivers simultaneously without duplicating the stream per IP.使用多播, 設定遠程 IP 在發送方到多播位址, 例如224.0.0.23. 所有接收者使用相同的位址加入相同的多重播放群組. 在接收端, 配置相同的組播IP:

  • 斯佩爾: 將組IP設定為224.0.0.23
  • VLC: 打開udp://@224.0.0.23:8090

多播支援同一網路內的一對多串流傳輸. 實際設備IP並不重要; 反而, delivery depends on network multicast support and devices joining the same group.注意: 網路狀況可能會影響效能. 有 VPN 的環境, 虛擬機, 多個網路介面卡, 或不支援 IGMP 的交換器可能會影響組播接收.

組播

Remote IP setting on Multicast of SDI AHD to IP encoder board
SDI AHD 到 IP 編碼器板組播的遠端 IP 設定
VLC network URL setting on Multicast of SDI AHD to IP encoder board
SDI AHD 多播到 IP 編碼器板的 VLC 網路 URL 設定

單播

Remote IP setting on Unicast of SDI AHD to IP encoder board
SDI AHD 單播到 IP 編碼器板的遠端 IP 設定
VLC network URL setting on Unicast of SDI AHD to IP encoder board
SDI AHD 到 IP 編碼器板單播的 VLC 網路 URL 設定

Q: If there are multiple encoder multicast boards in the same network, should we change the port on each board to avoid conflict?

一個: 未必. There are two valid ways to ensure that multiple encoder streams do not conflict on the same network:

  1. Use different UDP multicast IP addresses for each encoder stream.
  2. Use different UDP port numbers for each encoder stream.

UDP streaming is distinguished by the combination of IP地址 (unicast or multicast) 和 port number. 一起, they define a unique UDP stream identity on the network.

On the encoder board, 該 UDP Stream settings 包括:

  • 遠程 IP: Defines the destination IP address (if a multicast address is used, the stream becomes a UDP multicast stream).
  • Tx Port: Defines the transmission port number.
multiple encoder boards in same network configured with a different IP address UDP port number
multiple encoder boards in same network configured with a different IP address UDP port number

結合 遠程 IP + Tx Port determines a unique UDP stream.

To avoid conflicts when multiple encoder multicast boards are deployed in the same network, you can either assign different multicast IP addresses, different UDP ports, or use both depending on the network design requirements.

Q: How do I obtain multicast IP addresses for my system?

一個: Multicast IP addresses are not automatically assigned; they are selected from the standard multicast range 224.0.0.0 至 239.255.255.255. 實踐, these addresses should be planned and allocated by the network administrator to ensure there are no conflicts with existing multicast services or devices on the network.

Q: The encoder board needs to output video over both HDMI and AV interfaces, but both streams use the same UDP address. How can we play or switch between them?

一個: When HDMI and AV streams are transmitted over the same UDP address, they are typically not separated by network ports, 但是透過 internal stream identifiers, similar to an MPEG-TS (傳輸流) 結構.

它是如何運作的

  • Both HDMI and AV inputs are multiplexed into a single UDP stream
  • Each video source is assigned a unique stream ID (例如, PID / service ID)
  • The receiver performs demultiplexing based on these IDs, rather than separating by IP or port
  • This allows multiple video channels to coexist in one UDP stream

How Splayer handles this

跟我們 斯佩爾 2.0 UDP播放器, the system supports this architecture natively:

  • Simultaneous decoding of multiple video streams from a single UDP address
  • Stream separation based on internal IDs (MPEG-TS PID/service mapping)
  • Real-time switching between HDMI and AV sources without changing network settings
  • Flexible multi-channel playback using a single UDP input source

This design simplifies deployment by keeping one UDP configuration, while still enabling multi-input video handling and seamless switching.

You can download 斯佩爾 2.0 UDP播放器 這裡: 斯佩爾 2.0 UDP Player Download

問一個問題

← 返回

感謝你的回應。 ✨