70,039
社区成员
发帖
与我相关
我的任务
分享TCP和UDP视频传输的性能差异有多大？
最近看一个项目，里面的机制由于协议原因视频的传输采用了tcp，所以视频观看很卡。求教如果采用udp会有多大的提升？
...全文
请发表友善的回复…
发表回复
yutianzuijin 2011-10-18
- 打赏
- 举报
[Quote=引用 12 楼 lida2003 的回复:]
mstsc 远程播放电影确实比较卡的。哪怕局域网，我加100M带宽局域网，用mstsc播放，卡的一塌糊涂。
[/Quote]那大哥有什么解决之道吗？
mstsc 远程播放电影确实比较卡的。哪怕局域网，我加100M带宽局域网，用mstsc播放，卡的一塌糊涂。
[/Quote]那大哥有什么解决之道吗？
lida2003 2011-10-18
- 打赏
- 举报
mstsc 远程播放电影确实比较卡的。哪怕局域网，我加100M带宽局域网，用mstsc播放，卡的一塌糊涂。
yutianzuijin 2011-10-18
- 打赏
- 举报
[Quote=引用 9 楼 afer198215 的回复:]
rdesktop啊，基本可以肯定的告诉你，跟TCP无关，因为这个东西 我用过，我们项目里采用的是java版的rdesktop。
查查你们的播放器实现吧。
另外，RDP协议用UDP跟本实现不了。
[/Quote]我现在知道的rdesktop是传递远程桌面变化的部分，然后在本地进行回放，界面的绘制采用xwin，和播放器无关。如果远程桌面变化的部分小则没事，如果变化的大如视频播放则传递的量很大，效果也很差。但是整个rdesktop的底层通信却是基于tcp的，这点我非常确定。
rdesktop啊，基本可以肯定的告诉你，跟TCP无关，因为这个东西 我用过，我们项目里采用的是java版的rdesktop。
查查你们的播放器实现吧。
另外，RDP协议用UDP跟本实现不了。
[/Quote]我现在知道的rdesktop是传递远程桌面变化的部分，然后在本地进行回放，界面的绘制采用xwin，和播放器无关。如果远程桌面变化的部分小则没事，如果变化的大如视频播放则传递的量很大，效果也很差。但是整个rdesktop的底层通信却是基于tcp的，这点我非常确定。
qq120848369 2011-10-18
- 打赏
- 举报
楼主下载一个UDT源码去了解一下，UDT做视频传输流弊死。
想喝咖啡的貓 2011-10-18
- 打赏
- 举报
rdesktop啊，基本可以肯定的告诉你，跟TCP无关，因为这个东西 我用过，我们项目里采用的是java版的rdesktop。
查查你们的播放器实现吧。
另外，RDP协议用UDP跟本实现不了。
查查你们的播放器实现吧。
另外，RDP协议用UDP跟本实现不了。
hulongchuan 2011-10-18
- 打赏
- 举报
启动播放器卡，这可能和硬件的性能有关，我之前也遇到过类似的问题，鼠标键盘不卡，是因为这些简单的操作对硬件的性能要求不高。2楼分析的对，至于tcp和udp之间的性能到底有多大，那只有你试试才能知道!
luciferisnotsatan 2011-10-18
- 打赏
- 举报
[Quote=引用 4 楼 bokutake 的回复:]
rdesktop应该不是传输像传输视频那样传输的，它使用的是差分压缩的方法，所以必须使用TCP来保证传输的有效性，否则差分压缩就不成立了。
真正实时视频基本上都是用UDP的，因为像MPEG分为I帧、B帧什么的，即使中间帧丢失，只要下一个关键帧来了，也可以重建，配合好的缓冲机制的话，比TCP要实用多了
[/Quote]
如果这样的话，用rdesktop不能丢帧，那就只能用TCP了。虽然你可以自己用udp做个检测机制，但速度估计也快不了多少。
rdesktop应该不是传输像传输视频那样传输的，它使用的是差分压缩的方法，所以必须使用TCP来保证传输的有效性，否则差分压缩就不成立了。
真正实时视频基本上都是用UDP的，因为像MPEG分为I帧、B帧什么的，即使中间帧丢失，只要下一个关键帧来了，也可以重建，配合好的缓冲机制的话，比TCP要实用多了
[/Quote]
如果这样的话，用rdesktop不能丢帧，那就只能用TCP了。虽然你可以自己用udp做个检测机制，但速度估计也快不了多少。
yujie_v 2011-10-18
- 打赏
- 举报
udp关键考虑实时性的。tcp丢包重传，这个是无法控制的。
yutianzuijin 2011-10-18
- 打赏
- 举报
[Quote=引用 2 楼 luciferisnotsatan 的回复:]
udp本身没有安全保障，视频丢几帧问题不大。但你先确定是tcp数据传的慢导致的，而不是你网络本身就慢。
[/Quote]我获得的数据是一帧变化的tcp帧是15k，如果要流畅播放至少也要有每秒30帧吧，带宽达不到。但是换成udp就能达到吗，我不是很清楚.
udp本身没有安全保障，视频丢几帧问题不大。但你先确定是tcp数据传的慢导致的，而不是你网络本身就慢。
[/Quote]我获得的数据是一帧变化的tcp帧是15k，如果要流畅播放至少也要有每秒30帧吧，带宽达不到。但是换成udp就能达到吗，我不是很清楚.
辰岡墨竹 2011-10-18
- 打赏
- 举报
rdesktop应该不是传输像传输视频那样传输的，它使用的是差分压缩的方法，所以必须使用TCP来保证传输的有效性，否则差分压缩就不成立了。
真正实时视频基本上都是用UDP的，因为像MPEG分为I帧、B帧什么的，即使中间帧丢失，只要下一个关键帧来了，也可以重建，配合好的缓冲机制的话，比TCP要实用多了
真正实时视频基本上都是用UDP的，因为像MPEG分为I帧、B帧什么的，即使中间帧丢失，只要下一个关键帧来了，也可以重建，配合好的缓冲机制的话，比TCP要实用多了
yutianzuijin 2011-10-18
- 打赏
- 举报
[Quote=引用 1 楼 afer198215 的回复:]
你确定这和tcp有关?
[/Quote]现在正在研究一个rdp协议的源码rdesktop。这个协议是基于tcp实现的。如果我们只进行一些简单的鼠标键盘操作，协议工作的很好。但是如果我们启动一个播放器的话，则协议是按照tcp来传递变化的帧的，所以才导致视频播放很卡。现在想解决这个问题，但是不知道如何解决，也不知道tcp和udp之间的性能差异到底有多大。
你确定这和tcp有关?
[/Quote]现在正在研究一个rdp协议的源码rdesktop。这个协议是基于tcp实现的。如果我们只进行一些简单的鼠标键盘操作，协议工作的很好。但是如果我们启动一个播放器的话，则协议是按照tcp来传递变化的帧的，所以才导致视频播放很卡。现在想解决这个问题，但是不知道如何解决，也不知道tcp和udp之间的性能差异到底有多大。
luciferisnotsatan 2011-10-18
- 打赏
- 举报
udp本身没有安全保障，视频丢几帧问题不大。但你先确定是tcp数据传的慢导致的，而不是你网络本身就慢。
想喝咖啡的貓 2011-10-18
- 打赏
- 举报
你确定这和tcp有关?
pathuang68 2011-10-18
- 打赏
- 举报
[Quote=引用 5 楼 yutianzuijin 的回复:]
引用 2 楼 luciferisnotsatan 的回复:
udp本身没有安全保障，视频丢几帧问题不大。但你先确定是tcp数据传的慢导致的，而不是你网络本身就慢。
我获得的数据是一帧变化的tcp帧是15k，如果要流畅播放至少也要有每秒30帧吧，带宽达不到。但是换成udp就能达到吗，我不是很清楚.
[/Quote]
1. 根本不需要秒30帧，一秒钟12帧就很流畅了
2. 传输前确认经过压缩了吗？
引用 2 楼 luciferisnotsatan 的回复:
udp本身没有安全保障，视频丢几帧问题不大。但你先确定是tcp数据传的慢导致的，而不是你网络本身就慢。
我获得的数据是一帧变化的tcp帧是15k，如果要流畅播放至少也要有每秒30帧吧，带宽达不到。但是换成udp就能达到吗，我不是很清楚.
[/Quote]
1. 根本不需要秒30帧，一秒钟12帧就很流畅了
2. 传输前确认经过压缩了吗？
yutianzuijin 2011-10-18
- 打赏
- 举报
[Quote=引用 15 楼 afer198215 的回复:]
RDP实际上只传输 改变的部分，除非你的整个画面全部改变，否则 根本不会有多大的图像。
我们存了近1小时的图片，不到300MB。
[/Quote]但现实情况是如果用户播放视频，则就会很卡，即使没有全屏播放。通过对接收的帧大小进行分析，发现在没有全屏的情况下播放视频一帧是15k，这证明传递的图像已经经过压缩了。但是图像的传递是基于rdp协议来的，但是rdp又是tcp上的一个应用，我个人感觉这是一个瓶颈。
RDP实际上只传输 改变的部分，除非你的整个画面全部改变，否则 根本不会有多大的图像。
我们存了近1小时的图片，不到300MB。
[/Quote]但现实情况是如果用户播放视频，则就会很卡，即使没有全屏播放。通过对接收的帧大小进行分析，发现在没有全屏的情况下播放视频一帧是15k，这证明传递的图像已经经过压缩了。但是图像的传递是基于rdp协议来的，但是rdp又是tcp上的一个应用，我个人感觉这是一个瓶颈。
想喝咖啡的貓 2011-10-18
- 打赏
- 举报
RDP实际上只传输 改变的部分，除非你的整个画面全部改变，否则 根本不会有多大的图像。
我们存了近1小时的图片，不到300MB。
我们存了近1小时的图片，不到300MB。
lida2003 2011-10-18
- 打赏
- 举报
[Quote=引用 13 楼 yutianzuijin 的回复:]
引用 12 楼 lida2003 的回复:
mstsc 远程播放电影确实比较卡的。哪怕局域网，我加100M带宽局域网，用mstsc播放，卡的一塌糊涂。
那大哥有什么解决之道吗？
[/Quote]
我看过进程管理的网络带宽，确实占用率不高。
如果我们不考虑视频压缩算法。仅仅是像素raw data传递。
1024 * 768 * 24位真彩色 = 2.25MB
如果是每秒30帧 2.25 * 30 = 67.5MB/s = 540Mb/s
也就说如果我们是raw data 传输24位真彩色 1024*768分辨率以30帧每秒的速率播放需要带宽至少540Mb/s，如果加上协议开销，也就说100M网卡完全不能胜任。怎么说也得来个千兆网络，注意不是网口千兆就可以的。网络需要千兆的。
当然如果视频能压缩，可能会好一点，至于具体rdp是如何工作，大家可以分析一下，如果视频不压缩，大部分网络性能肯定跟不上的。
一定要压缩的。
引用 12 楼 lida2003 的回复:
mstsc 远程播放电影确实比较卡的。哪怕局域网，我加100M带宽局域网，用mstsc播放，卡的一塌糊涂。
那大哥有什么解决之道吗？
[/Quote]
我看过进程管理的网络带宽，确实占用率不高。
如果我们不考虑视频压缩算法。仅仅是像素raw data传递。
1024 * 768 * 24位真彩色 = 2.25MB
如果是每秒30帧 2.25 * 30 = 67.5MB/s = 540Mb/s
也就说如果我们是raw data 传输24位真彩色 1024*768分辨率以30帧每秒的速率播放需要带宽至少540Mb/s，如果加上协议开销，也就说100M网卡完全不能胜任。怎么说也得来个千兆网络，注意不是网口千兆就可以的。网络需要千兆的。
当然如果视频能压缩，可能会好一点，至于具体rdp是如何工作，大家可以分析一下，如果视频不压缩，大部分网络性能肯定跟不上的。
一定要压缩的。
