问题一：

问题描述：rtsp流间隔一段时间后总是中断，因为有断开重连机制，所以画面一直是卡住，然后正常播放一段时间，这样循环。

原因描述：由于没有与服务器端建立心跳导致；有些服务器会检测心跳，有的不会，当检测心跳时长时间超过一定值后，服务器端会断开连接；

解决方法：定期发送心跳GET_PARAMETER；

代码：

TaskToken    m_HeartBeatCommandTask;
Boolean bsupportGetParamter = False;RTSPClient * XXXX::StartRTSPClient(char const * rtspURL)
{RTSPClient * pRtspClient = NULL;pRtspClient = myRTSPClient::createNew(*env, rtspURL, 1, NULL);if (pRtspClient){pRtspClient->sendOptionsCommand(continueAfterOption);}return pRtspClient;
}int XXXX::StopRTSPClient(RTSPClient * rtspClient)
{bsupportGetParamter = False;env->taskScheduler().unscheduleDelayedTask(m_HeartBeatCommandTask);m_HeartBeatCommandTask = NULL;return 0;
}void XXXX::continueAfterOption()
{/*...............*/bsupportGetParamter = RTSPOptionIsSupported("GET_PARAMETER", "");sendDescribeCommand(continueAfterDESCRIBE);/*...............*/
}void XXXX::continueAfterDESCRIBE(RTSPClient* rtspClient)
{/*...............*/setupNextSubsession(rtspClient);/*...............*/
}void XXXX::setupNextSubsession(RTSPClient* rtspClient)
{/*...............*///对ServerMediaSubsession发送SETUP命令，收到回复后回调continueAfterSETUP函数rtspClient->sendSetupCommand(*scs.subsession, continueAfterSETUP, False, True);/*...............*/// 成功与所有的ServerMediaSubsession建立了连接，现在发送PLAY命令rtspClient->sendPlayCommand(*scs.session, continueAfterPLAY, scs.session->absStartTime(), scs.session->absEndTime());/*...............*/
}void XXXX::continueAfterSETUP(RTSPClient* rtspClient, )
{/*...............*///调用setupNextSubsession函数与下一个ServerMediaSubsession建立连接，//在setupNextSubsession函数中，会检查是否与所有的ServerMediaSubsession都建立了连接，//全部建立连接之后则发送PLAY命令请求开始传送数据，收到回复则调用continueAfterPLAY函数setupNextSubsession(rtspClient);
}void XXXX::continueAfterPLAY(RTSPClient* rtspClient, int resultCode, char* resultString) {/*...............*///发送play命令之后，设置定时发送心跳scheduleHeartBeatCommand(rtspClient);
}void XXXX::continueAfterHeartBeatOption(RTSPClient* rtspClient)
{scheduleHeartBeatCommand(rtspClient);
}void XXXX::scheduleHeartBeatCommand(RTSPClient* rtspClient)
{// 获取超时时间，设置超时一半的时间发送心跳unsigned delayMax = rtspClient->sessionTimeoutParameter();int64_t uSecondsToDelay = delayMax;uSecondsToDelay = uSecondsToDelay * 500000;m_HeartBeatCommandTask = env->taskScheduler().scheduleDelayedTask(uSecondsToDelay, sendHeartBeatCommand, rtspClient);
}void XXXX::sendHeartBeatCommand(void* clientData)
{// 支持GET_PARAMETER参数的话就发送GET_PARAMETER，不支持发送option// 发送成功之后在通过回调continueAfterHeartBeatOption重新设置定时，这样就进入了循环，一直在发送心跳if (bsupportGetParamter){sendGetParameterCommand((*rtspClient->scs.session), continueAfterHeartBeatOption, NULL);}else{sendOptionsCommand(continueAfterHeartBeatOption);}
}

问题二：

问题描述：发送option后收到回应，再次发送DESCRIBE后隔10s左右收到回应，建立连接时间较长；

原因描述：使用live555 接收有鉴权功能的IPC中的RTSP服务时 RTSP play 之前会有很长时间的延时大概10秒左右；原因是我们的rtsp的url 可能是这种形式的rtsp:\\usr:password@192.xxx.xxx.xxx\streamname；也就是说rtsp的url 是包含用户名和密码的。

借鉴连接：https://blog.csdn.net/u013008311/article/details/81585827

解决方法：RTSPClient 实例使用时sendDescribeCommand 使用

sendDescribeCommand（describecallback，Authenticator*）；

修改之前代码：

// 假设rtspURL的格式rtsp:\\usr:password@192.xxx.xxx.xxx\streamname
RTSPClient * pRtspClient = NULL;pRtspClient = ourRTSPClient::createNew(*env, rtspURL, 1, NULL);if (pRtspClient)
{pRtspClient->sendOptionsCommand(continueAfterOption);
}

修改之后：

// 先将rtsp:\\usr:password@192.xxx.xxx.xxx\streamname解析一下，
// pUnauthorizedPath 的格式为rtsp:\\192.xxx.xxx.xxx\streamname
char* pUsername = NULL;
char* pPassword = NULL;
char* pUnauthorizedPath = NULL;
ParseRTSPURL(rtspURL, pUsername, pPassword, pUnauthorizedPath);if (pUsername != NULL && pPassword != NULL)pRtspClient = ourRTSPClient::createNew(*env, pUnauthorizedPath, 1, NULL);
elsepRtspClient = ourRTSPClient::createNew(*env, rtspURL, 1, NULL);if (pRtspClient)
{if (pUsername != NULL && pPassword != NULL){Authenticator authenticator(pUsername, pPassword, False);pRtspClient->sendOptionsCommand(continueAfterOption, &authenticator);}else{pRtspClient->sendOptionsCommand(continueAfterOption);}
}

ParseRTSPURL()函数链接：https://blog.csdn.net/m0_37684310/article/details/89713900

使用live555客户端源码遇到的问题及解决方法相关推荐

git clone github源码下载速度很慢的解决方法
为什么80%的码农都做不了架构师?>>> git 在国内下载github上源码时,一般下载速度都非常慢,通常只有几KB到几十KB. MacBook-Pro-2:opensour ...
python3 安装包源码包下载慢问题解决方法
目录问题解决方法1 选择国内镜像源解决方法2 使用下载器问题 python官网下载地址:https://www.python.org/downloads/ 国内下载特别慢解决方法1 选择国内 ...
【Java】CMD编译Java源码遇到\ufeff问题的解决方法
记事本支持保存的四种编码 UTF-8文件的CMD编译我们把一个记事本写的.UTF-8编码的.java文件放在cmd下使用javac命令编译: 确实乱码,因为人家支持的默认CHCP是936: 这是简体 ...
linux安装源文件出现错误,编译安装源码时出现错误的解决方法
由于软件更新速度比较快,所以我们经常需要自己动手去编译安装一个软件,但是编译安装时难免不出现错误,像LAMP,LNMP在好多平台我都是手动编译的,也出现过不少错误,以下总结编译安装出现错误时的解决方法 ...
vlc 调用live555的源码分析--vlc v2.1.1版本
VLC调用Live555源码解析以前在看live555的源码和例子的时,发现live555的例子都是回调,这样我们根本无法判断命令是否发送成功,也无法判断发送是否超时:网上搜索,也没有看到有用的资料 ...
boost::asio异步模式的C/S客户端源码实现
异步模式的服务器源码 //g++ -g async_tcp_server.cpp -o async_tcp_server -lboost_system //#include <iostream& ...
zookeeper 客户端_zookeeper进阶-客户端源码详解
流程图先看一下客户端源码的流程图总体流程总体流程开启SendThread线程开启EventThread 总结下面根据源码讲解,大家整合源码和流程图一起看最好,本篇内容比较多建议收藏起来看. ...
Netty学习笔记(一)Netty客户端源码分析
最近在学些BIO,NIO相关的知识,也学习了下Netty和它的源码,做个记录,方便以后继续学习,如果有错误的地方欢迎指正如果不了解BIO,NIO这些基础知识,可以看下我的如下博客 IO中的阻塞.非阻 ...
grpc-go客户端源码分析
grpc-go客户端源码分析代码讲解基于v1.37.0版本. 和grpc-go服务端源码分析一样,我们先看一段示例代码, const (address = "localhost:50051 ...

使用live555客户端源码遇到的问题及解决方法

使用live555客户端源码拉rtsp流遇到两个问题，正常测试拉取海康摄像头没问题；

问题一：

问题二：

使用live555客户端源码遇到的问题及解决方法相关推荐

最新文章

热门文章