基于 TCP/IP 的大二进制块传输协议推荐
我计划开发一种视频转码系统。
一台机器具有图像采集卡，可以接收来自各种来源的音频/视频信号。
多台转码机器将通过千兆以太网连接到该源机器。
源机器将压缩的音频/视频帧数据发送到转码机器。
因为这是简单的单向传输，所以我认为可以使用 HTTP。但网络带宽是问题所在。
通过简单的搜索，我在超级用户中找到了一篇帖子。
这个现实世界的千兆位以太网示例仅显示 340Mbps 的吞吐量。
我的目标系统应该能够同时对全高清视频进行多个转码。
1080P全高清视频在不压缩的情况下数据速率可达712Mbps。即使使用压缩，仅 1 或 2 个通道也很容易使千兆位网络饱和。
假设 3 是目标。使用什么协议来完成 3 个全高清视频数据的同时传输？我可以使用 HTTP 吗？我必须设计特殊用途的多播协议吗？是否有任何开源和/或开放规范协议用于此目的？
提前致谢。
I'm planning to develop a kind of video transcoding system.
One machine has frame grabber and will receive audio/video signal from various sources.
Several transcoding machines will be connected to this source machine through gigabit ethernet.
The source machine will send zipped audio/video frame data to transcoding machines.
Because this is simple one way transport, I thought I can use HTTP. But network bandwidth is the problem.
With simple search I found a post in the Superuser.
This real world gigabit ethernet example shows only 340Mbps throughput.
My target system should be capable of multiple simultaneous transcoding of Full HD video.
Data rate of 1080P full HD video could be 712Mbps without compress. Even with compress, this could easily saturate gigabit network at only 1 or 2 channels.
Let's say 3 is the target. What protocol do I use to accomplish 3 simultaneous transport of full HD video data? Can I use HTTP? Do I have to devise special purpose multicast protocol? Is there any open source and/or open specification protocol for this purpose?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您想使用组播并且可以切换到 UDP 协议，那么我建议您考虑 RTP 协议。
但您似乎没有流媒体目的，此外，您正在发送压缩文件。 HTTP 应该可以解决这个问题，但如果您想避免开销，那么您可以使用 3 个简单的 TCP 连接，而不使用 HTTP。
If you want to use multicast and you can switch to UDP protocol, then I'll suggest you to take in consideration RTP protocol.
But you seem not to have streaming purposes and , in addition , you are sending zipped file. HTTP should be ok for this , but if you want to avoid overhead then you could use 3 simple TCP connections without HTTP.
TCP/IP 吞吐量是很难量化的，除非您在自己的条件下实际尝试过。该人可能只会看到 340Mbps 的吞吐量，但使高带宽连接达到最大速度的简单方法是通过 TCP 进行多个并行传输……为此，HTTP 也可以工作。
真正的问题是双重的......首先，您的视频是否需要在一定时间内到达转码器？如果是这样，您的时间窗口是多少？其次，单个 gzip 压缩流占用多少带宽？
最后，请记住，您可以使用 LACP 将以太网连接与两个或多个 NIC 捆绑在一起，这样，如果您发现自己受到单个 GigE 连接的限制，您的服务器可以输出更多数据。与您的网络管理员联系，看看是否有可能...
编辑评论中的讨论：
所以您有大约 30 毫秒的时间来发送单个帧的数据...只是为了提供帮助你有预算，如果不包括转码延迟，请务必从秒数的 1/30 中减去这些延迟......在这种情况下，我会保持一个恒定的 TCP 套接字打开，然后增量发送文件相同的 TCP 套接字...这将减少 TCP 建立和拆除的开销...您甚至可以使用普通 ole FTP 解决问题...只是在视频程序结束之前不要关闭 FTP 会话过度...将交换机和主机配置为使用巨型帧（超过 1522 字节的以太网 MTU，包括标头、crc 和 vlan 标记...）可以使文件传输次数减少几毫秒，但管理开销巨型帧可能会很痛苦...例如，当有人升级交换机或路由器时，他们经常忘记检查供应商接口对巨型帧的支持...使问题更加复杂的是供应商销售代表对他们的巨型帧支持“做出假设”。
TCP/IP throughput is something that is difficult to quantify without actually trying it under your own conditions. That person might only see 340Mbps of throughput, but the simple way to saturate high bandwidth connections to maximum speed is multiple parallel transfers over TCP... for that purpose HTTP will work as well.
The real question is twofold... first does your video need to arrive at your transcoder within a certain amount of time? If so, what is your timing window? Second, how much bandwidth does a single gzipped stream take up?
Finally, remember you can use LACP to bundle your ethernet connections together with two or more NICs, so your server could pump more data out if you find that you're limited by a single GigE connection. Talk to your network administrator to see if that is a possibility...
EDIT RESPONDING TO DISCUSSION IN COMMENTS:
So you have about 30 milliseconds to send the data for a single frame.... just to help you with budgeting, if that does not include transcoding delays, be sure to subtract those from the 1/30th of a second figure... with that kind of timing, I would keep a constant TCP socket open and just incrementally send the files over the same TCP socket... that will reduce your overhead from TCP establishment and teardown... you might even be able to work something out with plain-ole FTP... just don't close the FTP session until the video program is over... configuring your switch and hosts to use jumbo frames (ethernet MTU over 1522 bytes, including the headers, crc, and vlan tag...) could shave a few more milliseconds off your file transfer numbers, but the administrative overhead of jumbos can be a pain... for instance when someone upgrades the switches or routers, they often forget to check vendor interface support for jumbos... compounding the problem are vendor sales reps who "make assumptions" about their jumbo frame support.