Splayer COFDM接收器Vcan1776-RX流协议的UDP流播放器设置

COFDM HDMI 无线视频发射器和接收器上的 UDP 流播放器设置

UDP流播放器是最低延迟CVBS模拟视频编码器的最佳解决方案. COFDM无线视频接收器Vcan1776-RX默认固件支持RTSP播放器. 部分客户端需要使用UDP协议.

IP地址和端口号可在网页上配置, http://192.168.0.215 (默认)

1. 升级固件后, 接收端将恢复出厂默认参数 (中心频率: 320MHz, 无线带宽: 6MHz, 网口IP地址: 192.168.0.215), 客户需要通过修改中心频率和带宽 参数配置板工具, 和发射器一致保存.

2. 客户通过网页访问接收方Web服务器 (HTTP协议://192.168.0.215), 并修改自身IP地址以及接收器连接的Windows PC端IP地址的设置:

笔记: 他们之中, 本地IP是接收者自己的IP, 远程IP为对接Windows PC端ip. 客户可以根据自己的实际情况进行配置. 注意修改需要重启接收器后才会生效.

下载UDP播放器 斯佩尔

3. 下载UDP播放器 斯佩尔.
   • 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 适用于 Win10 或 Win11
   • https://drive.google.com/file/d/1VAegQjd-PmIL2XbJf7K8dnujMxhoIuhd/view?usp=drive_link
   • Splayer_QT_V1.1.1 适用于 Win10 或 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. 在Windows PC上打开Splayer播放器, 点击右下角的设置按钮, 然后会弹出设置页面:

笔记:

1. 可以看到Port端口号设置为 1234, 由接收方UDP流程序硬编码，不可修改;
2. 在解码栏, 根据当前视频流属性进行配置, 比如上面的H264低延迟视频流配置;

4. 设置好后点击 “确认” 按钮保存参数, 点击左下角的播放按钮. Windows PC收到UDP推流后, 它将立即解码并播放.

以上UDP流播放器设置适用于以下机型.

它如何支持Linux VLC播放器? Linux下播放低延迟流?

问题: 现在 UDP 流无法使用 VLC 播放器播放. 我需要在Linux下播放这个UDP流，我尝试了解这个流的细节. 任何脚本或密钥或其他东西?

我想在Linux下制作自己的播放器，我想了解解调器中这个UDP视频流的细节.

如果是普通的UDP视频流, 然后质疑为什么它不能与 VLC 或 OBS studio 一起播放.

回答: 适用于型号 Vcan1726-RX, 我们有两个固件可供选择, RTSP播放器的第一个固件支持VLC播放器, 但有些客户提到它的延迟很长, 所以我们制作了第二个固件, Splayer 上的 UDP 广播, 支持更低的延迟.

这个UDP音视频流是我们自定义的格式, 所以VLC无法解释它. 如果您的客户想打开自己的播放器 (Linux下), 目前有两种选择:

1. 更新为默认 RTSP 流访问 (RTSP 播放器的第一个固件)
2. 我们提供相应的DEMUX库和例程 (我们需要了解客户的Linux环境才能编译出合适的库文件)
3. 这是 “DEMUX 库和例程” 由我们的工程师在Ubuntu下编写 14.04 64位系统

第二种对于普通客户来说太难了, 而且我们不知道您客户自己的播放器的开发能力.

由于部分客户端在Windows操作系统VLC播放器上遇到低延迟问题, 不管我们在这里如何测试, 我们没有发现这个问题. 当时, 你使用Windows来测试. 如果换成Linux也许可以, 不会有RTSP流媒体问题. 请尝试在 Linux 上使用第一版固件测试 Vcan1726 示例. 也许这在 Linux 操作系统上不是问题.

问题: 你能为这个应用程序构建一个 docker 镜像吗? 哪一个端口用于传入流, 另一个用于输出流的端口，带有一些广泛使用的编解码器 (h264)?

什么是 Splayer 和 UDP 流播放器?

SPlayer是一款支持多种视频格式的媒体播放器, 包括 UDP 流.

UDP 流是一种使用用户数据报协议通过互联网发送视频数据的方法 (UDP协议), 这是一种快速而简单的协议，不保证数据包的传送或顺序.

UDP流可用于实时视频广播或低延迟视频传输, 但也可能会出现数据包丢失或损坏的情况.

根据网络搜索结果, SPlayer可以通过以下步骤播放UDP流:

• 打开 SPlayer 并单击 “打开网址” 右上角的按钮.
• 以 udp 格式输入 UDP 流的 URL://@ip: 港口, 其中 ip 是服务器的 IP 地址，port 是流的端口号. 例如, UDP协议://@224.0.0.1:1234.
• 单击 “好的” 按钮并等待流加载.

Splayer如何在Win10上运行良好?

问题: 我们无法启动 Splayer 4.2 and 4.3 在Windows下 10. 您能为我们提供适用于 Windows 的 Splayer 的正确版本吗 10 and 11?

4.2 此刻开始并关闭. 4.3 从错误消息开始.

应用程序名称错误: 播放器, 版本: 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
报告编号: 4af19407-045e-48e5-a0f7-86fc90c6b3d3
错误包全名:
错误包相关应用程序 ID:

回答: 请尝试使用我们的Splayer_qt_v1.0.zip (103.5MB).

反馈: 新版SPlayer在Win下的问题站点上运行良好 10! 谢谢你！

问题: 我们发现从 Reciver by Splayer 程序播放视频时时间延迟增加 (UDP流).

如果详细讲一下 – 接收器通过以太网电缆直接连接到 PC. PC和接收器在同一个本地网络. 当我们启动 Splayer 时，时间延迟是正常的，并且精确的计数显示我们 330 毫秒, 这比我们观察到的 HDMI 输出要多一点 270 毫秒. 这很好. 但是，如果我们在工作场所没有任何变化的情况下等待几分钟，我们就会观察到时间延迟持续增加，达到 1-1,5 秒，这在客户应用程序中是不可接受的.
昨天我在Win上亲自测试了一下 10, 和 Win11 在不同的 PC 上，具有复杂的关闭 Win Brandmauer 和 Splayer qt (你的最后一个版本), 和斯佩尔 4.3 (旧版). 我每次在任何配置中都会重复这个问题.
请帮我解决这个问题. 我们需要 Splayer 播放时的恒定时间延迟，该延迟不能超过 350 毫秒.

回答: 这样的问题不应该出现, 因为低延迟模式下播放器没有缓存, 而延迟完全取决于PC的解码能力. 工程师将于下周一搭建环境并进行测试.

另一点是要求客户检查笔记本电脑显示器的刷新率设置. 例如, 如果相机输入1080p60, 那么客户笔记本电脑显示器的刷新率也必须是60Hz. 否则, 显示速度会太慢, 这也会导致数据拥塞并引入延迟.

Slayer播放器延迟较大, 要么解码慢，要么显示慢, 都是PC造成的.

HDMI 摄像头编码 HDMI 接收器解码, 输出到显示器, Splayer播放器及电脑播放延迟测试

我们没有发现您提到的问题.

可以看到当前Splayer播放器屏幕和接收器HDMI输出是一致的, 并且它们之间的延迟非常低.

可以请问一下顾客吗, 相机输入的分辨率和帧速率是多少? 假设客户的相机是1080p60, 您还可以执行以下两个步骤来进一步排查问题:

1. 让客户将相机更改为较低帧率进行测试, 例如1080p50/30;
2. 可以设置编码段参数，让它降帧编码. 例如, 通过参数口发送ATSO0,30_命令, 编码输出1080p30用于测试.

笔记:

1. Splayer 是专门为我们专有/自定义流媒体协议开发的，目前不支持标准 MPEG-TS 协议的解析或播放.
2. Splayer 目前仅在 Windows 上可用. Linux和Android版本尚未开发，现阶段不支持.
3. 此外, 不是mpeg-ts协议导致延迟增加. 即使切换到我们自定义的协议, 延迟不会减少 (我们的自定义协议主要对所有数据包执行CRC检查, 而 mpeg-ts 协议则没有, 这是协议之间最大的区别). 对延迟影响最大的是播放器中视频解码和显示的处理. 我们自己的播放器Splayer将会针对图传应用场景进行优化.
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. 我们的自定义协议主要增强了CRC验证，以更好地处理传输错误, 这有助于防止意外的视频解码问题，甚至是因数据包损坏而导致的播放器崩溃. 解复用协议本身不会引入显着的延迟, 无论是我们自定义的协议还是标准的MPEG-TS协议. 影响延迟的主要因素实际上是之后的解码和渲染阶段. 一般来说:
   • 由于 UDP 流和播放器解码/渲染是异步过程, 大多数播放器在开始播放之前都会引入一定量的缓冲. 缓冲区越大, 延迟越高.
     例如, VLC 媒体播放器通常使用相对较大的缓冲, 其缓冲区大小甚至可能在播放过程中动态增加. 相比之下, Splayer 故意将播放缓冲区保持得非常小，以最大程度地减少延迟.
   • 视频解码和帧渲染也是异步过程. 如果渲染跟不上, 解码的视频帧可能会累积在渲染队列中, 这会引入类似于预解码缓冲的额外延迟. Splayer也在这方面进行了优化，以减少帧累积并保持低延迟播放.
7. 我们的定制协议还包括一些额外的优化, 这就是为什么我们最终决定采用它而不是继续使用标准 MPEG-TS 协议 (我们最初使用的):
   • 与标准MPEG-TS协议比较, 我们的自定义协议减少了冗余协议开销并提高了无线带宽利用率. 这对于带宽受限的无线链路（例如 COFDM 视频传输系统）尤为重要.
   • 我们的自定义协议为复用不同类型的数据提供了更大的灵活性. 除了视频和音频, 可以方便地封装串口数据和其他用户自定义的数据流, 使其比标准 MPEG-TS 更灵活且更易于扩展.
   • 我们的自定义协议支持直接在协议层内集成 AES 加密和解密. 这对于本身不支持 AES 加密的无线链路特别有用, 例如标准 Wi-Fi 连接.
   • 此外, 我们的定制协议专为低延迟、高可靠的传输场景而设计, 与通用标准协议相比，允许对整个传输和播放管道进行更严格的优化.

相对的

1. 您想从 HDMI CVBS 视频 UART 数据编码器板获取 UART 数据吗?
2. 适用于 Windows x64 的低延迟 UDP 播放器 SDK

Q: 系统是否支持组播? 我可以将一个流输出到多个IP吗?

一个: Yes. 系统支持UDP组播, 允许将一个流同时传送到多个接收器，而无需为每个 IP 复制该流。使用多播, 设置远程IP 在发送方到多播地址, 例如224.0.0.23. 所有接收者使用相同的地址加入相同的多播组. 在接收端, 配置相同的组播IP:

• 斯佩尔: 将组IP设置为224.0.0.23
• 可见光通信: 打开udp://@224.0.0.23:8090

多播支持同一网络内的一对多流传输. 实际设备IP并不重要; 反而, 交付取决于网络多播支持和加入同一组的设备。笔记: 网络状况可能会影响性能. 有 VPN 的环境, 虚拟机, 多个网络适配器, 或者不支持 IGMP 的交换机可能会影响组播接收.

组播

单播

Q: 如果同一网络中有多个编码器组播板, 我们是否应该更改每个板上的端口以避免冲突?

一个: 未必. 有两种有效的方法可以确保多个编码器流在同一网络上不会发生冲突:

1. 使用不同的UDP组播IP地址 对于每个编码器流.
2. 使用不同的UDP端口号 对于每个编码器流.

UDP 流的特点是结合 IP地址 (单播或多播) and 端口号. 一起, 他们在网络上定义了唯一的UDP流标识.

在编码器板上, 这 UDP 流设置 包括:

• 远程IP: 定义目标IP地址 (如果使用多播地址, 该流成为 UDP 多播流).
• 发送端口: 定义传输端口号.

的组合 远程IP + 发送端口 确定唯一的 UDP 流.

避免同一个网络中部署多个编码器组播板时发生冲突, 您可以分配不同的多播 IP 地址, 不同的UDP端口, 或根据网络设计要求同时使用.

Q: 如何获取系统的多播 IP 地址?

一个: 组播 IP 地址不会自动分配; 它们是从标准多播范围中选择的 224.0.0.0 到 239.255.255.255. 在实践中, 这些地址应由网络管理员规划和分配，以确保与网络上现有的组播服务或设备不发生冲突.

Q: 编码器板需要通过 HDMI 和 AV 接口输出视频, 但两个流使用相同的 UDP 地址. 我们如何播放或在它们之间切换?

一个: 当 HDMI 和 AV 流通过相同的 UDP 地址传输时, 他们通常是 不被网络端口分隔, 但是通过 内部流标识符, 类似于 MPEG-TS (传输流) 结构.

它是如何运作的

• HDMI 和 AV 输入均为 多路复用为单个 UDP 流
• 每个视频源都分配有一个 唯一的流ID (例如, PID / 服务ID)
• 接收器执行 根据这些ID进行解复用, 而不是通过IP或端口来分隔
• 这允许多个视频通道共存于一个 UDP 流中

Splayer 如何处理这个问题

与我们的 斯佩尔 2.0 UDP播放器, 系统原生支持该架构:

• 同时解码 来自单个 UDP 地址的多个视频流
• 流分离基于 内部 ID (MPEG-TS PID/服务映射)
• HDMI 和 AV 信号源之间实时切换，无需更改网络设置
• 使用单个 UDP 输入源灵活的多通道播放

此设计通过保留 1个UDP配置, 同时仍然启用 多输入视频处理和无缝切换.

您可以下载 斯佩尔 2.0 UDP播放器 这里: 斯佩尔 2.0 UDP播放器下载