开始分析MediaServer源码前，结合官方文档说明，对各文件夹源码总结如下：

groupsock 静态库，封装了network interfaces和sockets。举例而言，Groupsock类中封装了一个收发组播数据包的socket。

liveMedia 静态库，定义了一系列类簇，根类为Medium，这些类支持了多种媒体类型和编解码器。

WindowsAudioInputDevice 静态库，实现了liveMedia中的AudioInputDevice虚基类，可为Windows程序提供从输入设备中读取PCM audio samples的功能。

UsageEnvironment 静态库，内部主要有如下几个虚基类：

TaskScheduler 为DelayedTask、socket后台操作处理、事件event提供调度支持HashTable 定义通用hash表的接口，供其他代码使用UsageEnvironment 集成TaskScheduler、groupsock、liveMedia等模块功能，添加Result、Error消息机制，从而提供使用环境。

BasicUsageEnvironment 静态库，由于UsageEnvironment中仅给出虚基类定义，为了能够真正地运行，所以从UsageEnvironment继承并实现了BasicUsageEnvironment类。它用于实现易用的命令行程序，其中，Read events和delayed operations通过select()循环进行支持。

mediaServer 可执行文件，通过逻辑集成上述库所提供的的功能，提供串流服务。

MediaServer

MeidaServer运行效果如图所示：

面对一个庞大的项目工程，想要分析源码，必须先找出有效突破口，本文中将从live555MediaServer.cpp 中main()函数开始切割工程。

1. main()

main()函数并不复杂，下面列出整理后的源码：

int main(int argc, char **argv) { // 准备使用环境 TaskScheduler* scheduler = BasicTaskScheduler::createNew(); UsageEnvironment* env = BasicUsageEnvironment::createNew(*scheduler); // RTSP Server授权控制，默认关闭. 如需开启，按如下步骤： // 1. define ACCESS_CONTROL // 2. authDB->addUserRecord("xxxx", "xxxx"); UserAuthenticationDatabase* authDB = NULL; #ifdef ACCESS_CONTROL authDB = new UserAuthenticationDatabase; authDB->addUserRecord("username1", "password1"); #endif // 创建RTSPServer，默认使用554端口，如已被占用或其他错误，则尝试使用8554端口 RTSPServer* rtspServer; portNumBits rtspServerPortNum = 554; rtspServer = DynamicRTSPServer::createNew(*env, rtspServerPortNum, authDB); if(rtspServer == NULL) { rtspServerPortNum = 8554; rtspServer = DynamicRTSPServer::createNew(*env, rtspServerPortNum, authDB); } if(rtspServer == NULL) { *env << "Failed to create RTSP server: " << env->getResultMsg() <<"\n"; exit(1); } // 打印版本信息、rtspURL前缀、及其他说明信息 *env << ... //@1 尝试建立一个HTTP server，用于提供 RTSP-over-HTTP通道，尝试端口为80， 8000， 8080 if(rtspServer->setUpTunnelingOverHTTP(80) || rtspServer->setUpTunnelingOverHTTP(8000) || rtspServer->setUpTunnelingOverHTTP(8080)) { *env << "(We use port " << rtspServer->httpServerPortNum() << " for optional RTSP-over-HTTP tunneling, or for HTTP live streaming (for indexed Transport Stream files only).)\n"; } else { *env << "(RTSP-over-HTTP tunneling is not available.)\n"; } //@2 开启事件循环 env->taskScheduler().doEventLoop(); return 0; }

源码分析：

@1 建立HTTP server 所谓Tunneling，实质上分为三个步骤：

将源数据（无论什么格式）抽象为简单数据发送端使用目标协议对数据进行包裹，此处为HTTP接收端参照协议对数据解包，重新获得源数据

为什么要进行HTTP Tunneling? 因为部分客户端可能为iPhones或iPads，而这些设备仅支持Apple家的HLS(HTTP Live Streaming)机制的串流。具体信息可参阅官方文档中Streaming to iPhones and iPads一节。

@2 开启事件循环 时间循环的开启实质上是通过UsageEnvironment的TaskScheduler中doEventLoop()函数完成的，这是整个Server活过来的key，因此必然需要进一步跟踪进去。

2. env->taskScheduler().doEventLoop()

先放源码：

void BasicTaskScheduler0::doEventLoop(char volatile* watchVariable) { while(1){ //@1 wathcVariable if(watchVariable != NULL && *watchVariable != 0) break; //@2 SingleStep() SingleStep(); } }

源码分析：

@1 watchVariable 当且仅当watchVariable有值时提前break 查找doEventLoop()调用处，发现除main()中该值为NULL外，其他地方都给出了变量用于控制执行。 调用者分别有：

* live555MediaServer -> main() * DynamicRTSPServer * AC3AudioStreamFramer * DVVideoStreamFramer * H264VideoFileServerMediaSubsession * H265VideoFileServerMediaSubsession * MP3StreamState * MPEG1or2FileServerDemux * MPEG4VideoFileServerMediaSubsession * SIPClient

@2 SingleStep 查找得到该函数实现部分位于BasicTaskScheduler中。

此处不免有些困惑，为何不直接放在类BasicTaskScheduler0中？ 为了解开这个困惑，此处先粗略整理如下继承、功能关系（后续会具体分析）：

虚基类TaskScheduler 内含DelayedTask、socket operations background handling以及直接的EventTrigger三类事件处理接口。BasicTaskScheduler0 : public TaskScheduler 主要实现doEventLoop()函数及DelayedTask、EventTrigger部分BasicTaskScheduler : public BasicTaskScheduler0 主要实现SingleStep()函数及background handling部分

3. SingleStep()

放出整理后源码：

void BasicTaskScheduler::SingleStep(unsigned maxDelayTime) { fd_set readSet = fReadSet; fd_set writeSet = fWriteSet; fd_set exceptionSet = fExceptionSet DelayInterval const& timeToDelay = fDelayQueue.timeToNextAlarm(); struct timeval tv_timeToDelay; tv_timeToDelay.tv_sec = timeToDelay.seconds(); tv_timeToDelay.tv_usec = timeToDelay.useconds(); // .tv_sec过大（<= 11.5days）会引发select()失败，所以先规范tv_timeToDelay值域 ... //@1 select int selectResult = select(fMaxNumSockets, &readSet, &writeSet, &exceptionSet, &tv_timeToDelay); if(selectResult <0) { if( GetLastError() != EINTR ) { // 异常错误，视为严重故障；打印错误信息后退出 print_Set_info(); abort(); } } else //if(selectResult <0) { //@2 HandlerIterator, HandlerDescriptor, HandlerSet HandlerIterator iter(*fHandlers); HandlerDescriptor* handler; //@3 fLastHandledSocketNum if(fLastHandledSocketNum >= 0) { // 如已处理过socket读写，则找到前次socket读写的下一个链表节点 while((handler = iter.next()) != NULL) { if(handler->socketNum == fLastHandledSocketNum) break; } if(handler == NULL) { // 未找到，重置相关值 fLastHandlerSocketNum = -1; iter.reset(); } } while((handler = iter.next()) != NULL) { // 找到链表中合法节点，开始处理 int sock = handler->socketNum; int resultConditionSet = 0; if(FD_ISSET(sock, &readSet) && FD_ISSET(sock, &fReadSet)) resultConditionSet |= SOCKET_READABLE; if(FD_ISSET(sock, &writeSet) && FD_ISSET(sock, &fWriteSet) resultConditionSet |= SOCKET_WRITEABLE; if(FD_ISSET(sock, &exceptionSet) && FD_ISSET(sock, &fExceptionSet) resultConditionSet |= SOCKET_EXCEPTION; if((resultConditionSet&handler->conditionSet) != 0 && handler->handlerProc != NULL) { // 保存当前处理节点socketNum fLastHandledSocketNum = sock; (*handler->handlerProc)(handler->clientData, resultConditionSet); break; } } // while((handler = iter.next()) != NULL) if(handler == NULL && fLastHandledSocketNum >= 0) { // 上一次处理的socketNum不为0，且未在当前链表中找到，但只要链表本身不为空，就必须处理socket读写 int sock = handler->socketNum; int resultConditionSet = 0; if(FD_ISSET(sock, &readSet) && FD_ISSET(sock, &fReadSet)) resultConditionSet |= SOCKET_READABLE; if(FD_ISSET(sock, &writeSet) && FD_ISSET(sock, &fWriteSet) resultConditionSet |= SOCKET_WRITEABLE; if(FD_ISSET(sock, &exceptionSet) && FD_ISSET(sock, &fExceptionSet) resultConditionSet |= SOCKET_EXCEPTION; if((resultConditionSet&handler->conditionSet) != 0 && handler->handlerProc != NULL) { fLastHandledSocketNum = sock; (*handler->handlerProc)(handler->clientData, resultConditionSet); break; } if(handler == NULL) fLastHandledSocketNum = -1; } //@4 fTriggersAwaitingHandling && fLastUsedTriggerMask if(fTriggersAwaitingHandling != 0) { if(fTriggersAwaitingHandling == fLastUsedTriggerMask) { fTriggersAwaitingHandling &= ~fLastUsedTriggerMask; if(fTriggeredEventHandlers[fLastUsedTriggerNum] != NULL) { (*fTriggeredEventHandlers[fLastUsedTriggerNum])(fTriggeredEventClientDtas[fLastUsedTriggerNum]); } } else { unsigned i = fLastUsedTriggerNum; EventTriggerId mask = fLastUsedTriggerMask; do{ i = (i+1)%MAX_NUM_EVENT_TRIGGERS; mask >>= 1; if(mask == 0) mask = 0x80000000; if((fTriggersAwaitingHandling&mask) != 0) { fTriggersAwaitingHandling &= ~mask; if(fTriggeredEventHandlers[i] != NULL) { (*fTriggeredEventHandlers[i])(fTriggeredEventClientDatas[i]); } fLastUsedTriggerMask = mask; fLastUsedTriggerNum = i; break; } } while(i != fLastUsedTriggerNum); } } } //@5 hadnleAlarm fDelayQueue.hadnleAlarm(); }

源码分析：

@1 select select(或pselect)允许进程监控多个文件描述符(fd)，阻塞直到至少一个fd处于I/O操作ready状态为止。 通常fd会在可进行进行块读取或高效写操作时，切换为ready状态。

当select成功时，会返回参数中三个set(read/write/exception)之一的fd，如返回值为0，表示超时前并未出发任何fd。 如果返回值为-1，表示函数出错，可进一步获取文件错误代码（Window使用WSAGetLastError, Linux中直接使用errno值）并进行判断分析：

EBADF set参数中存在无效fdEINTR 中断信号EINVAL nfds参数为负数，或timeout时长无效ENOMEM 内部表格分配内存失败

更进一步的select说明，将在后续单独说明后给出链接。

@2 HandlerIterator, HandlerDescriptor, HandlerSet 千言万语不如一张图。下图中列出三者关系，颜色与说明相对应。

那么问题来了，该双向链表是怎么产生的？也就是说谁，何时，在哪里调用了HandlerSet::assignHandler()函数？ 通过查找assignHandler，发现唯一调用入口为BasicTaskScheduler::setBackgroundHandling; 进一步的，调用setBackgroundHandling()函数的有如下位置：

GenericMediaServer::ClientConnection::ClientConnection() READABLE|EXCEPTION incomingRequstHandlerSocketDescriptor::registerRTPInterface() READABLE|EXCEPTION tcpReadHandlerRTSP::RTSPClient() READABLE|EXCEPTION incomingDataHandlerRTSPClient::openConnection() READABLE|EXCEPTION incomingDataHandlerRTSPClient::openConnection() READABLE|EXCEPTION incomingDataHandlerRTSPClient::connectToServer() WRITABLE|EXCEPTION connectionHandlerRTSPClient::handleAlternativeRequestByte1() READABLE|EXCEPTION incomingDataHandlerRTSPClient::connectionHandler1() READABLE|EXCEPTION incomingDataHandlerRTSPServer::RTSPClientConnection::handleAlternativeRequestByte1() READABLE|EXCEPTION incomingRequestHandlerRTSPServer::RTSPClientConnection::changeClientInputSocket() READABLE|EXCEPTION incomingRequstHandlerTCPStreamSink::processBuffer() WRITABLE socketWritableHandler

大致分析可得出如下结论：

事件来源主要为创建RTSP实例，RTSPClient、RTSPServer间交互，以及TCPSink进行Buffer处理事件Handler对应为Request处理，连接建立、接收数据处理，以及TCP读写

事件部分本篇就到此为止，后续将更进一步展开分析。

@3 fLastHandledSocketNum fLastHandledSocketNum只有两种取值可能：

-1 ：HandlerSet为空时，因此默认值也为-1已成功处理过得Handler socketNum值

具体执行过程，已在上述源码中添加注释。

@4 fTriggersAwaitingHandling && fLastUsedTriggerMask 由于event handler会修改可读socket set，因此我们在处理完socket后才开始检查Event情况。 fTriggersAwaitingHandling和fLastUsedTriggerMask都是以32bit值进行实现的，也就是说，使用时，他们的每一个bit都具有意义。 默认情况下，fTriggersAwaitingHandling值为0，fLastUsedTriggerMask为1。而源码中可以看到，如fTriggersAwaitingHandling为0值时，是不会启动event trigger机制的。

因此首先要找到，fTriggersAwaitingHandling值会首先在哪里被修改。结果如下：

BasicTaskScheduler0::deleteEventTrigger() fTriggersAwaitingHandling &= ~eventTriggerIdBasicTaskScheduler0::triggerEvent() fTriggersAwaitingHandling |= eventTriggerId;

即Event处理机制启动前，必须先triggerEvent进行添加，且在处理前未deleteEventTrigger才可以生效。 fLastUsedTriggerMask的功效和fLastHandledSocketNum类似，都只是为了更快的定位到开始点，并进行循环查找。

@5 hadnleAlarm socket IO和event都处理完后，终于轮到延时任务，它是通过handleAlarm进行处理。

handleAlarm()

惯例先放源码：

void DelayQueue::handleAlarm() { // @1 synchronize if(head()->fDeltaTimeRemaining != DELAY_ZERO) synchronize(); if(head()->fDelatTimeRemaining == DELAY_ZERO) { DelayQueueEntry *toRemove = head(); removeEntry(toRemove); toRemove->handleTimeout(); } }

源码分析： * @1 synchronize 检查到DeltaTimeRemaining不为0时，需要进行同步。这里需要补充下定时器的概念。

> 定时器实现 > 计算机中存在两种时钟，分别为： > * 硬件时钟，电池供电，也称为RTC，在系统关机时起作用 > * 系统时钟，基于RTC根据CPU中断计时，电脑运行时有效 > > 两者频率并不严格相同，细节部分这里不具体讨论，这里只要知道系统时钟的前提是CPU中断即可。 假设开启了一个计时器，比如Sleep(5000),然而CPU每个时钟周期并非以ms为单位，如2.4GHz的CPU，时钟周期为(1/2.4G)s，因此每个时钟周期或中断产生（具体机制视CPU而定），会检查剩余时间是否为0甚至小于0。时钟周期的差异会引发计时器的误差，也因为如此，计时器都是有精度的，并非都能实现所需精度。 回到源码，这里的DelayedTask也是使用了类似的定时器机制，每次同步仅仅是跟当前时间作比较，并跟新timeSinceLastSync。 当timeSinceLastSync >= fDeltaTimeRemaining时，判定为定时器timeout，并执行对应TaskFunc()。

总结

至此，MediaServer大的轮廓已经分析完毕，主要相关的动线有三条：

Socket I/OEventDelayedTask 只要牢牢抓住这三条动线，结合相关入口、出口，就可以将MediaServer源码的血肉充实起来。本篇中如有疑虑或错误指出，还请大家指出。同样可以提出想要着重了解的内容，后续更新会选择性加入其中。