live555

一.效果 二.实现 为了控制视频的显示路数，通常需要做通道切换，这里提供了1通道+4通道+9通道+16通道，其他通道基本上不会用到，因为一般来说，超过9个通道实时显示视频流，建议采用子码流来显示，如果都采用主码流，解码压力大，CPU和内存都吃不消。不过随着CPU、显卡和内存的逐步升级，显示16个通道的实时视频已无压力。 在Qt中，各种通道的切换可以用QGridLayout实现。每路视频封装成一个widget，初始化时，创建32个视频widget，设置每个widget的visible为false，并添加到列表中。然后把列表中index为0的widget添加到QGridLayout，并设置该widget的visible为true。这样的话界面启动后默认显示一路视频。 m_gridLayout=new QGridLayout(); m_gridLayout->setSpacing(2); for(int i=0;i<MAX_CAMERA_COUNT;i++) { VideoWidget *videoWidget=new VideoWidget(this); connect(videoWidget,&VideoWidget::signalStreamStarted,this,&QHMainWidget::slotStreamStarted); connect(videoWidget,

这是我工作之余完成的第一个软件，全凭爱好坚持下来，花了不少时间，也收获很多。 博客中很多内容都是亲身实践所得，有些内容甚至可以说是“全网首发 ”，比如网上多是ffmpeg拉流后ffmpeg录制，没搜到live555拉流ffmpeg录制的相关实现。 开发过程中，参考了许多开源项目，比如VLC中关于live555拉流部分；同时获得了公司流媒体大佬的大力支持，这里一并感谢！ 专栏中并未提到UDP丢包问题，实测用海康摄像头wifi链接家里100M宽带，客户端使用RTP over UDP模式拉流时，会出现丢包。客户端使用VLC时也会丢包，出现马赛克现象，说明live555源码中并未对丢包做过多的预防处理。但是把丢包问题留给上层处理是非常不合适的，因为上层不好判断哪一包丢了。比较靠谱的方法是深入live555源码，根据RTP包序号来判断丢包。 不过话说回来，UDP是不可靠传输协议，媒体包在因特网上传输时必然会面临着丢包。使用UDP的目的就是实时性好，如果加上丢包处理，势必会影响实时性。 UDP丢包处理的目的是用画面卡顿的代价来取代马赛克，然而RTP over TCP模式在相同的网络中就是卡顿无马赛克，那为何不直接用这种模式呢。 因此，个人觉得无特殊要求的话，这里没必要处理UDP丢包。 关于RTP over UDP和RTP over TCP的比较可以参考： http://thompsonng

一.soundtouch soundtouch是一个用C++编写的开源的音频处理库，可以改变音频文件或实时音频流的节拍(Tempo)、音调(Pitch)、速率(Rate)。ST的3个效果互相独立，也可以一起使用。这些效果通过采样率转换、时域压拓结合实现。 Tempo：通过时域压拓算法WSOLA，改变声音的播放速率而不影响音调，即变速不变调。 Pitch：变调不变速时。 Rate：变调也变速。 主要特性 跨平台：支持Windows、Mac OS、Linux、Android、Apple iOS等。 完全开源：ST库与示例工程完全开源可下载。 容易使用：编程接口使用单一的C++类。 支持16位整型或32位浮点型的单声道、立体声、多通道的音频格式。 可实现实时音频流处理，输入/输出延迟约为100ms。 关于soundtouch源码结构简析可参考： https://zhuanlan.zhihu.com/p/266868420 关于WSOLA算法可参考： https://zhuanlan.zhihu.com/p/110278983 二.Tempo soundtouch多用于本地文件的变速播放，这里为何要用呢？上篇文章提到过，当网络不稳定时，会出现时而无包可收，时而收取到大量包的情况，而读取本地文件不会存在这样的问题。我测试用的荧石摄像头，wifi连接到家里的百兆宽度，也会出现上面所述的问题

RTSP服务运作 基础基本搞明白了，那么RTSP,RTP等这些协议又是如何利用这些基础机制运作的呢？ 首先来看RTSP. RTSP首先需建立TCP侦听socket。可见于此函数： [cpp] view plain copy DynamicRTSPServer* DynamicRTSPServer::createNew(UsageEnvironment& env, Port ourPort, UserAuthenticationDatabase* authDatabase, unsigned reclamationTestSeconds) { int ourSocket = setUpOurSocket(env, ourPort); //建立TCP socket if (ourSocket == -1) return NULL; return new DynamicRTSPServer(env, ourSocket, ourPort, authDatabase, reclamationTestSeconds); } 要帧听客户端的连接，就需要利用任务调度机制了，所以需添加一个socket handler。可见于此函数： [cpp] view plain copy RTSPServer::RTSPServer(UsageEnvironment& env, int ourSocket,

很久没写博客了，今天准备开始接着写。 一直以来对音视频这块都比较感兴趣，从我博客中可以看出，很久之前就开始学习WebRTC，并且转发了一些流媒体的文章，但因为工作中主要是做Qt客户端开发的，音视频学习只能断断续续进行。今年由于年初疫情，隔离在家，时间比较充裕，于是又捡起了心中所好。 说起rtsp，自然会想到开源的跨平台流媒体框架live555。live555兼容的摄像机种类多，文档丰富，而且大名鼎鼎的VLC播放器中关于rtsp的推拉流使用的就是live555，因此决定撸起袖子从VLC源码看起....... 转眼间，一年就快过去了，基于live555的rtsp播放器也略有小成，支持Windows、Linux和Mac三个平台，先上几张图： 开发环境： Qt5.12.2+live555+ffmpeg4.3.1+SDL2.0.12+faac1.30+soundtouch2.2 主要功能： 1.支持多路视频显示 Windows和Linux支持Qt widget、SDL和Qt OpenGL三种方式渲染，Mac上支持Qt widget和Qt OpenGL两种方式渲染。SDL在Mac中嵌入Qt会有问题。 2.支持多种音视频编码格式 视频支持H264和H265，音频支持AAC、G711a、G711u和G726 3.支持抓图 使用ffmpeg编码视频数据为jpg格式并保存 4.支持录制

1.帧捕获 在前面的实现过程中，采用了QVideoProbe捕获摄像头数据，在信号绑定之后，传输到QSmartVenc，编码模块是额外放在另外一个线程处理的 QVencParm param; param.width = 1280; param.height = 720; param.code = MPP_VIDEO_CodingAVC; param.fmt = MPP_FMT_YUV420P; m_venc.reset(new QSmartVenc(param)); QThread *vencThread = new QThread(this); m_venc->moveToThread(vencThread); vencThread->start(); 将probe数据绑定到编码模块 connect(m_probe.data(),&QVideoProbe::videoFrameProbed,m_venc.data(),&QSmartVenc::needHandleImage); 2.编码 编码是使用的瑞芯微MPP，参考历程mpi_enc_test，整体接口略显麻烦，基本可以跟着流程不动进行修改。其中需要注意一点的是stride在MPP中需要是16字节对齐，这里最好将输入分辨率也做16字节对齐，这样宽和高就刚好和stride匹配，避免后面填充的时候还有手动计算YUV分量位置.

运行live555, 搭建好rtsp server 看到rtsp://0.0.0.0/<filename>，这里 ip地址为0.0.0.0，说明没有正常获取到你服务器的ip，此时如果用vlc或者mpc-hc或者potplayer播放的话，服务器上会报错：Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0；这里需要 设置默认网关； 了解到： live555在不知道本地IP地址与网络接口的情况下，通过一个在本地某端口建立一个UDP连接，然后把这个UDP连接加入 到一个组播组 ，当然要对这个组播组进行相应的设置，比如TTL，回环等等；然后通过UDP连接发送一个数据；最后通过这个UDP连接接收这个数据，并且解析相应的发送地址； 尝试如下方法可解决： 方法一：关闭防火墙重启 live555mediaserver，ip识别正常，播放正常； 方法二：开启防火墙后，放行udp端口15947，放行tcp端口554，也就是live555mediaserver 默认的rtsp端口；正常； 这是由于发现在 live555源码的groupsock/GroupsockHelper.cpp 中 live555是通过连接本机的15947端口来确定自己的ip的。但是不放行防火墙和端口的话

我们在实现一套EasyNVR无插件直播方案时，选择了采用行业标准的通用协议RTSP/Onvif接入摄像机IPC摄像机 / NVR硬盘录像机设备，众所周知，Onvif是摄像机的发现与控制管理协议，Onvif用到的流媒体协议也是RTSP，那么，我们在摄像机NVR流媒体接入上，就是直接采用统一的RTSP协议接入； 然而，在RTSP协议上，由于各个厂家都有不同的处理方法，比如：海康、大华、雄迈、宇视、天地伟业等厂家的RTSP地址规则就不一样，在有Onvif协议支持的设备还好一些，可以通过Onvif将摄像机的RTSP地址发现出来，但是遇到不支持Onvif的设备，就要自己拼接各个厂家的RTSP地址规则了，例如： 海康、大华IpCamera RTSP地址和格式 ， 雄迈/巨峰摄像机RTSP地址格式 ； 接入RTSP方面，目前市面上兼容性最强的两个组件： live555和ffmpeg ，各有利弊，live555结构复杂、ffmpeg整体庞大，最终我们选择了以live555作为摄像机RTSP接入的方案，能非常方便实现部分功能的定制，例如本文重点提到的OPTIONS发送的问题： 当我们采用RTP over UDP/TCP方式在取流的过程中，RTSPClient（live555）可能长时间都在从RTSPServer（IPC/NVR）取流，但缺没有向RTSPServer发送保活报文

　　之前写过一篇关于在 Linux 平台上编译 Android 平台上VLC播放器源代码的文章，vlc这款播放器非常优秀而且是开源的，它的核心是开源视频编解码库ffmpeg。而且这款播放器还支持RTSP协议，这个主要是用开源的live555来实现的，live555这个库以后还需要认真研习。 一、PC端（Windows平台）VLC播放RTSP视频延迟问题解决 　　前几天用PC平台上的VLC播放RTSP流媒体时延迟时间较长，存在1s左右的延迟，效果不是很好，后来查了资料，发现这个延迟时间是可以修改的。 　　找到工具->首选项，然后参数设置左下角选择“全部”，左边选择 “输入编解码”->“网络缓存”选项，可以根据具体需要加以修改，具体见下图不过这个值不要太小，否则缓存太小，播放视频的过程中会很卡 如果网络环境较好，300ms以内效果很好，实时性较好。 二：PC端（Linux平台）VLC播放RTSP视频延迟问题解决 　　这里我的 测试 平台是ubuntu，linux平台上的vlc可以以命令行的方式来运行，而命令行是可以带参数的，我们只需要在参数里面指定这个延迟时间就可以了，下面是具体的命令行形式，大家可以根据各自需要加以调整 vlc rtsp://192.168.1.1:8556/test.avi --newwork-caching=300 　

https://blog.csdn.net/li_wen01/article/details/51762040 live555为流媒体提供解决方案的平台的c++开源库。 1. 各个库的介绍 LIVE555 下包含LiveMedia、UsageEnvironment、BasicUsageEnvironment、GroupSock库，MediaServer简单服务器程序以及其他多个测试demo。 1.1LiveMedia 库 包含一系列处理不同编码格式和封装格式的类，基类是Medium（live/liveMedia/include/Media.hh）。 1.2UsageEnvironment 库 环境类，用于错误信息的输出。LIVE555中多数类中均包含此类对象指针。其内部包含TaskSchedule抽象类的指针，该类用于任务调度，因此所有包含UsageEnvironment指针的类均可将自己加入到调度中。 1.3BasicUsageEnvironment 库 包含具体环境类和具体TaskScheduler类。UsageEnvironment用于对错误信息的处理，BasicUsageEnvironment类用于以控制台方式输出错误信息。因此想要以其他方式输出错误信息的类，可以从UsageEnvironment派生