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