TCP和UDP视频传输的性能差异有多大?

yutianzuijin
博客专家认证
2011-10-18 10:43:14
最近看一个项目,里面的机制由于协议原因视频的传输采用了tcp,所以视频观看很卡。求教如果采用udp会有多大的提升?
...全文
1170 17 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
17 条回复
切换为时间正序
请发表友善的回复…
发表回复
yutianzuijin 2011-10-18
  • 打赏
  • 举报
回复
[Quote=引用 12 楼 lida2003 的回复:]

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的,这点我非常确定。
qq120848369 2011-10-18
  • 打赏
  • 举报
回复
楼主下载一个UDT源码去了解一下,UDT做视频传输流弊死。
想喝咖啡的貓 2011-10-18
  • 打赏
  • 举报
回复
rdesktop啊,基本可以肯定的告诉你,跟TCP无关,因为这个东西 我用过,我们项目里采用的是java版的rdesktop。

查查你们的播放器实现吧。

另外,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做个检测机制,但速度估计也快不了多少。
yujie_v 2011-10-18
  • 打赏
  • 举报
回复
udp关键考虑实时性的。tcp丢包重传,这个是无法控制的。
yutianzuijin 2011-10-18
  • 打赏
  • 举报
回复
[Quote=引用 2 楼 luciferisnotsatan 的回复:]

udp本身没有安全保障,视频丢几帧问题不大。但你先确定是tcp数据传的慢导致的,而不是你网络本身就慢。
[/Quote]我获得的数据是一帧变化的tcp帧是15k,如果要流畅播放至少也要有每秒30帧吧,带宽达不到。但是换成udp就能达到吗,我不是很清楚.
辰岡墨竹 2011-10-18
  • 打赏
  • 举报
回复
rdesktop应该不是传输像传输视频那样传输的,它使用的是差分压缩的方法,所以必须使用TCP来保证传输的有效性,否则差分压缩就不成立了。
真正实时视频基本上都是用UDP的,因为像MPEG分为I帧、B帧什么的,即使中间帧丢失,只要下一个关键帧来了,也可以重建,配合好的缓冲机制的话,比TCP要实用多了
yutianzuijin 2011-10-18
  • 打赏
  • 举报
回复
[Quote=引用 1 楼 afer198215 的回复:]

你确定这和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. 传输前确认经过压缩了吗?
yutianzuijin 2011-10-18
  • 打赏
  • 举报
回复
[Quote=引用 15 楼 afer198215 的回复:]

RDP实际上只传输 改变的部分,除非你的整个画面全部改变,否则 根本不会有多大的图像。
我们存了近1小时的图片,不到300MB。
[/Quote]但现实情况是如果用户播放视频,则就会很卡,即使没有全屏播放。通过对接收的帧大小进行分析,发现在没有全屏的情况下播放视频一帧是15k,这证明传递的图像已经经过压缩了。但是图像的传递是基于rdp协议来的,但是rdp又是tcp上的一个应用,我个人感觉这是一个瓶颈。
想喝咖啡的貓 2011-10-18
  • 打赏
  • 举报
回复
RDP实际上只传输 改变的部分,除非你的整个画面全部改变,否则 根本不会有多大的图像。
我们存了近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是如何工作,大家可以分析一下,如果视频不压缩,大部分网络性能肯定跟不上的。

一定要压缩的。

70,022

社区成员

发帖
与我相关
我的任务
社区描述
C语言相关问题讨论
社区管理员
  • C语言
  • 花神庙码农
  • 架构师李肯
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧