音视频学习之rtsp推流学习1(rtspserver开源库example运行及流程梳理)

简介: 音视频学习之rtsp推流学习1(rtspserver开源库example运行及流程梳理)

工作需要实现一个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的逻辑,以及为后面做准备。

理论沉淀及参考

音视频相关理论学习及实践参考:推荐免费订阅

目录
相关文章
|
编解码 开发工具 数据安全/隐私保护
Windows平台RTMP直播推送集成简要说明
好多开发者在集成大牛直播SDK (官方)的Windows平台RTMP推送模块时吓一跳,怎么这么多接口?本文做个简单的拆分:
103 0
|
9月前
|
Web App开发 Windows
FFmpeg开发笔记(十五)详解MediaMTX的推拉流
MediaMTX是开源轻量级流媒体服务器,提供RTSP, RTMP, HLS, WebRTC和SRT服务。启动后,它在不同端口监听。通过FFmpeg的推拉流测试,证明了MediaMTX成功实现HLS流媒体转发,但HLS播放兼容性问题可能因缺少音频流导致。推流地址为rtsp://127.0.0.1:8554/stream,RTMP地址为rtmp://127.0.0.1:1935/stream,HLS播放地址为http://127.0.0.1:8888/stream(Chrome)和http://127.0.0.1:8888/stream/index.m3u8(其他播放器可能不支持)。
1043 2
FFmpeg开发笔记(十五)详解MediaMTX的推拉流
|
Web App开发 开发工具 Android开发
Android平台不需要单独部署流媒体服务如何实现内网环境下一对一音视频互动
我们在做内网环境的一对一音视频互动的时候,遇到这样的技术诉求:如智能硬件场景下(比如操控智能硬件),纯内网环境,如何不要单独部署RTMP或类似流媒体服务,实现一对一音视频互动。
109 0
直播软件开发如何使用FFMPEG推流并保存在本地
最近开发了基于C#的直播软件开发推流器一直不大理想,终于在不懈努力之后研究了一点成果,这边做个笔记;本文着重在于讲解下如何使用ffmpeg进行简单的推流,看似简单几行代码没有官方的文档很吃力。并获取流的源代码
|
6月前
|
Web App开发 Android开发
FFmpeg开发笔记(四十六)利用SRT协议构建手机APP的直播Demo
实时数据传输在互联网中至关重要,不仅支持即时通讯如QQ、微信的文字与图片传输,还包括音视频通信。一对一通信常采用WebRTC技术,如《Android Studio开发实战》中的App集成示例;而一对多的在线直播则需部署独立的流媒体服务器,使用如SRT等协议。SRT因其优越的直播质量正逐渐成为主流。本文档概述了SRT协议的使用,包括通过OBS Studio和SRT Streamer进行SRT直播推流的方法,并展示了推流与拉流的成功实例。更多细节参见《FFmpeg开发实战》一书。
100 1
FFmpeg开发笔记(四十六)利用SRT协议构建手机APP的直播Demo
|
9月前
|
Linux C++ iOS开发
VLC源码解析:视频播放速度控制背后的技术
VLC源码解析:视频播放速度控制背后的技术
719 0
|
Web App开发 缓存 算法
白话解读 WebRTC 音频 NetEQ 及优化实践
NetEQ 是 WebRTC 音视频核心技术之一,对于提高 VoIP 质量有明显的效果,本文将从更为宏观的视角,用通俗白话介绍 WebRTC 中音频 NetEQ 的相关概念背景和框架原理,以及相关的优化实践。
白话解读 WebRTC 音频 NetEQ 及优化实践
|
编解码 Java 开发工具
[技术分享]Android平台实时音视频录像模块设计之道
录像有什么难的?无非就是数据过来,编码保存mp4而已,这可能是好多开发者在做录像模块的时候的思考输出。是的,确实不难,但是做好,或者和其他模块有非常好的逻辑配合,确实不容易。
119 0
|
9月前
|
Windows
【音视频 学习 ffmpeg】环境准备
【音视频 学习 ffmpeg】环境准备

热门文章

最新文章