基于live555的rtsp播放器之二十：完结

草上爬

已于 2023-02-17 09:00:40 修改

阅读量5.9k

点赞数 7

分类专栏：基于live555的rtsp播放器文章标签： qt ffmpeg live555 sdl rtsp

于 2021-01-25 18:52:17 首次发布

本文链接：https://blog.csdn.net/caoshangpa/article/details/113131538

版权

基于live555的rtsp播放器专栏收录该内容

20 篇文章 ¥299.90 ¥399.90

订阅专栏

超级会员免费看

博主分享了基于live555实现的RTSP播放器的开发经验，包括实战心得和全网首发的ffmpeg录制功能。文章提到了在开发过程中参考VLC和得到流媒体专家的帮助，并展示了播放器的实际效果，与海康、大华客户端的延时和同步性能相当。讨论了UDP丢包问题，指出深入live555源码进行丢包处理的必要性，以及RTP over UDP和TCP模式的选择权衡。提供了相关链接供读者深入研究。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

这是我工作之余完成的第一个播放器，花了不少时间，也收获很多。
博客中很多内容都是亲身实践所得，有些内容甚至可以说是“全网首发 ”，比如网上多是ffmpeg拉流后ffmpeg录制，没搜到live555拉流ffmpeg录制的相关实现。
开发过程中，参考了许多开源项目，比如VLC中关于live555拉流部分；同时获得了公司流媒体大佬杰哥的大力支持，这里一并感谢！

简单流程图如下：

实际效果图：

延时和同步方面对比海康和大华的PC客户端毫不逊色。

专栏中并未提到UDP丢包问题，实测用海康摄像头wifi链接家里100M宽带，客户端使用RTP over UDP模式拉流时，会出现丢包。客户端使用VLC时也会丢包，出现马赛克现象，说明live555源码中并未对丢包做过多的预防处理。但是把丢包问题留给上层处理是非常不合适的，因为上层不好判断哪一包丢了。比较靠谱的方法是深入live555源码，根据RTP包序号来判断丢包。
不过话说回来，UDP是不可靠传输协议，媒体包在因特网上传输时必然会面临着丢包。使用UDP的目的就是实时性好，如果加上丢包处理，势必会影响实时性。
UDP丢包处理的目的是用画面卡顿的代价来取代马赛克，然而RTP over TCP模式在相同的网络中就是卡顿无马赛克，那为何不直接用这种模式呢。
关于RTP over UDP和RTP over TCP的比较可以参考：http://thompsonng.blogspot.com/2011/03/rtsp-rtp-over-tcp.html

PS：本专栏订阅后所有源码

原文链接：https://blog.csdn.net/caoshangpa/article/details/113131538