RTSP 和 RTMP原理 & 通过ffmpeg实现将本地摄像头推流到RTSP服务器
RTSP 和 RTMP原理 & 通过ffmpeg实现将本地摄像头推流到RTSP服务器
文章目录
一、流媒体:RTSP 和 RTMP
0、参考资料
1、RTSP 和 RTMP的工作原理
1)RTSP工作原理
-
用户设备向视频流平台发送 RTSP 请求
-
视频流平台返回可以操作的请求列表,比如播放、暂停等
-
用户设备向视频流平台发送具体的请求,比如播放
-
视频流平台解析请求并调用指定机制启动视频流处理
-
由于 RTSP 依赖于专用服务器,并且依赖于 RTP(底层用到了UDP),因此该协议不支持加密视频内容或重传丢失的数据包。
这里解释一下
RTSP
中是如何用到UDP
和TCP
的:-
RTP协议,英文全称:Real-time Transport Protocol,中文就是实时传输协议,它的底层其实就是UDP,这样一来就可以实现低延迟。
-
除了RTP协议,为确保流畅和一致的流传输,RTSP 还使用另外两种网络通信协议:
TCP
收发控制命令(例如播放或停止请求):TCP可靠传输,比如用户按下播放或者停止播放的时候,这个是个准确的请求,这个需要保证可靠性,这个时候TCP作用就体现了。UDP
传送音频、视频和数据:UDP是低延迟的协议,那么用于传送音频、视频和数据可以达到非常高效的效果。
-
这里可以通过开源的rtsp服务器可以简单理解:TCP
监听端口为8554,UDP
监听端口为8000
2)RTMP工作原理
-
摄像头捕获视频
-
通过编码器将视频流传输到视频平台服务器
-
视频平台处理视频流
-
通过CDN分发到离用户最近的服务器上
-
最后视频流就能成功的到达用户设备
在视频从摄像头到服务器的过程中,RTMP将大量数据分割成小块并跨多个虚拟通道传输(内容分发网络CDN),在视频源和 RTMP 服务器之间提供了稳定和流畅的视频流。
2、RTSP 和 RTMP的优缺点
1)RTSP的优缺点
-
RTSP的优点:
轻松自定义流:可以通过结合不同的协议来开发自己的视频流解决方案。
分段流式传输:RTSP 流使观看者能够在下载完成之前访问的视频内容,而不必下载完整的视频以流式传输内容。
-
RTSP的缺点:
与 HTTP不兼容:没有简单的解决方案可以在 Web 浏览器中播放 RTSP流,因为 RTSP 旨在通过私有网络流式传输视频,必须借用额外软件。
使用率低:由于视频播放器和流媒体服务并未广泛支持 RTSP 流媒体,因为使用率比较低。
2)RTMP的优缺点
-
RTMP的优点:
低延迟:RTMP使用独占的 1935 端口,无需缓冲,可以实现低延迟。
适应性强:所有 RTMP 服务器都可以录制直播媒体流,同时还允许观众跳过部分广播并在直播开始后加入直播流。
灵活性:RTMP 支持整合文本、视频和音频,支持
MP3
和AAC
音频流,也支持MP4、FLV
和F4V
视频。 -
RTMP的缺点:
HTML5 不支持:标准HTML5 播放器不支持 RTMP 流。
容易受到带宽问题的影响:RTMP 流经常会出现低带宽问题,造成视频中断。
HTTP 不兼容:无法通过 HTTP 流式传输 RTMP,必须需要实现一个特殊的服务器,并使用第三方内容交付网络或使用流媒体视频平台。
3)RTSP和RTMP的比较
RTMP 和 RTSP协议 都是流媒体协议:
- RTMP(Real Time Message Protocol 实时消息传递协议) 有 Adobe 公司提出,用来解决多媒体数据传输流的多路复用(Multiplexing)和分包(packetizing)的问题,优势在于低延迟,稳定性高,支持所有摄像头格式,浏览器加载
flash
插件就可以直接播放。 - RTSP (Real-Time Stream Protocol 实时流协议)由Real Networks 和 Netscape共同提出的,基于文本的多媒体播放控制协议。RTSP定义流格式,流数据经由RTP传输;RTSP实时效果非常好,适合视频聊天,视频监控等方向。
RTMP 和 RTSP协议 的区别:
-
RTSP虽然实时性最好,但是实现复杂,适合视频聊天和视频监控;
-
RTMP强在浏览器支持好,加载flash插件后就能直接播放,所以非常火,相反在浏览器里播放rtsp就很困难了。
3、RTSP和RTMP如何选择
-
IP 摄像机选择RTSP:几乎所有 IP 摄像机都支持 RTSP,这是因为 IP 摄像机早在 RTMP 协议创建之前就已经存在,与 RTSP 和 IP 摄像机结合使用时,IP 摄像机本身充当 RTSP 服务器,这意味着要将摄像机连接到 IP 摄像机服务器并广播视频。
-
物联网设备选择RTSP:RTSP 通常内置在无人机或物联网软件中,从而可以访问视频源,它的好处之一是低延迟,确保视频中没有延迟,这对于无人机来说至关重要。
-
流媒体应用程序选择RTMP:比如各种短视频软件、视频直播软件等都内置了RTMP,RTMP 是为满足现代流媒体需求而设计的。
4、如何在浏览器上播放RTSP
-
直播的协议有:
rtmp
,http
,rtsp
等等。最常用的有二种:http, rtmp,当使用http
协议的时候视频格式需要是m3u8
或flv
,下面作详细说明各种环境的优缺点。首先,rtsp
不能使用于网页环境(包含PC端和移动端),那么直播只能选择rtmp
或http
。 -
rtmp
协议只支持flashplayer
,也就是只能在PC端(或安卓环境中安装了flashplayer组件,这种环境比较少)安装了flashplayer
的情况下使用。按现在的趋势,flashplayer
是要逐渐被淘汰掉的。当然,在中国还会存在相对长时间。 -
http
协议的直播分二种格式,m3u8
和flv
。flv
是一种即将被淘汰的直播格式。用来做直播已显的力不从心了。所以综合考虑,m3u8
相对的比较好点,优点是支持移动端,并且支持PC端上安装了flashplayer的环境。缺点就如同rtmp
一样。flashplayer并不是未来的发展趋势。另外一个缺点就是m3u8
是有延迟的。并不能实时,实时传输方面不如rtmp协议。因为m3u8
的直播原理是将直播源不停的压缩成指定时长的ts
文件(比如9秒,10秒一个ts文件)并同时实时更新m3u8文件里的列表以达到直播的效果。这样就会有一个至少9,10秒的时间延迟。如果压缩的过小,可能导致客户端网络原因致视频变卡。实现
rtsp
转http
并使用m3u8
格式进行直播 可以参考RTSP Webcam to HLS Live Streaming using FFMPEG and XAMPP | PART 1具体过程:外接支持
rtsp
的webcam
;使用ffplay
命令来播放rtsp流,可以根据参数将实时视频写入到指定文件夹中(分段写入);xampp
开启apache(开启80端口),可以让页面通过保存的m3u8
文件实时访问webcam
的监控界面。
二、ffmpeg将本地摄像头推流到RTSP服务器
0、ffmpeg
参考资料
- FFmpeg Protocols Documentation
- FFmpeg中文文档
- FFmpeg流媒体处理-收流与推流
- FFmpeg发送流媒体的命令(UDP,RTP,RTMP)
- ffmpeg将本地摄像头推流到RTSP服务器
Note:ffmpeg
将本地摄像头推流到rtsp
的8554
端口上(rtsp-simple-server
在处理rtsp
时,监听的是8554
端口,指定其他端口ffmpeg
推流会失败)
1、安装ffmpeg
和rtsp-simple-server
大致实现过程:使用
rtsp-simple-server
作为中转服务器,用于ffmpeg
(写客户端)推流,后台服务(读客户端)拉流
1)windows安装rtsp-simple-server
和ffmpeg
参考windows环境下,搭建RTSP视频推流服务器即可(记得修改rtsp-simple-server.yml
配置文件中的ip地址)
2)linux安装rtsp-simple-server
和ffmpeg
-
安装rtsp-simple-server_v0.20.2_linux_amd64.tar.gz(这里以x86 CPU为例),解压后修改
rtsp-simple-server.yml
配置文件中的ip地址(vim
替换命令为%s:/127.0.0.1/192.168.132.100/g
),执行./rtsp-simple-server
即可启动rtsp服务器。如果要想在后台启动
rtsp
服务器,执行如下命令nohup ./rtsp-simple-server >> rtsp_server.log 2>&1 & #非挂起启动命令tail rtsp_server.log #查看rtsp-simple-server启动日志文件ps -aux | grep rtsp_simple_server #查看rtsp-simple-server进程dpf 2116 0.0 0.0 13140 1016 pts/0 S+ 04:54 0:00 grep --color=auto rtsp_simple_server
-
ffmpeg
安装地址如下https://johnvansickle.com/ffmpeg/,解压后执行./ffmpeg
即可使用ffmpeg
,参考在linux下使用ffmpeg方法
Note:在linux中关于tar.gz
,xz
,tar
的解压操作请自行上网查阅。
2、将本地摄像头推流到RTSP服务器
大致实现过程:使用
rtsp-simple-server
作为中转服务器,用于ffmpeg
(写客户端)推流,后台服务(读客户端)拉流
这里以windows系统作为演示,先解压rtsp-simple-server_v0.19.1_windows_amd64.zip,打开rtsp-simple-server.exe
监听RTSP下TCP的8554端口,然后通过ffmpeg将指定摄像头采集到的图像帧向该端口进行推流(即多个客户端与服务器端的socket通信)
1)写客户端:ffmpeg
-
ffmpeg
推流视频文件到指定ip + 端口上(-stream_loop -1
):ffmpeg -re -stream_loop -1 -i 你视频的文件名 -c copy -f rtsp rtsp://127.0.0.1:8554/videoFile_test
-
ffmpeg
将本地摄像头的视频流推送到指定ip + 端口上,则需要//获取本地摄像头名称ffmpeg -list_devices true -f dshow -i dummy //ffmpeg向指定端口推流(我的是Integrated Camera)ffmpeg -f dshow -i video="自己的摄像头驱动名称" -vcodec libx264 -preset:v ultrafast -tune:v zerolatency -rtsp_transport tcp -f rtsp rtsp://127.0.0.1:8554/camera_test//libx264编码ffmpeg -f dshow -i video="Integrated Camera" -vcodec libx264 -preset:v ultrafast -tune:v zerolatency -rtsp_transport tcp -f rtsp rtsp://127.0.0.1:8554/camera_test
2)服务器端:RTSP服务器
-
初启动效果如下:
-
开启两个
ffmpeg
模拟两个写客户端,完成摄像头采集视频帧的推流和本地视频文件的推流该过程会出现两个
createby
和publishing
,在不同文件路径下写入图像帧,可以通过指定进程(ip+端口)来处理(这里新创建了56725
和56732
两个进程来处理),而RTSP的监听端口仍然是8554
,这样可以实现非阻塞通信。
3)读客户端:读客户端可以通过两种方式来实现
-
安装VLC,选择流数据播放模式,输入
rtsp://127.0.0.1:8554/camera_test
,rtsp://127.0.0.1:8554/videoFile_test
即可播放; -
亦或者使用如下python代码:
import cv2def capture_video(rtsp_path): name = rtsp_path.split("/")[-1] capture = cv2.VideoCapture(rtsp_path) while capture.isOpened(): ret, frame = capture.read() if not ret: break cv2.imshow(name, frame) if cv2.waitKey(50) == 27: breakif __name__ == '__main__': # rtsp_paths = ['rtsp://127.0.0.1:8554/videoFile_test','rtsp://127.0.0.1:8554/camera_test'] rtsp_paths = ['rtsp://127.0.0.1:8554/videoFile_test'] for rtsp_path in rtsp_paths: capture_video(rtsp_path) cv2.waitKey(0) cv2.destroyAllWindows()
此时会出现两个createby
和reading
,即开启两个进程进行视频流的读取
3、存在问题:视频读取时延大
基于tcp
和RTP
的rtsp直播延迟很高,一开始延迟只有7s,由于TCP的拥塞控制,导致随着时间推移,延迟越来越高,有14s之多。
1)可能原因1:视频编码导致延迟高(亲测效果不明显)
参考ffmpeg直播解决延时的关键方法,主要原因是使用libx264
或者h264
对视频进行编码的问题。
解决方法参考ffmpeg–使用命令+EasyDarwin推流笔记本摄像头
//h264_qsv编码(比libx264编码快点)ffmpeg -f dshow -i video="Integrated Camera" -vcodec h264_qsv -tune:v zerolatency -rtsp_transport tcp -f rtsp rtsp://127.0.0.1:8554/camera_test//不使用编码器,直接推送(但是很模糊)ffmpeg -f dshow -i video="Integrated Camera" -rtsp_transport tcp -f rtsp rtsp://127.0.0.1:8554/camera_test
2)可能原因2:设置ffmpeg
参数(亲测效果不明显)
参考解决ffmpeg的播放摄像头的延时优化问题(项目案例使用有效) _
原参数:
-vcodec libx264,-r 25,-video_size 1280x720,
优化参数1:
-tune zerolatency //设置零延时-preset ultrafast //--preset的参数主要调节编码速度和质量的平衡,有ultrafast(转码速度最快,视频往往也最模糊)、superfast、veryfast、faster、fast、medium、slow、slower、veryslow、placebo这10个选项,从快到慢
优化参数2:
-threads 4,-c:a copy,-fflags nobuffer,-max_delay 1,-vprofile baseline,-rtsp_transport tcp,-crf 30,-vsync 2,-f flv
ffmpeg
完整命令如下:
ffmpeg -f dshow -i video="Integrated Camera" -vcodec libx264 -r 25 -video_size 640x480 -tune:v zerolatency -preset:v ultrafast -threads 4 -c:a copy -fflags nobuffer -max_delay 1 -rtsp_transport tcp -crf 30 -vsync 2 -f flv -f rtsp rtsp://127.0.0.1:8554/camera_test
3)可能原因3:tcp连接导致延迟高
参考RTSP end to end latency will be increasing when use tcp #902
ffmpeg
在通过rtsp实现推流时默认是遵循tcp协议的,目的是为了保证消息可靠传输。对于实时音视频通信,如果要想实现低延迟,要么增加带宽,要么使用UDP进行传输。
4)原因4:逐帧读取时需要逐帧解码,导致输入和输出速率不匹配导致延迟高(有效 - 抽帧读取)
解决方法:对于读客户端,采用抽帧读取的方法来解决。如果采用逐帧读取并完成解码的方式,会让写客户端不停地推流,而读客户端来不及解码导致缓存区拥塞。
参考Opencv—视频跳帧处理,OpenCV笔记:cv2.VideoCapture 完成视频的跳帧输出操作
ffmpeg
写客户端命令无需修改:
//获取本地摄像头名称ffmpeg -list_devices true -f dshow -i dummyffmpeg -f dshow -i video="Integrated Camera" -vcodec libx264 -r 25 -video_size 640x480 -tune:v zerolatency -preset:v ultrafast -threads 4 -c:a copy -fflags nobuffer -max_delay 1 -rtsp_transport tcp -crf 30 -vsync 2 -f flv -f rtsp rtsp://127.0.0.1:8554/camera_test
python读客户端代码修改如下:
def capture_video(rtsp_path): name = rtsp_path.split("/")[-1] capture = cv2.VideoCapture(rtsp_path) #不用带cv2.CAP_DSHOW now_fps = 0 while capture.isOpened(): # 设置每 10 帧输出一次 if (now_fps == 3): now_fps = 0 ret, frame = capture.read() if not ret: break cv2.imshow(name, frame) if cv2.waitKey(50) == 27: break else: # 跳帧,仅获取帧但不做解码处理 ret = capture.grab() now_fps += 1
来源地址:https://blog.csdn.net/qq_33934427/article/details/128009659
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341