live555学习笔记－RTSPClient分析

最新推荐文章于 2024-06-20 07:17:37 发布

比较清纯

最新推荐文章于 2024-06-20 07:17:37 发布

阅读量1.5k

点赞数 1

本文链接：https://blog.csdn.net/hffgjh/article/details/86979712

版权

本文是关于live555学习的笔记，主要分析了RTSPClient的工作流程，从建立TCP连接，发送DESCRIBE请求获取SDP描述，根据SDP创建MediaSession，初始化MediaSubsession，到设置RTP/RTCP sockets，最后准备发送SETUP请求进行数据传输。

摘要由CSDN通过智能技术生成

八 RTSPClient分析

有RTSPServer，当然就要有RTSPClient。
如果按照Server端的架构，想一下Client端各部分的组成可能是这样：
因为要连接RTSP server，所以RTSPClient要有TCP socket。当获取到server端的DESCRIBE后，应建立一个对应于ServerMediaSession的ClientMediaSession。对应每个Track，ClientMediaSession中应建立ClientMediaSubsession。当建立RTP Session时，应分别为所拥有的Track发送SETUP请求连接，在获取回应后，分别为所有的track建立RTP socket，然后请求PLAY，然后开始传输数据。事实是这样吗？只能分析代码了。

testProgs中的OpenRTSP是典型的RTSPClient示例，所以分析它吧。
main()函数在playCommon.cpp文件中。main()的流程比较简单，跟服务端差别不大：建立任务计划对象－－建立环境对象－－处理用户输入的参数(RTSP地址)－－创建RTSPClient实例－－发出第一个RTSP请求（可能是OPTIONS也可能是DESCRIBE）－－进入Loop。

RTSP的tcp连接是在发送第一个RTSP请求时才建立的，在RTSPClient的那几个发请求的函数sendXXXXXXCommand()中最终都调用sendRequest()，sendRequest()中会跟据情况建立起TCP连接。在建立连接时马上向任务计划中加入处理从这个TCP接收数据的socket handler：RTSPClient::incomingDataHandler()。
下面就是发送RTSP请求，OPTIONS就不必看了，从请求DESCRIBE开始：

[cpp] view plain copy

void getSDPDescription(RTSPClient::responseHandler* afterFunc)
{
ourRTSPClient->sendDescribeCommand(afterFunc, ourAuthenticator);
}
unsigned RTSPClient::sendDescribeCommand(responseHandler* responseHandler,
Authenticator* authenticator)
{
if (authenticator != NULL)
fCurrentAuthenticator = *authenticator;
return sendRequest(new RequestRecord(++fCSeq, "DESCRIBE", responseHandler));
}

参数responseHandler是调用者提供的回调函数，用于在处理完请求的回应后再调用之。并且在这个回调函数中会发出下一个请求－－所有的请求都是这样依次发出的。使用回调函数的原因主要是因为socket的发送与接收不是同步进行的。类RequestRecord就代表一个请求,它不但保存了RTSP请求相关的信息，而且保存了请求完成后的回调函数－－就是responseHandler。有些请求发出时还没建立tcp连接，不能立即发送，则加入fRequestsAwaitingConnection队列；有些发出后要等待Server端的回应，就加入fRequestsAwaitingResponse队列，当收到回应后再从队列中把它取出。
由于RTSPClient::sendRequest()太复杂，就不列其代码了，其无非是建立起RTSP请求字符串然后用TCP socket发送之。

现在看一下收到DESCRIBE的回应后如何处理它。理论上是跟据媒体信息建立起MediaSession了，看看是不