
基于live555的rtsp播放器
文章平均质量分 78
基于Qt、live555、FFmpeg、SDL、faac和soundtouch实现的rtsp播放器。跨平台,多路拉流,支持多种音视频编码格式,支持音视频录制为mp4,支持缓冲时间设置,支持GPU渲染。本专栏提供源码,订阅后留下邮箱。
草上爬
专注技术,热爱分享
展开
-
基于live555的rtsp播放器之二十:完结
这是我工作之余完成的第一个播放器,花了不少时间,也收获很多。博客中很多内容都是亲身实践所得,有些内容甚至可以说是“全网首发 ”,比如网上多是ffmpeg拉流后ffmpeg录制,没搜到live555拉流ffmpeg录制的相关实现。开发过程中,参考了许多开源项目,比如VLC中关于live555拉流部分;同时获得了公司流媒体大佬杰哥的大力支持,这里一并感谢!专栏中并未提到UDP丢包问题,实测用海康摄像头wifi链接家里100M宽带,客户端使用RTP over UDP模式拉流时,会出现丢包。客户端使用VL原创 2021-01-25 18:52:17 · 5840 阅读 · 21 评论 -
基于live555的rtsp播放器之十九:实现多路切换
二.实现为了控制视频的显示路数,通常需要做通道切换,这里提供了1通道+4通道+9通道+16通道,其他通道基本上不会用到,因为一般来说,超过9个通道实时显示视频流,建议采用子码流来显示,如果都采用主码流,解码压力大,CPU和内存都吃不消。不过随着CPU、显卡和内存的逐步升级,显示16个通道的实时视频已无压力。在Qt中,各种通道的切换可以用QGridLayout实现。每路视频封装成一个widget,初始化时,创建32个视频widget,设置每个widget的visible为false,并添原创 2021-01-25 18:48:34 · 4333 阅读 · 3 评论 -
基于live555的rtsp播放器之十八:G711a/G711u/G726转AAC
封装格式的主要作用是把视频码流和音频码流按照一定的格式存储在一个文件中。现如今流行的封装格式如下表所示:此表来自雷神:[总结]视音频编解码技术零基础学习方法,由表可见:1.除了AVI之外,其他封装格式都支持流媒体,即可以“边下边播”。有些格式更“万能”一些,支持的视音频编码标准多一些,比如MKV。而有些格式则支持的相对比较少,比如说RMVB。2.几乎所有封装格式都音频编码都支持AAC。雷神博客中还有关于AAC、MP3和WMA等主流音频编码格式的对比,对比结果表明在码率较低的情况下,不同编码方案原创 2021-01-25 13:01:34 · 4805 阅读 · 3 评论 -
基于live555的rtsp播放器之十七:ffmpeg硬解码
一.关于硬解1.目前的主流GPU加速平台INTEL、AMD、NVIDIA2.目前主流的GPU平台开发框架CUDA:NVIDIA的封闭编程框架,通过框架可以调用GPU计算资源AMD APP:AMD为自己的GPU提出的一套通用并行编程框架,标准开放,通过在CPU、GPU同时支持OpenCL框架,进行计算力融合。OpenCL:开放计算语言,为异构平台编写程序的该框架,异构平台可包含CPU、GPU以及其他计算处理器,目标是使相同的运算能支持不同平台硬件加速。Inel QuickSync:集成于Inte原创 2021-01-24 22:43:34 · 3584 阅读 · 1 评论 -
基于live555的rtsp播放器之十六:包含B帧的录制
一.包含B帧视频的特点上篇博文中提到过,视频中由于B帧需要双向预测,B帧依赖于其前和其后的帧,因此含B帧的视频解码顺序与显示顺序不同,即DTS与PTS不同。下图以一个开放式GOP示意图为例,说明视频流的解码顺序和显示顺序。采集顺序:指图像传感器采集原始信号得到图像帧的顺序。编码顺序:指编码器编码后图像帧的顺序。存储到磁盘的本地视频文件中图像帧的顺序与编码顺序相同。传输顺序:指编码后的流在网络中传输过程中图像帧的顺序。解码顺序:指解码器解码图像帧的顺序。显示顺序:指图像帧在显示器上显示的顺序。原创 2021-01-24 22:31:14 · 3365 阅读 · 4 评论 -
基于live555的rtsp播放器之十五:录制mp4
录制这里是指是音频和视频同步录制。一.使用ffmpeg录制的流程实现录制的方法有多种,我尝试成功过的有以下三种:1.使用mp4v2库录制mp4,这个库主要用于录制h264+AAC,多年未更新。如果要录制h265+AAC,需要自己改源码。官网地址:https://code.google.com/archive/p/mp4v22.使用gpac库录制mp4,这个库支持录制h264+AAC或h265+AAC,官网地址:https://gpac.wp.imt.fr3.使用ffmpeg4录制,毫无疑问,支原创 2021-01-24 22:20:33 · 4035 阅读 · 4 评论 -
基于live555的rtsp播放器之十四:使用soundtouch加速音频播放
一.soundtouchsoundtouch是一个用C++编写的开源的音频处理库,可以改变音频文件或实时音频流的节拍(Tempo)、音调(Pitch)、速率(Rate)。ST的3个效果互相独立,也可以一起使用。这些效果通过采样率转换、时域压拓结合实现。Tempo:通过时域压拓算法WSOLA,改变声音的播放速率而不影响音调,即变速不变调。Pitch:变调不变速时。Rate:变调也变速。主要特性跨平台:支持Windows、Mac OS、Linux、Android、Apple iOS等。完全开源:ST库原创 2021-01-17 08:55:03 · 3507 阅读 · 1 评论 -
基于live555的rtsp播放器之十三:音视频同步
一.音视频同步原理这里音视频同步包括两部分,一是网络接收时的音视频同步,二是音视频播放时的音视频同步。网络接收同步live555已经实现了,但是音视频播放同步得我们自己实现。1.live555音视频同步live555中视频和音频是分别进行编码的,接收时如何实现两者的同步呢?首先我们要了解RTP\RTSP协议中时间戳的获取。下面两幅图中,图一是RTP报文头格式,图二是RTCP返回的Sender Report(SR)包。live555内置的时间格式是timeval:struct timev原创 2021-01-15 21:36:18 · 4365 阅读 · 3 评论 -
基于live555的rtsp播放器之十二:使用QOpenGLWidget渲染yuv420p
一.GLSL VersionsIntroYou can use the#versioncommand as the first line of your shader to specify GLSL version:#version 120void main() { gl_FragColor = vec4(1.0);}GLSL versions are released alongside GL versions. See the following charts to ..原创 2021-01-15 21:04:49 · 3461 阅读 · 1 评论 -
基于live555的rtsp播放器之十一:使用SDL2或D3D9渲染yuv420p
一.音视频同步原理这里音视频同步包括两部分,一是网络接收时的音视频同步,二是音视频播放时的音视频同步。网原创 2021-01-15 19:54:02 · 3747 阅读 · 1 评论 -
基于live555的rtsp播放器之十:视频解码
一.软解与硬解基本定义:1、硬解指的是使用硬件GPU运行解码,通过调用GPU的专门模块编码进行解码,本质上依靠的是芯片,解码效果和兼容性受芯片(厂商)技术影响。2、软解即软件解码,它本质上依靠的是硬件的CPU性能处理能力,CPU性能越高解码效果越好。二者区别:1、功耗上:软解使用CPU解码,解码中对视频信息进行运算使得CPU负载过高,会导致高功耗、转换效率低、高发热等;而硬件的出现就是为了补充软解CPU占用过多导致卡顿的一种替代性方案,使用GPU解码,GPU独特的计算方法使得解码效率高、低功耗原创 2021-01-10 22:56:04 · 3688 阅读 · 2 评论 -
基于live555的rtsp播放器之九:使用SDL2播放音频
一.pcm文件准备找一个mp3文件,然后用FFmpeg命令将它转换成pcm文件,这里使用NorwayForest-500.mp3(挪威的森林-伍佰)。首先要使用ffmpeg查看mp3文件的一些信息,比如采样率、声道数等。ffmpeg -i NorwayForest-500.mp3从上图所示的信息,可以看到mp3文件采样率是44100Hz,双声道,在转换成pcm文件时要用到上面的信息。ffmpeg -i NorwayForest-500.mp3 -acodec pcm_s16le -f原创 2021-01-09 17:55:35 · 3186 阅读 · 1 评论 -
基于live555的rtsp播放器之八:音频重采样
一.什么是音频重采样音频重采样就是改变音频的采样率、采样格式、声道数等参数,使之按照我们期望的参数输出。比如我们将采样率 48kHz、采样格式 f32le、声道数 1 的音频 A 转换成采样率 44.1kHz、采样格式 s16le、声道数 2 的音频 B。那么为什么需要对音频重采样?列举一个经典用途,有些音频编码器对输入的原始PCM数据是有特定参数要求的,比如要求必须是44100_s16le_2。但是你提供的PCM参数可能是48000_f32le_1。这个时候就需要先将48000_f32le_1转换成原创 2021-01-08 19:44:24 · 3730 阅读 · 1 评论 -
基于live555的rtsp播放器之七:音频解码
一.初始化解码器void QHAudioDecoder::openDecoder(Format *format){ m_firstFrame=true; AVCodec *codec = avcodec_find_decoder((AVCodecID)format->codecID); if (!codec) { std::cout <<"audio codec not found"<< std::endl; }原创 2021-01-05 13:04:07 · 3310 阅读 · 1 评论 -
基于live555的rtsp播放器之六:断网重连
live555原生不支持断网重连,需要客户端自己实现。我的实现方法是,在sendPlayCommand的回调函数中启动超时处理函数,函数中通过延时任务每秒钟调用自己一次,并累加检测次数值,当检测次数达到超时时间时,认为网络异常,释放所有live555资源,并重启会话。在音视频数据接收时,需要调用网络检测函数,该函数中重置检测次数值为0,这样的话,当接收不到数据时,检测次数值就会一直累加。下面是超时处理函数:void networkTimeoutHandler(void *clientData){原创 2021-01-03 20:23:56 · 4808 阅读 · 1 评论 -
基于live555的rtsp播放器之五:数据接收时应该注意的问题
一.h264中的I、P和B帧I-帧:也成为关键帧,I-帧完全自我指涉的,并且不使用任何其他帧的信息。它在三种帧中占最大的比例,并且具有最高的质量,但是压缩效率是最低的。P-帧:P-帧是所谓的“预测”帧。当创建了一个P-帧时,编码器可以向后查看I-帧或者P-帧中冗余的图片信息。P-帧比I-帧效率高,但是没有B-帧的效率高。B-帧:B-帧是双向预测帧,这意味着当我们创建B-帧,编码器可以同时向前和向后查找冗余的图片信息。这使得B-帧在三种帧中具备最佳的效率。注意,B-帧在使用Baseline方式生产视频原创 2021-01-02 23:15:28 · 3761 阅读 · 2 评论 -
基于live555的rtsp播放器之四:视频数据接收
一.h264中的I、P和B帧原创 2021-01-02 22:09:47 · 3992 阅读 · 1 评论 -
基于live555的rtsp播放器之三:音频数据接收
live555客户端的研究都是从源码中的testRTSPClient例子开始的,这个例子包含了RTSP消息交互和数据接收。一.RTSP消息交互一次基本的RTSP操作过程如下:C表示RTSP客户端,S表示RTSP服务端1.第一步:查询服务器端可用方法C->S:OPTION request //询问S有哪些方法可用S->C:OPTION response //S回应信息的public头字段中包括提供的所有可用方法2.第二步:得到媒体描述信息C->...原创 2021-01-01 20:07:02 · 4898 阅读 · 8 评论 -
基于live555的rtsp播放器之二:开发环境配置
一.MacOS Mojave 10.14 64位系统开发环境配置1.安装brewbrew是Mac下的一个包管理工具,作用类似于centos下的 yum、ubuntu下的apt-getbrew可以用一条命令,就可以在mac上安装、卸载、更新各种软件包,因为brew的使用方便,如今已成为使用mac电脑的程序员的必备工具。先查看自己电脑上安装没:brew -v如果没安装,则安装:/bin/zsh -c "$(curl -fsSL https://gitee.com/cunkai/Home原创 2020-12-23 22:21:24 · 3948 阅读 · 1 评论 -
基于live555的rtsp播放器之一:开篇
很久没写博客了,今天准备开始接着写。一直以来对音视频这块都比较感兴趣,从我博客中可以看出,很久之前就开始学习WebRTC,并且转发了一些流媒体的文章,而目前的工作正好是做直播客户端的相关开发,加上由于年初疫情,隔离在家,时间比较充裕,于是又捡起了心中所好。说起rtsp,自然会想到开源的跨平台流媒体框架live555。live555兼容的摄像机种类多,文档丰富,而且大名鼎鼎的VLC播放器中关于rtsp的推拉流使用的就是live555,因此决定撸起袖子从VLC源码看起.......转眼间,一年就快过去了,原创 2020-12-21 21:33:50 · 5583 阅读 · 3 评论