视频流上的TCP与UDP

Question

我刚从网络编程的考试中回到家,他们问我们的一个问题是"如果要播放视频,你会使用TCP还是UDP？为存储的视频和实时视频流提供解释".对于这个问题,他们只是简单地期望存储视频的TCP简短回答和实时视频的UDP,但我在回家的路上想到了这一点,并且使用UDP流媒体直播视频一定更好吗？我的意思是,如果你有足够的带宽,并说你正在播放足球比赛或音乐会,你真的需要使用UDP吗？

让我们说,当你正在流式音乐会或使用TCP的任何东西时,你开始丢失数据包(在你和发送者之间的某些网络中发生了一些不好的事情),并且整整一分钟你都没有得到任何数据包.视频流将暂停,一分钟后,数据包开始再次通过(IP为您找到了新的路由).然后会发生什么是TCP会在您丢失的那一刻重新传输并继续向您发送实时流.假设带宽高于流上的比特率,并且ping不是太高,所以在很短的时间内,丢失的那一分钟将作为流的缓冲区,这样,如果再次发生丢包,您将不会注意到.

现在,我可以想到一些设备,这不是一个好主意,例如视频会议,你需要总是在流的末尾,因为视频聊天期间的延迟是可怕的,但在足球比赛或音乐会期间,如果你在流后面一分钟,这有什么关系？此外,您可以保证获得所有数据,最好保存以供日后查看,而不会出现任何错误.

所以这让我想到了我的问题.关于使用TCP进行直播,我不知道有什么缺点吗？或者它应该真的是,如果你有它的带宽你应该去TCP,因为它对网络"更好"(流量控制)？

Answer 1

使用TCP进行实时视频的缺点:

1. 通常,实时视频流设备的设计不考虑TCP流.如果使用TCP,则操作系统必须为每个客户端缓冲未确认的段.这是不可取的,特别是在直播活动的情况下; 据推测,由于事件的特殊性,您的同时客户名单很长.预先录制的视频广播通常没有这么多的问题,因为观众错开了他们的重播活动; 因此TCP更适合重播视频点播.
2. IP多播大大降低了大量受众的视频带宽需求; TCP阻止使用IP多播,但UDP非常适合IP多播.
3. 实时视频通常是从相机录制的恒定带宽流; 预录制的视频流脱离磁盘.当源流处于恒定带宽时(如实况事件会发生的那样),TCP的丢失 - 回退动态使得更难以提供实时视频.如果从相机缓冲到磁盘,请确保有足够的缓冲区用于不可预测的网络事件和可变的TCP发送/退避速率.UDP为此应用程序提供了更多控制,因为UDP不关心网络传输层丢弃.

仅供参考,在描述网络时请不要使用"包"这个词.网络发送"数据包".

Answer 2

但是在足球比赛或音乐会期间,如果你在流后面一分钟,那有什么关系呢？

对一些球迷来说,相当多.有人指出,由于编码(或其他),数字视频流中存在的几秒钟的延迟可能会非常烦人,因为在世界杯比赛等高调事件中,您可以听到来自这些人的欢呼声和呻吟声.隔壁(他们正在观看一个未经处理的模拟程序),然后才能看到引起他们的游戏动作.

我认为,对于那些关心体育运动的人来说(那些是最大的数字电视付费用户群,至少在德国这里),在现场视频流中落后一分钟是完全不可接受的(如同,他们' d切换到竞争对手,但这不会发生.

Answer 3

通常视频流有点容错.因此,如果某些软件包丢失(例如,由于某些路由器正在过载),那么它仍然能够显示内容,但质量会降低.

如果您的直播流使用TCP/IP,那么它将被迫等待那些已删除的包,然后才能继续处理更新的数据.

那是双坏的:

• 旧数据被重新传输(这可能是为了已经显示的帧,因此没有价值)和
• 在重新传输旧数据之后,新数据才能到达

如果您的目标是尽可能显示最新信息(对于实时流,您通常希望是最新的,即使您的帧看起来有点糟糕),那么TCP也会对您不利.

对于录制的流,情况略有不同:你可能会缓冲更多(可能是几分钟!),并且宁愿重新传输数据而不是由于丢失包而导致的一些工件.在这种情况下,TCP是一个很好的匹配(当然,这仍然可以在UDP中实现,但TCP没有与实时流案例一样多的缺点).

Answer 4

有一些适用于UDP传输的用例和适用于TCP传输的其他用例.

该用例还规定了视频的编码设置.广播足球比赛的重点是质量,视频会议的重点是延迟.

使用多播向您的客户提供视频时,将使用UDP.

对多播的要求是广播服务器和客户之间昂贵的网络硬件.实际上,这意味着如果您的公司拥有网络基础设施,您可以使用UDP和多播进行实时视频流.即使这样,服务质量也被用于标记视频数据包并对其进行优先级排序,因此不会发生数据包丢失.

多播将简化广播软件,因为网络硬件将处理向客户分发数据包.客户订阅多播信道,网络将重新配置以将数据包路由到新订户.默认情况下,所有客户都可以使用所有渠道,并且可以进行最佳路由.

此工作流程会对授权过程产生不足.网络硬件不会将订阅用户与其他用户区分开来.授权的解决方案是加密视频内容,并在订阅有效时在播放器软件中启用解密.

单播(TCP)工作流允许服务器检查客户端的凭据,并且只允许有效的订阅.甚至只允许一定数量的同时连接.

未通过互联网启用多播.

要通过Internet传送视频,必须使用TCP.当使用UDP时,开发人员最终重新实现分组重传,例如.Bittorrent p2p实时协议.

"如果你使用TCP,操作系统必须为每个客户端缓冲未确认的段.这是不可取的,特别是在直播事件的情况下".

此缓冲区必须以某种形式存在.对于玩家方的抖动缓冲区也是如此.它被称为"套接字缓冲区",服务器软件可以知道此缓冲区何时已满并丢弃实时流的正确视频帧.最好使用单播/ TCP方法,因为服务器软件可以实现正确的帧丢弃逻辑.UDP情况下随机丢失的数据包只会造成糟糕的用户体验.喜欢这个视频:http://tinypic.com/r/2qn89xz/9

"IP多播大大降低了大量受众的视频带宽需求"

私有网络也是如此,未通过互联网启用多播.

"请注意,如果TCP丢失了太多数据包,则连接会中断;因此,UDP可以为此应用程序提供更多控制,因为UDP不关心网络传输层丢失."

UDP也不关心丢弃整个帧或帧组,因此它不再提供对用户体验的控制.

"通常视频流有点容错"

编码视频不具有容错能力.当通过不可靠的传输进行传输时,向视频容器添加前向纠错.很好的例子是用于卫星视频广播的MPEG-TS容器,其携带多个音频,视频,EPG等流.这是必要的,因为卫星链路不是双工通信,这意味着接收器不能请求重传丢失的数据包.

当您具有双工通信时,最好只将数据重新传输到具有数据包丢失的客户端,然后在发送到所有客户端的流中包含前向纠错的开销.

在任何情况下,丢失的数据包都是不可接受的.在带宽受阻的特殊情况下,丢帧是可以的.

丢失数据包的结果是这样的工件:

一些解码器可以在关键位置中断丢失数据包的流.