工作需要实现一个rtsp的推流拉流业务流程，对开源项目rtspserver进行学习及理解。
参考系列rtspserver的文章：我的开源项目-RtspServer_JT同学的博客-CSDN博客_rtsp server
建立在个人对rtsp推流流程有一定理解的基础上，本文目的是通过开源库rtspserver实现推流，了解一下这个库，运行该库下相关demo，对理论做实践。
1：搭建环境
# git clone git@github.com:ImSjt/RtspServer.git #这里我是直接在github上下载的源码包解压 hlp@ubuntu:~/rtsp$ cd RtspServer-master/ hlp@ubuntu:~/rtsp/RtspServer-master$ ls example Makefile objs pic README.md src test hlp@ubuntu:~/rtsp/RtspServer-master$ make #执行make进行编译
2：运行example
使用make后，在example目录下会生成一些列的测试可执行程序，直接对可执行程序进行运行测试：
这里的测试方案：
1：使用测试代码，使用rtsp进行推流。
2：使用vlc进行拉流播放，音频/视频/alsa采集/摄像头采集依次测试
2.1：example之测试音频aac文件
2.1.1：rtspserver运行example推流aac文件 （作为服务端使用rtsp推流）
hlp@ubuntu:~/rtsp/RtspServer-master/example$ ./aac_rtsp_server test.aac Play the media using the URL "rtsp://192.168.0.110:8554/live"
2.1.2：同时，使用vlc进行拉流测试，分别使用默认udp和tcp进行测试
在偏好设置中，分别测试udp和tcp的逻辑。
选择tcp进行测试，如上图，使用抓包工具分析，简单看看协议，先不关注协议流程（rtsp，sdp，rtp，rtcp）协议的含义.大体分析
2.1.3：使用tcp进行测试，如上图选择：
使用wireshark对tcp流程进行抓包：
简单分析和观察，查看报文细节：
1：观察流程：可以发现在tcp的基础上，是rtsp进行交互，其中有看到sdp协商报文，最后通过rtp进行实际流的传输
2：观察每种报文的端口，发现这里所有的流都用的服务器的8554端口
3：这里本应该还有rtcp流，
2.1.4：使用udp进行测试，取消上图得选项，默认就是udp。
简单分析wireshark报文,会发现
1：rtsp报文进行交互控制，sdp进行媒体协商，最后再通过rtsp确定了rtp和rtcp使用方式是udp并且端口是64164~64165
2：会发现实际数据传输用的udp协议(rtp基于udp进行），rtp用得端口64164
3：发现有rtcp报文，用的64165端口
2.1.5：结果：
使用vlc工具进行拉流测试得，点击媒体==》打开网络串流==》
使用这个开源库进行推流和拉流测试时，明显的发现音频播放是卡断的，简单看源码应该于文件得读取发送定时器方案有关。
2.2：example之测试图像h264文件，无音频
2.2.1：服务端启动推流，推送h264视频文件
hlp@ubuntu:~/rtsp/RtspServer-master/example$ ./h264_rtsp_server test.h264 Play the media using the URL "rtsp://192.168.0.110:8554/live"
2.2.2：首先是偏好设置设为tcp，使用vlc进行拉流播放，同时抓流进行查看：
简单分析查看：
1：rtsp进行流程控制交互（基于tcp，端口8554），经过sdp媒体协商，流程后，使用rtp（基于tcp，同样8554）端口进行数据传输。
2：vlc进行拉流播放，能正常现实视频图像，但是会发现等待时间明显过长，（图像资源得显示问题）
2.2.3：偏好设置为udp，使用vlc进行拉流，抓包看看udp得逻辑：
简单查看分析后：
1：rtsp贯穿整个流程控制协议得交互，rtp报文是实际数据流得数据，rtcp报文是rtp控制报文，sdp是媒体协商报文
2：这里大概分析逻辑，可以发现使用udp作为rtp底层协议时，有端口得协商，后面rtp/rtcp的传输基于这里的端口。
3：视频播放延迟过高。
2.3：example之测试视频aac+h264
2.3.1：rtspserver服务端运行测试demo
hlp@ubuntu:~/rtsp/RtspServer-master/example$ ./h264_aac_rtsp_server test.h264 test.aac Play the media using the URL "rtsp://192.168.0.110:8554/live"
2.3.2：首先偏好设置为tcp，使用vlc进行拉流测试，抓包简单查看：
简单分析：
1：rtsp协议进行控制报文，进行传输数据前的相关控制交互逻辑，媒体协商sdp，协商rtp用的传输方式是tcp
2：可以看到，有图像和音频的时候，实际传输的时候有两个类型96和97
2.3.3：设置偏好设置为udp，使用vlc进行拉流测试，抓包进行查看：
简单分析后：
1：rtsp进行协议控制以及相关协商，除了sdp协商外，还有相关流的端口协商。
2：这里使用的是基于udp的rtp传输方式，这里如图，可以看到有两次的流端口协商。
第一次的流track协商：
可以看到，video流编号对应96的rtp包用了该端口，其对应的rtcp用了56401端口
从sdp媒体协商中可以看到：vedio 是96 audio是97
另外一个audio对应的端口协商是另一个报文，同样的逻辑。
2.4：example测试之使用alsa采集音频测试
以前使用linux虚拟机播放音频文件时，使用过alsa，可以用alsa基于linux实现音频的播放或者采集。
以前使用alsa实现播放aac,mp3,wav文件的测试，做过一些基础整理：音频播放的一些整理_yun6853992的博客-CSDN博客
sudo apt-get install libasound2-dev sudo apt-get install libfaac-dev #修改rtsp库makefile： ALSA_SUPPORT=y make #执行测试用例 root@ubuntu:/home/hlp/rtsp/RtspServer-master/example# ./alsa_rtsp_server hw:0,0 Play the media using the URL "rtsp://192.168.0.110:8554/live" 2022-01-13 00:22:20 <WARNING> /home/hlp/rtsp/RtspServer-master/src/extend/alsa/AlsaMediaSource.cpp:readFrame:57 overrun occurred
使用vlc进行拉流：
发现可以听到采集到的音频数据
2.5：example测试之使用V4L2采集摄像头测试
没用过，试试：
2.5.1：安装x264:
以前整理过linux上ffmpeg以及相关音频库的安装方式，可以参考：音视频linux环境安装ffmpeg_yun6853992的博客-CSDN博客
wget https://www.nasm.us/pub/nasm/releasebuilds/2.14.02/nasm-2.14.02.tar.bz2 tar xjvf nasm-2.14.02.tar.bz2 cd nasm-2.14.02/ sudo apt-get install autoconf ./autogen.sh ./configure make sudo make install wget https://www.nasm.us/pub/nasm/releasebuilds/2.14.02/nasm-2.14.02.tar.bz2 tar xjvf nasm-2.14.02.tar.bz2 ./configure ./configure --enable-shared --enable-static #这一步非常重要 make sudo make install #./v4l2_rtsp_server: error while loading shared libraries: libx264.so.164: cannot open shared object file: No such file or directory sudo vi /etc/ld.so.conf #增加/usr/local/lib sudo /sbin/ldconfig
2.5.2：运行测试demo，
修改makefile，V4L2_SUPPORT=y
执行make后，example目录下生成测试可执行文件v4l2_rtsp_server
这里使用虚拟机server测试，流程及逻辑已经打通，可以用桌面版虚拟机测试。
3：总结
rtspserver实现了推送给本地aac，h264, 使用摄像头采集图像，使用alsa采集音频的功能。
因为接触过一些音视频的基础，感觉基本测试demo能成功，但是更偏向于demo，需要一定的调优。
做练习仅仅为了巩固自己的理论知识，以及梳理rtsp的逻辑，以及为后面做准备。
理论沉淀及参考
音视频相关理论学习及实践参考：推荐免费订阅
