作者： Wolf Geek 转载请说明出处
上一回，主要介绍了有关WifiDisplay设备连接和建立数据流的流程，这一回将接着向底层前进。由于涉及的内容较多，这里仅仅理清一个大概的头绪，细节的部分将不再展开，如果有什么错误的地方我会及时更正。
当Source端通过RemoteDisplay.cpp的构造函数注册了Wifidisplay处理线程，并且ANetworkSession初始化了通信所用的数据管道并且开始监听数据流变化后，Source端将通过函数mSource->start(iface)开始建立RTSP连接并且向Sink端传递数据流。接下来，将具体分析其流程。mSource->start(iface)的具体实现在以下文件，
frameworks/av/media/libstagefright/wifi-display/source/WifiDisplaySource.cpp
status_t WifiDisplaySource::start(const char *iface) {
CHECK_EQ(mState, INITIALIZED);
sp<AMessage> msg = new AMessage(kWhatStart, id());
msg->setString("iface", iface);
sp<AMessage> response;
status_t err = msg->postAndAwaitResponse(&response);
if (err != OK) {
return err;
}
if (!response->findInt32("err", &err)) {
err = OK;
}
return err;
}
该函数首先通过CHECK_EQ来判断当前Source端状态是否为 INITIALIZED，如果是将通过 AMessage创建 标识为kWhatStart的消息，用于在onMessageReceived处理分支中进行匹配，msg->setString(“iface”,iface)用于在传递消息过程中携带网络地址端口信息， msg->postAndAwaitResponse用于返回相应结果。这种方式在Android的流媒体类中相当常见，是一种异步消息处理框架。与该框架相关的类主要有ALooper、AHandler、ALooperRoster等，具体请见这里。
接下来，我们来看看当Source端接收到kWhatStart的消息后做何种处理，
void WifiDisplaySource::onMessageReceived(const sp<AMessage> &msg) {
switch (msg->what()) {
case kWhatStart:
{
uint32_t replyID;
CHECK(msg->senderAwaitsResponse(&replyID));
AString iface;
CHECK(msg->findString("iface", &iface));
status_t err = OK;
ssize_t colonPos = iface.find(":"); //寻找“:”所在位置
unsigned long port;
if (colonPos >= 0) {
const char *s = iface.c_str() + colonPos + 1;
char *end;
port = strtoul(s, &end, 10); //得到port号
if (end == s || *end != '\0' || port > 65535) {
err = -EINVAL;
} else {
iface.erase(colonPos, iface.size() - colonPos);
}
} else {
port = kWifiDisplayDefaultPort;
}
if (err == OK) {
if (inet_aton(iface.c_str(), &mInterfaceAddr) != 0) { //将IP地址转化为32位的网络序列IP地址
sp<AMessage> notify = new AMessage(kWhatRTSPNotify, id());//建立标识为 kWhatRTSPNotify的消息作为参数传递
err = mNetSession->createRTSPServer(
mInterfaceAddr, port, notify, &mSessionID);
} else {
err = -EINVAL;
}
}
if (err == OK) {
mState = AWAITING_CLIENT_CONNECTION;
}
sp<AMessage> response = new AMessage;
response->setInt32("err", err);
response->postReply(replyID);
break;
}
...
}
}
首先，可以看到当Source端接收到消息标识为 kWhatStart的消息后，消息指针msg会通过函数msg->senderAwaitsResponse(&replyID)获取对应于postAndAwaitResponse函数的响应标识，并把处理中的错误信息作为消息载体通过response->postReply(replyID)传递回start(iface)函数。然后，该处理函数将接收到的网络地址端口信息iface拆分为IP地址和端口两个部分,并且利用 createRTSPServer创建RTSP服务端，函数会返回相应的Session编号。如果RTSP服务端创建成功，则将Source端状态更改为 AWAITING_CLIENT_CONNECTION，表示等待客户端连接。
接着看创建RTSP服务端具体做了哪些动作，
frameworks/av/media/libstagefright/wifi-display/ANetworkSession.cpp
status_t ANetworkSession::createRTSPServer(
const struct in_addr &addr, unsigned port,
const sp<AMessage> notify, int32_t *sessionID) {
return createClientOrServer(
kModeCreateRTSPServer,
&addr,
port,
NULL /* remoteHost */,
0 /* remotePort */,
notify,
sessionID);
}
可以看到函数createRTSPServer具体又调用了 createClientOrServer函数。在此类中，与建立管道数据流相关的函数都会调用该函数，它们分别是createRTSPClient、createRTSPServer、createUDPSession、createTCPDatagramSession等函数。
其中可以不用关注函数createTCPDatagramSession，这是因为Sink端默认选择了UDP方式进行传输。具体起关键性作用的是在WifiDisplaySink.h头文件中的static const bool sUseTCPInterleaving = false变量 ，具体而言，该变量为false就导致Sink端不会向Source端发送“Transport: RTP/AVP/TCP”这样的请求，这样在Source端就不会将Sender类中的mTransportMode变量设置为TRANSPORT_TCP或者 TRANSPORT_TCP_INTERLEAVED，所以在Sender类中最终并不会调用函数createTCPDatagramSession。
接下来，将重点看看函数createClientOrServer，其中与建立RTSP服务端无关的步骤先省略不看。
status_t ANetworkSession::createClientOrServer(
Mode mode,
const struct in_addr *localAddr,
unsigned port,
const char *remoteHost,
unsigned remotePort,
const sp<AMessage> notify,
int32_t *sessionID) {
Mutex::Autolock autoLock(mLock);
*sessionID = 0;
status_t err = OK;
int s, res;
sp<Session> session;
s = socket(
AF_INET,
(mode == kModeCreateUDPSession) ? SOCK_DGRAM : SOCK_STREAM,
0); //建立类型为流套接字的socket
...
if (mode == kModeCreateRTSPServer
|| mode == kModeCreateTCPDatagramSessionPassive) {
const int yes = 1;
res = setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes));//允许socket和一个已在使用中的地址捆绑
err = MakeSocketNonBlocking(s); //设置socket为非阻塞方式
struct sockaddr_in addr;
memset(addr.sin_zero, 0, sizeof(addr.sin_zero));
addr.sin_family = AF_INET;
if (mode == kModeCreateRTSPClient
|| mode == kModeCreateTCPDatagramSessionActive) {
...
} else if (localAddr != NULL) {
addr.sin_addr = *localAddr;
addr.sin_port = htons(port);
} else {
...
}
if (mode == kModeCreateRTSPClient
|| mode == kModeCreateTCPDatagramSessionActive) {
...
} else {
res = bind(s, (const struct sockaddr *)&addr, sizeof(addr));//socket与
sockaddr结构体指针绑定，sockaddr对应与iface
if (res == 0) { //绑定成功
if (mode == kModeCreateRTSPServer
|| mode == kModeCreateTCPDatagramSessionPassive) {
res = listen(s, 4); //作为服务端开始监听rtsp连接请求
} else {
...
}
}
}
}
...
Session::State state;
switch (mode) {
...
case kModeCreateRTSPServer:
state = Session::LISTENING_RTSP; //设置Session状态为 LISTENING_RTSP
break;
...
}
session = new Session(
mNextSessionID++,
state,
s,
notify); //创建一个session对象,sessionID加1
...
mSessions.add(session->sessionID(), session); //将该对象加入vector结构中保存
interrupt(); //向管道写端写数据
*sessionID = session->sessionID(); //由指针带出当前sessionID
goto bail;
...
bail:
return err;
}
可以看到建立RTSP服务端的步骤没什么特别的地方，无非是建立socket,绑定地址然后监听等步骤，只不过为了标识不同的请求和区分当前状态，这里用Session结构体和相应的状态来管理对应的socket。
回到RemoteDisplay.cpp的构造函数中，可以看到在Source端调用函数mSource->start(iface)之前就通过mNetSession->start()开启了ANetworkSession线程，接下来看一下mNetSession->start()究竟干了什么事。
status_t ANetworkSession::start(){
...
int res =pipe(mPipeFd); //建立读写管道，控制threadLoop的执行
if (res != 0) {
mPipeFd[0] = mPipeFd[1] = -1;
return -errno;
}
mThread = new NetworkThread(this); //构造ANetworkSession的内部结构线程
status_t err = mThread->run("ANetworkSession", ANDROID_PRIORITY_AUDIO);//开启该线程，将会调用NetworkThread线程中threadLoop，进一步会调用AnetworkSession::threadLoop()
...
return OK;
}可以看到ANetworkSession采用了管道的方式来控制AnetworkSession::threadLoop()的执行，
void ANetworkSession::threadLoop() {
fd_set rs, ws;
FD_ZERO(&rs);
FD_ZERO(&ws);
FD_SET(mPipeFd[0], &rs);
int maxFd = mPipeFd[0];
{
...
for (size_t i = 0; i < mSessions.size(); ++i) {
const sp<Session> &session = mSessions.valueAt(i);
int s = session->socket(); //遍历并获取vector结构中保存的socket
...
if (session->wantsToRead()) { //判断当前session状态是否需要读
FD_SET(s, &rs);
if (s > maxFd) {
maxFd = s;
}
}
if (session->wantsToWrite()) {//判断当前session状态是否需要写
FD_SET(s, &ws);
if (s > maxFd) {
maxFd = s;
}
}
}
}
int res = select(maxFd + 1, &rs, &ws, NULL, NULL ); //阻塞查看是否有socket可读写
...
if (FD_ISSET(mPipeFd[0], &rs)) {
char c;
ssize_t n;
do {
n = read(mPipeFd[0], &c, 1); //只有当管道中有数值时才跳出循环，即类中有其他函数调用了 interrupt函数
} while (n < 0 && errno == EINTR);
...
--res;
}
{
...
List<sp<Session> > sessionsToAdd;
for (size_t i = mSessions.size(); res > 0 && i-- > 0;) { //res>0判断是否有socket资源可进行读或写
const sp<Session> &session = mSessions.valueAt(i);
int s = session->socket();
if (FD_ISSET(s, &rs) || FD_ISSET(s, &ws)) {
--res;
}
if (FD_ISSET(s, &rs)) {
if (session->isRTSPServer() || session->isTCPDatagramServer()) {
//如果当前状态Session状态为LISTENING_RTSP或LISTENING_TCP_DGRAMS执行下列操作
struct sockaddr_in remoteAddr;
socklen_t remoteAddrLen = sizeof(remoteAddr);
int clientSocket = accept(
s, (struct sockaddr *)&remoteAddr, &remoteAddrLen);//从处于listen状态的流套接字s的客户连接请求队列中取出排在最前的一个客户请求建立新的socket通道
if (clientSocket >= 0) {
status_t err = MakeSocketNonBlocking(clientSocket);
...
sp<Session> clientSession =
new Session(
mNextSessionID++,
Session::CONNECTED,
clientSocket,
session->getNotificationMessage());
//把所建立RTSP连接的本地地址、客户地址以及端口等信息通过AMessage发送到Source端
clientSession->setIsRTSPConnection(
session->isRTSPServer()); //mIsRTSPConnection变量设为false
sessionsToAdd.push_back(clientSession); //将该Session加入到 sessionsToAdd队列尾部
}
...
} else {
status_t err = session->readMore(); //在建立UDP连接或者RTSP连接已建立的状况且该socket可读，接收相应socket传来的信息，同时通过AMessage的形式与Source或Sink端做数据交换并且通知其做相应处理
}
}
if (FD_ISSET(s, &ws)) {
status_t err = session->writeMore(); //对有写需求的Session,并且该socket是可写的情况下，向UDP或RTSP连接的另一端发送由Souce或Sink端相应请求中获得的数据
...
}
}
while (!sessionsToAdd.empty()) {
sp<Session> session = *sessionsToAdd.begin();
sessionsToAdd.erase(sessionsToAdd.begin());
mSessions.add(session->sessionID(), session); //按队列顺序把相关Session加入vector结构中保存
}
}
}
}
该 threadLoop()函数首先完成了Sink端RTSP客户端连接请求的接收，其次还负责完成在Source端和Sink端之间的RTSP连接和UDP连接的相关socket读写通信等工作。了解了ANetworkSession线程是如何管理Source端和Sink端之间数据通信的过程后，再次回到Wifi Display的开启流程上来。在threadLoop()函数中RTSP服务端会从处于listen状态的流套接字s的客户连接请求队列中取出排在最前的一个客户请求建立新的socket通道。可以看到这个连接请求由rtsp的客户端发出，具体而言，该请求是由createClientOrServer函数中相应的connect函数完成，
frameworks/av/media/libstagefright/wifi-display/ANetworkSession.cpp
if (mode == kModeCreateRTSPClient
|| mode == kModeCreateTCPDatagramSessionActive) {
struct hostent *ent= gethostbyname(remoteHost);
addr.sin_addr.s_addr = *(in_addr_t *)ent->h_addr;
addr.sin_port = htons(remotePort);
in_addr_t x = ntohl(addr.sin_addr.s_addr);
ALOGI("connecting socket %d to %d.%d.%d.%d:%d",
s,
(x >> 24),
(x >> 16) & 0xff,
(x >> 8) & 0xff,
x & 0xff,
ntohs(addr.sin_port));
res = connect(s, (const struct sockaddr *)&addr, sizeof(addr));
}
到这里，关注的焦点转向到createRTSPClient也就是Rtsp客户端建立的过程，而客户端的建立是由Sink端完成的，因此开始分析Sink端程序。
客户端主程序目前只有测试程序，由于没有设备并没有进行相关测试，该程序编译好只能以命令方式运行，命令有两个选项作为选择,调用格式如下，
./wfd -c xx.xx.xx.xx:port
./wfd -u uri
第一条命令用于将Sink端连接到Source端，需要知道Source端的IP地址及Port端口，第二条命令用于测试sink端连接到rtsp uri地址的效果。这里只来看第一条命令，执行后其会调用以下关键的几个函数，
frameworks/av/media/libstagefright/wifi-display/wfd.cpp
sp<ANetworkSession> session = new ANetworkSession;
session->start();
sp<WifiDisplaySink> sink = new WifiDisplaySink(session);
looper->registerHandler(sink);
sink->start(connectToHost.c_str(), connectToPort);
looper->start(true);
可以看到，Sink端的启动与Source端没有什么区别，依旧是开启如同RemoteDisplay.cpp中的那几个线程，下面来关注一下WifiDisplaySink线程的启动。首先是用构造函数new出一个操作对象，以下是构造函数，
WifiDisplaySink::WifiDisplaySink(
const sp<ANetworkSession> &netSession,
const sp<ISurfaceTexture> &surfaceTex)
: mState(UNDEFINED),
mNetSession(netSession),
mSurfaceTex(surfaceTex),
mSessionID(0),
mNextCSeq(1) {
}
上面为WifiDisplaySink的构造函数，可以看到调用时并没有去初始化第二个参数，默认就会被置为空，这是为用户自己构造Sink端程序界面提供的参数。后面会看到在TunnelRenderer类中会直接创建Surface对象供填充Sink端播放器使用。也就是说，如果要写自己的Sink端应用，可以将应用层要作为显示Source端数据流的Surface直接用来填充该构造函数使用。之后就是利用构造出的对象去启动Sink端主线程，
void WifiDisplaySink::start(const char *sourceHost, int32_t sourcePort) {
sp<AMessage> msg = new AMessage(kWhatStart, id());
msg->setString("sourceHost", sourceHost);
msg->setInt32("sourcePort", sourcePort);
msg->post();
}
又看到了熟悉的异步消息处理框架AMessage类，这里就直接去看onMessageReceived的相应处理，
void WifiDisplaySink::onMessageReceived(const sp<AMessage> &msg) {
switch (msg->what()) {
case kWhatStart:
{
int32_t sourcePort;
...
CHECK(msg->findString("sourceHost", &mRTSPHost));
CHECK(msg->findInt32("sourcePort", &sourcePort));
sp<AMessage> notify = new AMessage(kWhatRTSPNotify, id());
status_t err = mNetSession->createRTSPClient(
mRTSPHost.c_str(), sourcePort, notify, &mSessionID);
//建立RTSP客户端
CHECK_EQ(err, (status_t)OK);
mState = CONNECTING;
break;
}
...
}
}
到此，终于看到了Sink端调用ANetworkSession类中的createRTSPClient函数去建立Rtsp客户端。具体就是调用上面提到的connect函数将流套接字s连接至由命令指定的source端网络地址，并且将当前Session状态置为Session::CONNECTING。需要注意的是，只要调用了createClientOrServer的函数都会根据当前不同状态创建session并且加入到mSessions这一Vector结构中以供threadLoop和sendRequest等函数使用。当建立完RTSP服务端和客户端后，与RTSP服务端对应的session是需要读的，相应socket被加入到读文件描述符集合rs中；与RTSP客户端对应的session是需要写的，相应socket被加入到写文件描述符集合ws中。
Rtsp服务端在监听到客户端连接请求后，在threadLoop中将调用accept函数接收该请求并创建新的clientSocket。如果clientSocket可以被置为非阻塞状态，则通过其创建clientSession，具体就是调用Session的构造函数 sp<Session> clientSession =new Session(mNextSessionID++,Session::CONNECTED,clientSocket,session->getNotificationMessage())，
ANetworkSession::Session::Session(
int32_t sessionID,
State state,
int s,
const sp<AMessage> notify)
: mSessionID(sessionID),
mState(state),
mIsRTSPConnection(false),
mSocket(s),
mNotify(notify),
mSawReceiveFailure(false),
mSawSendFailure(false) {
if (mState == CONNECTED) {
struct sockaddr_in localAddr;
socklen_t localAddrLen = sizeof(localAddr);
int res = getsockname(
mSocket, (struct sockaddr *)&localAddr, &localAddrLen);//根据clientSocket获得本地网络地址
CHECK_GE(res, 0);
struct sockaddr_in remoteAddr;
socklen_t remoteAddrLen = sizeof(remoteAddr);
res = getpeername(
mSocket, (struct sockaddr *)&remoteAddr, &remoteAddrLen);//根据clientSocket获得连接到Rtsp服务端的客户端网络地址
CHECK_GE(res, 0);
in_addr_t addr = ntohl(localAddr.sin_addr.s_addr);
AString localAddrString = StringPrintf(
"%d.%d.%d.%d",
(addr >> 24),
(addr >> 16) & 0xff,
(addr >> 8) & 0xff,
addr & 0xff);
addr = ntohl(remoteAddr.sin_addr.s_addr);
AString remoteAddrString = StringPrintf(
"%d.%d.%d.%d",
(addr >> 24),
(addr >> 16) & 0xff,
(addr >> 8) & 0xff,
addr & 0xff);
sp<AMessage> msg = mNotify->dup(); //利用AMessage进行通知
msg->setInt32("sessionID", mSessionID);
msg->setInt32("reason", kWhatClientConnected); //通知Source端相关信息
msg->setString("server-ip", localAddrString.c_str());
msg->setInt32("server-port", ntohs(localAddr.sin_port));
msg->setString("client-ip", remoteAddrString.c_str());
msg->setInt32("client-port", ntohs(remoteAddr.sin_port));
msg->post();
}
}
可以看到，在创建clientSession时，session的状态被置为 CONNECTED，随后会根据clientSocket获得本地网络地址和连接到Rtsp服务端的客户端网络地址。在构造函数的最后会将相关信息通知Source端。此外，clientSession
Source端在创建RTSP服务端后就一直处于AWAITING_CLIENT_CONNECTION的状态，并且等待接收kWhatRTSPNotify类型的消息。当clientSession创建并向Source端发送通知消息后，Source端就在查询reason类型为kWhatClientConnected的消息。
frameworks/av/media/libstagefright/wifi-display/source/WifiDisplaySource.cpp
case ANetworkSession::kWhatClientConnected:
{
int32_t sessionID;
CHECK(msg->findInt32("sessionID", &sessionID));
if (mClientSessionID > 0) { // mClientSessionID初始为0
ALOGW("A client tried to connect, but we already "
"have one.");
mNetSession->destroySession(sessionID);
break;
}
CHECK_EQ(mState, AWAITING_CLIENT_CONNECTION); //检查状态
CHECK(msg->findString("client-ip", &mClientInfo.mRemoteIP));//接收clientSession传来的信息
CHECK(msg->findString("server-ip", &mClientInfo.mLocalIP));
if (mClientInfo.mRemoteIP == mClientInfo.mLocalIP) {
//出于安全考虑不接收由本地网络地址发来的连接
mNetSession->destroySession(sessionID);
break;
}
CHECK(msg->findInt32(
"server-port", &mClientInfo.mLocalPort));
mClientInfo.mPlaybackSessionID = -1;
mClientSessionID = sessionID;
ALOGI("We now have a client (%d) connected.", sessionID);
mState = AWAITING_CLIENT_SETUP;
status_t err = sendM1(sessionID);
CHECK_EQ(err, (status_t)OK);
break;
}
在Source端，onMessageReceived函数会接收由clientSession发送的通知消息，并且将Source端状态置为AWAITING_CLIENT_SETUP。与此同时，其会将clientSession对应的sessionID作为参数标识向RTSP服务端发送OPTIONS请求。
status_t WifiDisplaySource::sendM1(int32_t sessionID) {
AString request = "OPTIONS * RTSP/1.0\r\n";
AppendCommonResponse(&request, mNextCSeq); //添加基本消息，如时间、消息序号等等
request.append(
"Require: org.wfa.wfd1.0\r\n"
"\r\n");
status_t err =
mNetSession->sendRequest(sessionID, request.c_str(), request.size());
//向ANetworkSession发送数据等待threadLoop处理
if (err != OK) {
return err;
}
registerResponseHandler(
sessionID, mNextCSeq, &WifiDisplaySource::onReceiveM1Response);
//使用函数指针返回状态信息
++mNextCSeq; //消息序号标识递增
return OK;
}
进一步，ANetworkSession类中的sendRequest函数无非是将消息保存在mOutBuffer或者mOutDatagrams供writeMore函数使用。具体而言，当sendRequest函数调用完毕时，threadLoop中的select函数发现写文件描述符集合ws有写变化，即有socket可写。因而会调用session->writeMore()函数，该session对应于RTSP客户端，所处状态仍旧为Session::CONNECTING。因此，在调用writeMore函数时，会执行以下语句，
status_t ANetworkSession::Session::writeMore() {
...
if (mState == CONNECTING) {
int err;
socklen_t optionLen = sizeof(err);
CHECK_EQ(getsockopt(mSocket, SOL_SOCKET, SO_ERROR, &err, &optionLen), 0);
CHECK_EQ(optionLen, (socklen_t)sizeof(err));
if (err != 0) {
notifyError(kWhatError, -err, "Connection failed");
mSawSendFailure = true;
return -err;
}
mState = CONNECTED;
notify(kWhatConnected);
return OK;
}
CHECK_EQ(mState, CONNECTED);
CHECK(!mOutBuffer.empty());
ssize_t n;
do {
n = send(mSocket, mOutBuffer.c_str(), mOutBuffer.size(), 0); //客户端向服务端发送OPTIONS请求
} while (n < 0 && errno == EINTR);
status_t err = OK;
if (n > 0) {
mOutBuffer.erase(0, n);
} else if (n < 0) {
err = -errno;
} else if (n == 0) {
err = -ECONNRESET;
}
if (err != OK) {
notifyError(true , err, "Send failed.");
mSawSendFailure = true;
}
return err;
}
由于RTSP客户端所处状态为Session::CONNECTING，因此执行if中的语句。这里首先获得相关socket的错误信息，如果没有任何错误信息，则更改RTSP客户端相应Session状态为 CONNECTED，并且会通知Sink端 kWhatConnected信息将Sink端的状态置为CONNECTED。之后，threadLoop函数会将clientSession加入到mSessions集合中，并等待接收由客户端发送来的请求信息。也就是在下一次threadLoop执行时，clientSession将会调用readMore函数从mSocket中接收由客户端发送的请求信息，具体过程如下，
status_t ANetworkSession::Session::readMore() {
...
char tmp[512];
ssize_t n;
do {
n = recv(mSocket, tmp, sizeof(tmp), 0); //接收客户端请求信息
} while (n < 0 && errno == EINTR);
status_t err = OK;
if (n > 0) {
mInBuffer.append(tmp, n);
} else if (n < 0) {
err = -errno;
} else {
err = -ECONNRESET;
}
if (!mIsRTSPConnection) {
...
} else {
for (;;) {
size_t length;
if (mInBuffer.size() > 0 && mInBuffer.c_str()[0] == '$') {
//接收到类型为PlaybackSession::kWhatBinaryData且头部请求信息为'$'才会进入此判断体
...
}
sp<ParsedMessage> msg =
ParsedMessage::Parse(
mInBuffer.c_str(), mInBuffer.size(), err != OK, &length);
//解析处理RTSP消息
if (msg == NULL) {
break;
}
sp<AMessage> notify = mNotify->dup();
notify->setInt32("sessionID", mSessionID);
notify->setInt32("reason", kWhatData); //向Sink端发送类型为kWhatData的消息请求
notify->setObject("data", msg);
notify->post();
...
mInBuffer.erase(0, length);
if (err != OK) {
break;
}
}
}
if (err != OK) {
notifyError(false /* send */, err, "Recv failed.");
mSawReceiveFailure = true;
}
return err;
}
该函数会首先接收客户端请求信息，然后利用解析类将信息解析成Sink端能够识别处理的信息，并且向Sink端发送类型为kWhatData的消息请求。现在先来看一下Sink端在接收到消息后是如何进行处理的，
void WifiDisplaySink::onMessageReceived(const sp<AMessage> &msg) {
...
case ANetworkSession::kWhatData:
{
onReceiveClientData(msg); //调用消息处理函数
break;
}
...
}
void WifiDisplaySink::onReceiveClientData(const sp<AMessage> &msg) {
int32_t sessionID;
CHECK(msg->findInt32("sessionID", &sessionID)); //获得发送消息的sessionID
sp<RefBase> obj;
CHECK(msg->findObject("data", &obj)); //获得发送信息的object对象
sp<ParsedMessage> data =
static_cast<ParsedMessage *>(obj.get()); //根据object对象获取解析后的数据
ALOGV("session %d received '%s'",
sessionID, data->debugString().c_str());
AString method;
AString uri;
data->getRequestField(0, &method);
int32_t cseq;
if (!data->findInt32("cseq", &cseq)) { //获取send时加入的消息序号
sendErrorResponse(sessionID, "400 Bad Request", -1 );
return ERROR_MALFORMED;
}
if (method.startsWith("RTSP/")) { //如果消息以"RTSP/"开头
ResponseID id;
id.mSessionID = sessionID;
id.mCSeq = cseq;
ssize_t index = mResponseHandlers.indexOfKey(id); //根据 ResponseID获取注册时的mResponseHandlers在KeyedVector<ResponseID, HandleRTSPResponseFunc>这个数据结构中的位置
if (index < 0) {
ALOGW("Received unsolicited server response, cseq %d", cseq);
return ERROR_MALFORMED;
}
HandleRTSPResponseFunc func = mResponseHandlers.valueAt(index); //根据位置获取注册的回复函数
mResponseHandlers.removeItemsAt(index);
status_t err = (this->*func)(sessionID, data); //填充函数指针
//判断回复中是否有错误信息
CHECK_EQ(err, (status_t)OK);
} else {
AString version;
data->getRequestField(2, &version);
if (!(version == AString("RTSP/1.0"))) { //判断RTSP协议版本是否正确
sendErrorResponse(sessionID, "505 RTSP Version not supported", cseq);
return;
}
if (method == "OPTIONS") {
onOptionsRequest(sessionID, cseq, data);
} else if (method == "GET_PARAMETER") {
onGetParameterRequest(sessionID, cseq, data);
} else if (method == "SET_PARAMETER") {
onSetParameterRequest(sessionID, cseq, data);
} else {
sendErrorResponse(sessionID, "405 Method Not Allowed", cseq);
}
}
}
首先，Sink端接收函数类型为kWhatData的消息请求，会调用onReceiveClientData函数进行消息处理。该函数在获得发送信息的object对象、sessionID（此时的sessionID对应于clientSession）等信息后，根据object对象获取解析后的数据。如果解析后的消息以"RTSP/"开头，注册的回复函数中也没有错误信息，那么就填充之前利用registerResponseHandler函数注册的函数指针，否则就匹配处理方法类型调用相关处理函数。由于函数sendM1发送的是 OPTIONS请求，这样会直接去匹配处理方法类型，从而会调用onOptionsRequest函数。
void WifiDisplaySink::onOptionsRequest(
int32_t sessionID,
int32_t cseq,
const sp<ParsedMessage> &data) {
AString response = "RTSP/1.0 200 OK\r\n";
AppendCommonResponse(&response, cseq);
response.append("Public: org.wfa.wfd1.0, GET_PARAMETER, SET_PARAMETER\r\n");
response.append("\r\n");
status_t err = mNetSession->sendRequest(sessionID, response.c_str());
CHECK_EQ(err, (status_t)OK);
err = sendM2(sessionID);
CHECK_EQ(err, (status_t)OK);
}
该函数会将Sink端支持的方法GET_PARAMETER, SET_PARAMETER发送至ANetworkSession。以采取上面的那种readMore,writeMore之间socket通信的方式将Sink端支持的方法通知给Source端，Source端依旧采取形如Sink端的消息接收处理方式进行处理，
void WifiDisplaySource::onMessageReceived(const sp<AMessage> &msg) {
...
case ANetworkSession::kWhatData:
{
status_t err = onReceiveClientData(msg); //调用消息处理函数
if (err != OK) {
mClient->onDisplayError(
IRemoteDisplayClient::kDisplayErrorUnknown);
}
break;
}
...
}
status_t WifiDisplaySource::onReceiveClientData(const sp<AMessage> &msg) {
...
if (method.startsWith("RTSP/")) { //如果消息以"RTSP/"开头
ResponseID id;
id.mSessionID = sessionID;
id.mCSeq = cseq;
ssize_t index = mResponseHandlers.indexOfKey(id);
...
HandleRTSPResponseFunc func = mResponseHandlers.valueAt(index);
mResponseHandlers.removeItemsAt(index);
status_t err = (this->*func)(sessionID, data); //填充函数指针
if (err != OK) {
ALOGW("Response handler for session %d, cseq %d returned "
"err %d (%s)",
sessionID, cseq, err, strerror(-err));
return err;
}
...
return OK;
}
status_t err;
if (method == "OPTIONS") {
err = onOptionsRequest(sessionID, cseq, data); 匹配处理方法类型
} else if (method == "SETUP") {
err = onSetupRequest(sessionID, cseq, data);
} else if (method == "PLAY") {
err = onPlayRequest(sessionID, cseq, data);
} else if (method == "PAUSE") {
err = onPauseRequest(sessionID, cseq, data);
} else if (method == "TEARDOWN") {
err = onTeardownRequest(sessionID, cseq, data);
} else if (method == "GET_PARAMETER") {
err = onGetParameterRequest(sessionID, cseq, data);
} else if (method == "SET_PARAMETER") {
err = onSetParameterRequest(sessionID, cseq, data);
} else {
sendErrorResponse(sessionID, "405 Method Not Allowed", cseq);
err = ERROR_UNSUPPORTED;
}
return err;
}
首先，Source端接收函数类型为kWhatData的消息请求，会调用onReceiveClientData函数进行消息处理。该函数在获得发送信息的object对象、sessionID（此时的sessionID对应于clientSession）等信息后，根据object对象获取解析后的数据。由于此时消息以"RTSP/"开头，则会填充函数sendM1 中利用registerResponseHandler函数注册的函数指针onReceiveM1Response。如果回复信息中没有错误信息，即RTSP服务端返回的状态码为200,则表示RTSP服务端提供Sink端需要的那些RTSP方法。
与此同时，Sink端还会接下去执行，也就是调用sendM2函数，该函数如同sendM1函数，依旧是发送OPTIONS请求，只不过方向正好相反，是由Sink端发送Source端接收。具体流程与上面的流程一致，Source端在接收到OPTIONS请求请求后，会同样调用以下函数。
status_t WifiDisplaySource::onOptionsRequest(
int32_t sessionID,
int32_t cseq,
const sp<ParsedMessage> &data) {
int32_t playbackSessionID;
sp<PlaybackSession> playbackSession =
findPlaybackSession(data, &playbackSessionID);
if (playbackSession != NULL) {
playbackSession->updateLiveness();
}
AString response = "RTSP/1.0 200 OK\r\n";
AppendCommonResponse(&response, cseq);
response.append(
"Public: org.wfa.wfd1.0, SETUP, TEARDOWN, PLAY, PAUSE, "
"GET_PARAMETER, SET_PARAMETER\r\n");
response.append("\r\n");
status_t err = mNetSession->sendRequest(sessionID, response.c_str());
if (err == OK) {
err = sendM3(sessionID);
}
return err;
}
该函数会将Source端支持的所有方法通知给Sink端。同样的，Sink端也会填充类似的状态信息函数onReceiveM2Response。 如果回复信息中没有错误信息，即RTSP服务端返回的状态码为200,则表示RTSP服务端提供Source端需要的那些RTSP方法。
接下来，Source端会因为发送onOptionsRequest请求成功而继续调用sendM3函数以GET_PARAMETER方法发送获得Sink端所支持媒体流的内容保护（HDCP）支持性、视频格式信息、音频编码格式信息以及rtp客户端端口等信息的请求。Sink端则会调用onGetParameterRequest处理函数回复Sink端支持的相关信息。目前代码里可以看到Sink端并不支持内容保护特性。接下来，基本流程符合RTSP在进行媒体流通信的流程，这里就不做太多介绍。当流程调用到函数sendM5时，Source端会向Sink端发送SETUP命令，Sink端调用sendSetup启动sink端RTP线程，其中会利用createUDPSession创建UDP连接来传递音视频数据流。之后Source端会调用onSetupRequest函数做相应响应，如开启与编码Source端、打包相关的PlaybackSession线程，此过程算是Source端的核心代码，涉及到的内容较多如SurfaceFlinger等，希望有机会详细展开来介绍。当Setup流程结束后，Sink端通过sendPlay函数发送PLAY请求，Source端调用onPlayRequest函数做相应响应。如果playbackSession能够正常播放，则通过调用finishPlay函数完成开始播放的最后一些任务，如向Source端发送kWhatSessionEstablished消息，调用IRemoteDisplayClient的onDisplayConnected函数向应用层提供Wifi Display连接状态回调。
mClient->onDisplayConnected(
mClientInfo.mPlaybackSession->getSurfaceTexture(),
mClientInfo.mPlaybackSession->width(),
mClientInfo.mPlaybackSession->height(),
mUsingHDCP
? IRemoteDisplayClient::kDisplayFlagSecure
: 0);
该函数执行成功后，还会将Source状态由ABOUT_TO_PLAY改变为PLAYING。
当Sink端接收到Source端的数据流后，会调用/av/media/libstagefright/wifi-display/sink/RTPSink.cpp
下的parseRTP函数向TunnelRenderer类发送kWhatQueueBuffer消息，使其通过调用以下函数
/av/media/libstagefright/wifi-display/sink/TunnelRenderer.cpp
mStreamSource->doSomeWork();更新Sink端测试播放器PlayerClient在内存中的相关数据。具体流程放在下一回去做分析。
1077
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
