我正在计划开发一种视频转码系统。
一台机器有图像采集卡，可以接收来自各种来源的音频/视频信号。
多台转码机将通过千兆以太网连接到这台源机器。
源机器将压缩的音频/视频帧数据发送到转码机器。
因为这是一种简单的单向传输，我想我可以使用 HTTP。但是网络带宽是个问题。
通过简单的搜索，我在Superuser 中找到了一个帖子。
这个真实的千兆以太网示例仅显示 340Mbps 的吞吐量。
我的目标系统应该能够同时对全高清视频进行多次转码。
1080P全高清视频无压缩数据速率可达712Mbps。即使使用压缩，这也很容易使千兆网络仅在 1 或 2 个通道上饱和。
假设 3 是目标。我使用什么协议来完成 3 个全高清视频数据的同时传输？我可以使用 HTTP 吗？我必须设计特殊用途的多播协议吗？是否有任何用于此目的的开源和/或开放规范协议？
提前致谢。
【问题讨论】：
标签： video-streaming tcp network-protocols
如果您想使用多播并且可以切换到 UDP 协议，那么我建议您考虑 RTP 协议。 但是您似乎没有流式传输的目的，此外，您正在发送压缩文件。 HTTP 应该没问题，但是如果你想避免开销，那么你可以使用 3 个没有 HTTP 的简单 TCP 连接。
【讨论】：
TCP/IP 吞吐量如果没有在您自己的条件下实际尝试，就很难量化。该人可能只看到 340Mbps 的吞吐量，但将高带宽连接饱和到最大速度的简单方法是通过 TCP 进行多个并行传输......为此，HTTP 也可以工作。
真正的问题是双重的……首先，您的视频是否需要在一定时间内到达您的转码器？如果是这样，你的时间窗口是多少？二、单个gzip压缩流占用多少带宽？
最后，请记住，您可以使用 LACP 将您的以太网连接与两个或更多 NIC 捆绑在一起，这样如果您发现您受到单个 GigE 连接的限制，您的服务器可以输出更多数据。与您的网络管理员联系，看看是否有可能...
编辑回应评论中的讨论：
因此，您有大约 30 毫秒的时间来发送单帧的数据......只是为了帮助您进行预算，如果这不包括转码延迟，请务必从 1/30 秒的数字中减去这些延迟...在这种时间安排下，我将保持一个恒定的 TCP 套接字打开，并通过同一个 TCP 套接字逐步发送文件...这将减少 TCP 建立和拆除的开销...您甚至可以使用普通 ole FTP 解决问题...只是在视频程序结束之前不要关闭 FTP 会话...配置您的交换机和主机以使用巨型帧（以太网 MTU 超过 1522 字节，包括标头、crc、和 vlan 标记...）可以将您的文件传输数量减少几毫秒，但是 jumbos 的管理开销可能会很痛苦...例如，当有人升级交换机或路由器时，他们经常忘记检查供应商接口支持对于巨型...使问题更加复杂的是供应商销售代表“使 assu mptions”关于他们的巨型帧支持。
【讨论】：