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

2011-10-18 10:43:14 1.3k 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

树莓派视频传输的协议选择：UDP vs TCP vs MJPEG-Streamer深度对比本文深入对比了树莓派视频传输中UDP、TCP和MJPEG-Streamer三种协议的性能差异，提供了详细的实测数据和选型建议。针对不同应用场景如家庭安防、工业巡检和远程教育，推荐最优协议方案，并分享高级优化技巧。特别适合需要低延迟视频传输的开发者参考，帮助在资源受限的树莓派上实现高效视频流传输。阅读详情

最近看一个项目，里面的机制由于协议原因视频的传输采用了tcp，所以视频观看很卡。求教如果采用udp会有多大的提升？

...全文

Unity集成阿里云语音AI：从麦克风录音到实时语音合成的全流程实现本文详细介绍了在Unity中集成阿里云语音AI服务，实现从麦克风录音到实时语音合成的完整流程。通过调用阿里云的语音转文字和文字转语音接口，开发者可以快速为游戏或应用添加语音交互功能，提升用户体验。文章涵盖了环境配置、签名认证、音频处理及项目集成等核心步骤，并提供了实用的调试技巧。阅读详情

yutianzuijin

领域专家: 算法与数据结构技术领域

C语言 70,040 成员 243,237 内容

+ 关注 + 加入社区

切换为时间正序

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是如何工作，大家可以分析一下，如果视频不压缩，大部分网络性能肯定跟不上的。

一定要压缩的。

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

相关推荐