基于Apple Darwin的流媒体服务器的设计与实现
本科毕业论文
题目基于Apple Darwin的流媒体服务器的设计与
实现
Design and Implementation of Streaming
Media Server Based on Apple Darwin
姓名学号
专业计算机科学与技术
指导教师职称/学位讲师/硕士
中国·武汉
二○一七年五月
分类号密级
华中农业大学楚天学院本科毕业论文
基于Apple Darwin的流媒体服务器的设计与实现
Design and Implementation of Streaming Media Server
Based on Apple Darwin
学生姓名：
学生学号：
学生专业：计算机科学与技术
指导教师：
华中农业大学楚天学院
二○一七年五月
华中农业大学楚天学院毕业论文（设计）
原创性声明
本人郑重声明：所呈交的毕业论文（设计），是本人在导师的指导下，独立进行研究所取得的成果。除文中已经注明引用的内容外，本论文（设计）不包含任何其他个人或集体已经发表或撰写过的作品成果。本人完全意识到本声明的法律结果由本人承担。
作者签名：
日期：年月日
目录
摘要.................................................................................................................................................................. I 关键词.............................................................................................................................................................. I Abstract .......................................................................................................................................................... I Key words...................................................................................................................................................... I 1系统的可行性研究概述 (1)
1.1 系统研究的背景 (1)
1.2 系统研究的目的 (1)
1.3 系统研究的可行性分析 (1)
2 开发工具与主要技术简介 (1)
2.1 开发平台的软件介绍 (1)
2.2 主要技术 (2)
2.2.1 实时传输协议和实时传输控制协议 (2)
2.2.2 实时流媒体协议 (2)
2.2.3 回话描述协议 (2)
2.2.4 包交换流媒体服务 (3)
2.2.5 多媒体流媒体服务 (3)
3 总体设计 (3)
3.1 系统总体结构 (3)
4 系统设计 (4)
4.1 Darwin流媒体服务器连接过程 (4)
4.1.1 Darwin流媒体服务器的框架 (4)
4.1.2 Darwin流媒体服务器的实现 (5)
4.2 Darwin流媒体服务器直播 (6)
4.2.1 Darwin流媒体服务器分布式直播 (6)
4.3 Darwin实时视频转发设计 (7)
4.3.1转发模块设计 (8)
4.3.2转发模块实现 (8)
4.4 Darwin实时视频转发模式 (8)
4.4.1 先拉后推 (9)
4.4.2 先侦听后推送 (10)
4.4.3 Darwin实时视频流推送 (11)
4.5 Darwin流媒体中RSTP请求处理过程 (12)
4.6 Darwin流媒体服务器优化 (15)
4.6.1 Darwin流媒体转发 (15)
4.6.2 HLS打包库优化 (15)
4.6.3 HLS直播Flash Player卡顿优化 (16)
4.6.4低延时直播之转发缓存跟进算法 (17)
5 系统测试 (18)
5.1 云数据库测试 (18)
5.2 Darwin服务器测试 (18)
6 总结 (21)
参考文献 (22)
致谢 (23)
摘要
Darwin流媒体服务器是高性能并发服务器，提供了可跨平台的代码框架。设计上遵从高性能，简单，模块化的程序设计原则，来实现支持RTSP点播，直播的功能，同时其集成nginx服务器文件，实现了HLS的直播功能。
Darwin流媒体服务器采用了Reactor的并发服务设计模式，当线程发生时完成相应的Task,通过调用对应的handle来实现Task。通过调用有限个数Thread来完成handle的调用。时间线程充当Reactor模式中的事件分离器，任务线程充当Reactor模式中事件处理器。Darwin核心流媒体服务是RTSP开源流媒体直播服务。特点是高效，稳定，可靠，功能齐全。通过RTSP流媒体协议，支持安防行业需要的摄像机流媒体转发功能，底层（Select/Epoll网络模型，无锁队列调度）和上层（RESTful接口，WEB 管理，多平台编译），关键帧索引（秒开画面），远程运维方面优化。
关键词
Darwin流媒体服务器；RSTP系统；RTP系统；
Abstract
Darwin streaming media server is a high-performance concurrent server that provides a cross-platform code framework. Design to comply with high-performance, simple, modular programming principles, to achieve support RTSP on-demand, live function, while its integrated nginx server files, to achieve the HLS live function.
Darwin streaming media server uses Reactor's concurrent service design pattern, when the thread occurs when the corresponding Task, by calling the corresponding handle to achieve Task. By calling a limited number of Thread to complete the handle call. The time thread acts as an event splitter in the Reactor mode, and the task thread acts as an event handler in the Reactor mode. Darwin core streaming service is RTSP open source streaming media live service. Features are efficient, stable, reliable, fully functional. Through the RTSP streaming media protocol, to support the security industry needs the camera streaming media forwarding function, the underlying (Select / Epoll network model, no lock queue scheduling) and the upper (RESTful interface, WEB management, multi-platform compilation), key frame index Screen), remote operation and maintenance aspects of optimization.
Key words
Darwin Streaming Media Server；RSTP system；RTP system；
1系统的可行性研究概述
Darwin Streaming Server（简称DSS）是Darwin流媒体服务器，支持很多操作系统比如FreeBSD、Linux、Solaris、Windows NT和Windows 2000等，是目前同类产品中支持平台最多最广的。流媒体服务器Darwin支持标准RTSP/RTP/RTCP协议，具备RTSP点播、直播（推模式和拉模式）、HLS 直播等功能，适应安卓、IOS、微信直播等各终端平台，最大程度实现安防监控、满足移动互联网流媒体的需求，总结起来，根据流媒体服务器的特点和船务通项目的需求分析。
1.1 系统研究的背景
随着网络的飞速发展，计算机的网络已经进入千千万万的家庭，实现了每个家庭都有网络。而在实现的过程中出现了一个现象：存储方式和传输方法的过程已经发生巨大变化，从传统模式的文本信息和简单图像的网页转变成内容丰富多姿多彩的流式媒体信息。流式媒体是通过网络从中获取多媒体信息：如音频流、视频流等。流式媒体对应的传统工作方式是下载模式加上播放模式，当用户先下载多媒体文件，然后再在本地播放。
1.2 系统研究的目的
在窄带网络环境中，几乎所有Internet的流式媒体产品都有着类似的工作原理：首先需要开发高效的压缩编码的技术，通过一套完整有效的传输体系将其发布到用户的桌面上。来实施系统，这种方式设置允许以广播的方式重现这个多媒体服务器。此服务器，都必须有能力提供必需的客户，不仅播放的多媒体文件，而且还，启用上载和创建播放列表与那些已经在服务器域，在未来将被上传的多媒体文件的可能性。部署的服务器组成的一套程序，服务器将有一个软件上传文件另一个，另一个用于转换他们创建的播放列表。终于，最后一个是播放多媒体文件的必要条件。我们会在服务器上，执行过程中发现的问题之一就是协议，服务器的工作，并接受了文件格式由服务器。
1.3 系统研究的可行性分析
Darwin开源流媒体框架满足广大开发者和企业的需求，将整个流媒体的全过程以各个项目的形式提供给开发者、企业。让他们选择性的接入功能，调用功能，再结合现在非常热门的阿里云ECS 云服务器、OSS对象存储、负载均衡等服务功能，实现了流媒体音视频从前端设备到采集编码、推送、传输、分发、存储、设备管理、播放等覆盖传统视频监控行业和互联网行业的全功能、全平台点播、直播的全套服务，但为用户节省了大量的时间成本、试错成本、研发成本和运维成本，还能够带来更好的项目开发体验和上线效果。
Darwin开源流媒体解决方案整体采用的是行业通用的RTSP、RTP、RTCP、HTTP、RTMP、RESTful 协议和标准，对于开发者和企业来说，通用性和可读性都极强。能够广泛用于安防监控、智能家居、教育直播、幼儿园直播等项目，尤其是在安防行业结合移劢互联网方面，Darwin 开源流媒体解决方案提供了非常完善的实现方案。在国家大力支持全民创业、万众创新的大潮中，Darwin开源流媒体解决方案能让创业者能够更加与注于业务创新，简化开发实现流程，缩短技术实现时间，快速试错。
2 开发工具与主要技术简介
2.1 开发平台的软件介绍
本文采用操作系统是基于windows平台的vs2010上开发的。Darwin流媒体服务器源代码完全采用标准的C++语言写成，编程风格优秀，每个C++类都对应一对和类同名的.h和.cpp文件。采用了面对对象的概念，如继承，多态等。图2.1就是开发环境界面。
图2-1 开发环境界面
2.2主要技术
主要技术用到的协议。即文件和编纂用于传输的实时视频和音频文件的格式。
2.2.1实时传输协议和实时传输控制协议
这主要目标是创建一个可以播放流文件到客户端的系统。这些文件后被转换成正确的格式后播放，必须流通过网络提供给客户端文件。工作与RTP控制协议，负责监测服务的质量和传达有关通信会话中的参与者的信息。RTP是提供数据需要实时支持端到端交付服务。这种数据可以实时的音频或者视频，视频会议。UDP是没有服务质量或者保证。它最重要的是RTP不提供机制，以确保及时交付或防止无序数据包传输等功能，每个数据包发送，已帮助接送机重建包序列号。RTP定义被分为实时传输协议和RTP控制协议两个部分。即是负责人进行具有实时属性的数据和监测服务的质量和传达有关回话中的参与者信息。可以看出，RTP的功能是运输，除了数据，有用的信息来执行通信控制。
2.2.2 实时流媒体协议
实时流协议是一种应用层协议，负责控制具有属性的实时如实时视频或音频的数据传递。此协议负责建立和控制会话。由于此协议，客户端有可能播放、暂停和停止流。RTSP工作与其他协议，如RTP/RTCP协议RTSP无法执行流的传输与控制。RTSP充当多媒体服务器的网络远程控制。RTSP 消息可以在TCP或UDP发送和使用88端口号。为了执行RTSP连接，通信必须从客户端将请求发送到服务器上，直到它已发送的最后一个数据包的视频或音频的时刻处于活动状态RTSP支持的操作是客户端可以请求通过HTTP展示说明。含多播的地址和端口，如果演示文稿正在多播，和包含目的地提供的客户端，如果演示文稿是单播。媒体服务器可以加入到现有的会议.服务器和客户端之间的对话。
2.2.3 回话描述协议
远程用户加入会议。此信息包含包括IP地址和多媒体在哪里需要发送的端口号和用于声音和与会者的图像编码的编码解码器。SDP文件分为两个部分。第一个是关于会话级别和第二个，媒体级别的信息。
在SDP文件中，我们可以找到一些进一步的信息，可能有助于执行或知道更多关于流，像功能提示或加密密钥。用于创建流文件的一个重要特征。当用户访问RTSP链接使用SDP协议。第一个动作是描述请求和服务器答案显示可用的信息。这一信息，基于SDP协议。在SDP文件，服务器
显示不同流可用，如用于编纂，分配端口到每个流或每个工作流的带宽。
2.2.4包交换流媒体服务
MP4文件格式，最初来自于QuickTime文件格式，是指在3GPP文件格式。在释放PSS，主要的文件格式是MP4。这种文件格式灵活，支持本地播放和流媒体传输。3GPP媒体文件具有特定的媒体类型，如H.263视频和AMR音频。后释放出现释放和带来新的功能，是用户代理配置文件(UAProf)。
UAProf是一个文件具有扩展名.xml或.rdf。它是一个配置文件加访问实时环境中的无线设备中的数据的API。这允许用户设备与服务器根据客户端的物理能力相适应。设备的功能大部分被定义在用户配置文件或UAProf。这些配置文件，存储在配置文件中，指定的设备型号和版本。此信息可用于流媒体服务器。
2.2.5 多媒体流媒体服务
音频和视频流是MSS的一部分。MSS是结构点对点服务。流媒体服务支持实时流和伪流，检索的预编码内容和实时编码两个部分的内容。
3总体设计
3.1 系统总体结构
Darwin 开源流媒体解决方案可分为流媒体数据流、信令控制流两大部分，接入管理接口服务器CMS、流媒体服务器Darwin、存储不回放服务器RMS可直接运行在阿里云主机ECS上，CMS服务器负责进行设备和客户端的接入不管理，Darwin服务器负责进行流媒体音视频的分发和HLS切片，RMS服务器负责对直播流进行实时存储和录像检索，还有其他功能模块。
CMS服务器设备管理与接入服务器，Darwin流媒体服务器，RMS录像存储服务器，都能够分布式、平行部署、无限扩容，云端各个节点的服务单元都将负载信息写到共享的redis中进行数据共享，EasyCMS将在线设备相关信息写入到redis，Darwin服务器将负载信息和流媒体直播相关信息写入redis，这样在多个CMS服务器、Darwi n服务器之间就可以进行直播级联，Session共享，Token 验证等功能，框架图：
图3-1 Darwin开源流媒体解决方案架
如图3-1Darwin开源流媒体解决方案。Camera摄像机硬件启动后，启动Camera进程。Camera 向CMS服务器发送注册报文，并定期发送报活报文，维持摄像机与CMS服务器的TCP连接。CMS
服务器会对Camera发送注册报文进行权限验证，通过验证后的设备信息写入Redis中，也会将CMS 服务器的信息一起写入。Client向CMS服务器请求直播视频流，CMS服务器会在Redis中查找设备是否在线，第二步会查找该设备是否存在流媒体转发消息。如果存在，则直接将改直播流信息响应给Client，如果不存在，CMS服务器需要向Camera发送启动直播流推送的命令，CMS服务器再将Camera反馈的结果响应给Client，Client根据收到的结果进行播放。
Darwin流媒体服务器模块分为两种，一是动态模块，二是静态模块。动态模块在服务器启动伊始就会加载，而静态模块在这之后才会加载。Register是每个模块中必须支持的一个角色，服务器会在每个模块被装载后，就调用这些模块的Register角色。Register角色的主要工作就是初始化，例如对数据结构的初始化和内存分配的初始化等。它会调用QTSS Add Role来记录这个模块支持的其他角色，之后服务器就会初始化角色并且调用每个拥有这个角色的模块。在关闭服务器时，Shutdown 角色就会被各个模块调用，然后这些模块就会释放内存完成结束工作的处理。通过这些角色流媒体服务器就可以完成它的任务了图3-2服务器启动和关闭的流程显示的是服务器在启动和关闭的时候如何和Register（登记），Initialize（初始化），和Shutdown（关闭）这些角色协同工作的.。
图3-2 服务器启动和关闭流程
4 系统设计
4.1Darwin流媒体服务器连接过程
4.1.1 Darwin流媒体服务器的框架
图4-1 Darwin流媒体服务器流程
如图4-1所示Darwin流媒体服务器流程。实体线就是Darwin流媒体服务器进行流媒体数字流推送的过程，虚线就是关于CMS消息管理服务器的信令流。整个框架的流程是客户端向CMS服务器发送请求，CMS服务器将请求发送Darwin流媒体服务器，Darwin流媒体服务器将信息反馈给CMS服务器。Camera发送请求给Darwin服务器，Darwin服务器发送请求到RMS服务器。
4.1.2 Darwin流媒体服务器的实现
图4-2Darwin流媒体服务器流程图
如图4-2Drawin流媒体服务器流程图。Darwin服务器在接收到Camera直播推送后，将该设备的直播流信息写入到Redis中，这样就方便第3步中CMS服务器直接对设备直播流信息进行检索；Darwin服务器会定期检查设备直播流的客户端数量检查，当设备的Output数量由 > 0 减为0，或者在Darwin服务器内部巡检中发现规定事件内没有客户端请求，Darwin服务器会向CMS服务器发送设备直播流释放请求，CMS服务器再通过信令发送给Camera，停止Camera向Darwin服务器推送直播流。
4.2 Darwin流媒体服务器直播
Darwin流媒体服务器直播是基于RTSP协议,RTP协议和RTCP协议。在验证模块中加入支持信息，再加上使用动态码支持客户端缓冲，设置音频和视频分离发送模式一致，来降低复杂度，共享反射模块，也是共享其他服务器的直播源，用反射机制形成一个直播级联系统。提供对传送H.264，MPEG-4和3GPP文件，还允许使用Icecast兼容协议，通过HTTP传送标准的MP3文件到MP3客户端。如图4-3Drawin流媒体服务器直播流程图。
图4-3 Darwin流媒体服务器直播流程图
4.2.1 Darwin流媒体服务器分布式直播
如图4-4Drawin流媒体服务器分布式直播的流程图。其中有设备接入服务，视频分布服务，设备端，客户端四大模块。
图4-4 Darwin流媒体服务器分布式直播流程图
设备接入服务。在大部分在大部分的分布式服务器中，接入服务器常常属于被动接入形式，当然也有接入服务器主动接入配置的前端设备，这里我们按照接入服务器被动接收设备注册的方式介绍。按照被动的设备注册方式，设备在接入到服务器后，会与接入服务器建立一个交互的会话，以TCP方式进行连接并发送保活包，那么我们可以在原有DSS的RTSPSession基础上进行改造，改成属于自定义协议的交互流程，底层的网络读取与发送结构完全一致，只需要修改上层对收到的报文的处理，那么对于多路会话的维护也可以直接用原来对RTPSession列表的维护方式，改写Hash表fMySessionMap，用GetMySessionMap()从服务器主体获取，Hash表的主键可以按照自定义协议里的唯一标识进行，如前端设备的ID、ip等等。自定义协议部分就只需要参考DSS对RTSP的处理，改成自己的协议处理（文本协议、字节流协议）就可以了。
视频分布服务。分发服务器的修改就方便了，如果还是按照RTSP的方式进行流媒体发布，那基本就不需要修改了，直接用DSS在QTSSReflectorModule中已经有的被动接收推送的方式进行转发就可以了，设备在收到接入服务的媒体开始命令后，立即推送视频到DSS分发服务，通过DSS 已有的RTSP Announce、Setup、Play、RTP流程推送媒体数据，DSS再将媒体数据分发到客户端列表中。
设备端。设备协议也是自己定义的，本文用live555嵌入到设备（如IpC，硬盘录像机等）中，在live555中先定义一个RTSPClient，连接保活到接入服务，通过此条连接与接入服务始终保持通信，那么接入服务通过此条tcp发出开始视频的命令时，live555再开启另一条RTSPClient，通过live555已有的DarwinInjector类，经过RTSP Announce、Setup、Play、RTP过程，将流注入到DSS 中，在接入发出停止命令时，终止DarwinInjector的流注入，发出RTSP Teardown到DSS，停止媒体传输。如图4-5以live555为基础框架。
图4-5live555为基础框架
客户端。标准RTSP流程，不需要修改，客户端先请求到接入服务，接入服务发出RTSP 重定向的响应到客户端，重定向地址为分发服务的地址，客户端再转而去请求分发服务，这时候，分发服务已经获取到了设备推送来的媒体流，转发给客户端。
整个流程可以按照自己的需求进行修改，如：客户端请求到接入服务器后，接入服务器可以只判断请求的设备是否在线，如果不在线，返回404，如果在线，直接返回301，重定向到的分布式服务器，分布式服务器再通过与接入服务器的交互，通过接入服务器的信令通路控制设备发起视频，设备再成功发起视频后，再返回到分发服务器，成功回到客户端，如此，整个流程通过。
4.3Darwin实时视频转发设计
Darwin进行实时视频转发的两种模式中，本文描述了流媒体服务器对源端音视频转发的两种模式，其中一种拉模式转发。在传统视频监控行业，IP摄像机部署在监控内网的各个地点，我们需要将他们进行集中式的管理，并且对外发布，这时候我们就需要用到一台流媒体服务器，能够拉取所
需的摄像机的音视频流，并做转化（如RTMP、HTTP等），作为监控内网与公网的中转，提供转发服务。如下图4-6Drawin流媒体服务器实时视频转发所示。
图4-6 Darwin流媒体服务器实时转发流程
4.3.1转发模块设计
拉模式转发中，转发服务器一方面作为RTSP客户端的角色，向源端摄像机获取音视频数据，另一方面作为服务器的角色，将拉取到的音视频数据，重新作为数据源，分发给正在请求的客户端。源端数据流到服务器的数据流能够复用，也就是一路进多路出。服务器端维护所有正在分发的摄像机源列表。服务器与源端在空闲状态下无连接，只有在有需要的情况下才发起连接过程。当所有客户端结束对某个源端请求时，服务器停止从源端获取数据，断开连接。
Darwin系统需要RTSPClient客户端实现、RTP分发流程（ReflectorSession）实现。Darwin拉模式转发模块，我们定义此模块名称为QTSSOnDemandRelayModule，意为只有在有需要的时候，才会转发；Darwin与源端用于交互、保存信息、接收数据的ClientSession，为了不影响Darwin原有的架构，没有直接在RTSPClient类中修改，而是自定义类：RTSPClientSession，实例化RTSPClient 对象为其成员变量。在RTSPClientSession中，所有RTSP流程都由fClient（RTSPClient对象）完成，RTSPClientSession负责进行变量存储（如服务器地址fAddr、端口fPort、用户名fName、密码fPassword）、收到数据包统计（fStates、fNumPacketReceived）、RTSPClient控制（SETUP发送fNumSetups、RTSP断开fTeardownImmediately）、以及在非客户端断开情况下，服务器与摄像机间的重连。
4.3.2转发模块实现
拉模式转发模块名称为：QTSSOnDemandRelayModule，需要分别实现对RTSP和RTP的转发和处理，分别处理QTSS_RTSPPreProcessor_Role（RTSP消息处理）、QTSS_RTSPRelayingData_Role （拉取的RTP数据处理）、QTSS_ClientSessionClosing_Role（客户端或RTSPClientSession断开处理）。在*QTSS_RTSPPreProcessor_Role（RTSP消息处理）中，本文设计的拉模式转发为名称与地址映射的方式，映射列表配置在xml文件中，在QTSSOnDemandRelayModule初始化时，将配置映射表加载到模块中。在*QTSS_RTSPRelayingData_Role（拉取的RTP数据处理）中，RTSPClientSession获取到一个RTP包时，调用QTSS_RTSPRelayingData_Role，将RTP包Push给ReflectorSession进行分发。在*QTSS_ClientSessionClosing_Role（客户端和RTSPClientSession断开处理）中，ReflectorSession客户端引用数统计、客户端端断开流程、RTSPClientSession断开流程，基本与RTSPSession（客户端与设备推送）方法一样。
4.4 Darwin实时视频转发模式
Darwin服务器实时流媒体有两种模式（拉模式和推模式）。Darwin支持两种自动播送的场景：先拉后推。为了发起自动播送，RTSP客户会发送标准的RTSP请求来向服务器请求一个流，然后服
务器将该流中继到一个或者多个流媒体服务器。这种场景在"先拉后推"部分中加以描述。先侦听后推送。在这个场景中，自动播送在流媒体服务器接收到ANNOUNCE请求时被发起。这个场景在"先侦听后推送"部分中进行描述。先侦听后推送的流程，具体流程可以大致描述为：源端或者中继端（我们称之为推送端）先通过主动的连接，告知推送端信息(ID,IP等等)，服务器维护与源端的会话Session，建立一定的保活与超时机制，并通过此路Session相互交换控制或者上送信息，其中就包含流媒体推送的命令。可按照具体的需求，服务器可通过命令发送的方式，开启源端的推送流程（通过已经建立的Session自定义开启交互的命令），也可以是源端主动开始推送流程（DSS中描述为Broadcast广播），具体的RTSP推送流程大致为：Announce、Setup、Play、RTP(DSS为RTP over TCP)。这种模式的转发通常用于类似于3G视频监控这种难以穿透的网络类型的数据的转发。如图所示4-7Darwin服务器实时流媒体推送流程图。
图4-7 Darwin服务器实时流媒体推送流程图
4.4.1 先拉后推
用户可以通过发送标准的DESCRIBE/SETUP/PLAY请求来向远程的源中请求一个流，然后将它中继转发到一个或者多个目的地。当只希望让外部流的一份拷贝占用其内部连接的带宽时，这个功能可能有用。中继转发获取一份拷贝进行多份的复制和转发、分发到请求的客户端。图4-7先拉后推式提供了一个先拉后推（pull-then-push）场景的实例。
图4-8先拉后推式
如图4-8先拉后推式的步骤：流媒体服务器A（转发服务器）发送标准的RTSP客户DESCRIBE/SETUP/PLAY请求给远程服务器，即流媒体服务器B。发起请求的中继“客户端”（流媒体服务器A）开始接受流，然后向该输入流的中继配置中列出的所有目的地发送ANNOUNCE推送请求。
4.4.2 先侦听后推送
流媒体服务器可以被配置为将ANNOUNCE请求创建的输入流自动发送到一个或者多个目的地。这可能可以用于配制自动播送网络。图4-8提供了一个先侦听后推送的场景的实例。
图4-9先侦听后推送式
以图4-9先侦听后推送式作为参考，先侦听后推送场景的步骤如下：远程机器（IpCamera等前端设备或者中继服务器）向流媒体服务器A发送一个ANNOUNCE请求。流媒体服务器可以接受或者否认这个请求。如果它接受了请求，则流媒体服务器会检查其中继配置，以确定这个流是否应该被中继。如果该流应该被中继，则流媒体服务器将向自身发送标准的RTSP客户DESCRIBE/SETUP/PLAY请求。发出请求的中继“客户”（流媒体服务器A）开始接收流，然后向相应的输入流的中继配置中列出的所有目的地发送一个ANNOUCE请求。在缺省情况下，认证对于自动播送是必要的。来自播送器的ANNOUNCE请求需要通过服务器中活跃的认证机制来过滤。为了支持播送认证，需要在qtaccess文件中加入一个新的WRITE指令。这个新的指令使得SDP文件可以被写入到媒体文件夹(Darwin中为Movies文件夹)中。
先侦听后推送实现的流程是Announce->Setup->Play->RTP数据接收与转发进行详细的分析。在Darwin流媒体服务器中，处理推送报文的模块为QTSSReflectorModule，其中维护了一个静态的转发列表sSessionMap，用于存储各个转发会话的信息。下面就对具体的报文解析和数据处理进行分析。
RTSP Announce命令为源端向服务器端主动发起的上报本地媒体sdp信息的命令，处理函数为QTSSReflectorModule模块的DoAnnounce()函数。首先判断server配置中的enable_broadcast_announce字段是否为true，开启了广播推送转发，在通过获取
inParams->inRTSPRequest（在RTSPSession::Run调用前复制的当前请求的rtspRequest对象）的字典中的qtssRTSPReqLocalPath键值作为标识转发的唯一区别：.\Movies/test.sdp，必须以sdp结尾，可以修改sSDPSuffix进行配置)，这里的值既是一个标识，又是一个路径，用于存储获取到的sdp数据，后面此标识作为存储于sSessionMap中对象的键值。函数中通过对头字段的解析，获取到Content-Length:字段值，进而去读取具体的spd值，再存储到qtssRTSPReqLocalPath路径中，返回200 OK。解析DoSetup中isPush为true（表示为推送的Session）这条路路径，具体isPush值由Setup 请求中的mode值有关，mode="receive" || mode="record"表示isPush为true。完成ReflectorSession 的创建，下一步解析track ID，具体的解析方法可以根据自己的实际应用，有的按照track%d解析，有的按照trackID=%d解析，再根据trackId获取具体的track sdp信息，AddRTPStream创建对应于具体track的RTP流。DoPlay过程，isPush为true的路径就比较简单了，只是将推送的RTSPSession 中的RTSPBroadcastSessionAttr属性设置为前面DoSetup中获取到的ReflectorSession。ProcessRTPData(),这里只处理RTP over TCP的数据，根据RTP数据中的channel值，调用特定的ReflectorStream进行处理和转发，具体函数为：ProcessRTPData()，先通过前面在DoSetup() & isPush 为true时设置的sRTSPBroadcastSessionAttr属性，获取ReflectorSession再根据channelID获取具体的ReflectorStream并进行数据推送，给具体的ReflectorStream进行处理。
4.4.3 Darwin实时视频流推送
Pusher是一个推送RTSP流媒体音/视频流给RTSP流媒体服务器的标准RTSP/RTP协议推送库，Pusher就可以避免接触到稍显复杂的RTSP（ANNOUNCE、SETUP、PLAY）/RTP/RTCP推送流程，只需要调用EasyPusher的几个API接口，就能轻松、稳定地把流媒体音视频数据推送给RTSP服务器（Darwin Streaming Server、EasyDarwin、live555）进行转发和分发。如图4-10 EasyPusher基本调用流程所示。
图4-10 EasyPusher基本调用流程
4.5 Darwin流媒体中RSTP请求处理过程
本文将具体深入到RTSPSession内部，分析RTSPSession对每一个RTSP请求的处理过程。如图4-11RTSP请求处理过程所示。
图4-11 RTSP请求处理过程
在处理RTSP请求的流程中，Darwin流媒体主要采用了状态机(state machine)的处理方式。流程是进入初始化状态,实际在此状态中读取请求报文的方式与后续在kReadingRequest的读取及处理的方式是一致的，只不过在第一次进行Request处理的时候需要检测该请求的方式是以普通RTSP的方式，还是以RTSP-over-HTTP tunneling方式进行报文交互,检测步骤为kHTTPFilteringRequest对报文内容进行过滤，检查是否有HTTP报文中所出现的一些关键字(POST/GET等),是则直接进入RTSP-over-HTTP状态处理的下一步:kSocketHasBeenBoundIntoHTTPTunnel，否的话进入kHaveNonTunnelMessage状态。进入kHaveNonTunnelMessage：状态，说明请求报文格式是正确的，请求已进入受理状态，故在此状态中对fReadMutex,fSessionMutex进行加锁,禁止在处理报文的过程中接收以RTP Interleaved接收RTP数据或者发出RTSP响应报文.重置响应缓冲区并进入下一个状态kFilteringRequest.在处理RTSP请求的时候，服务器调用RTSP Filter（过滤器）角色。它会调用所有注册了RTSP Filter角色的模块，并将RTSP请求对象作为参数传递给它。每个RTSP Filter角色都可以改变qtssRTSPReqFullRequest属性的值。比如说，一个RTSP Filter角色可以把/foo/foo.mov 改为/bar/bar.mov，从而改变用于满足请求的文件夹。任何处理RTSP Filter角色的模块对客户端进行
响应，都会导致服务器跳过其它已经注册了RTSP Filter角色的模块，以及跳过已经注册其它RTSP 角色的模块，然后立即调用该响应模块的RTSP Postprocessor（后处理）角色。这里所说的对客户进行响应是指模块向客户端发送任何形式的数据。在调用了所有RTSP Filter（过滤器）角色之后，服务器就会对请求进行解析。解析请求包括填充RTSP对象剩余的属性值，以及创建下面两个会话：一个RTSP会话(RTSPSession)，和当前这个特定的请求相关联，在客户端关闭与服务器之间的RTSP 连接时，这个会话也会被关闭。一个客户会话(RTPSession)，和产生当前请求的客户端连接相关联，这个会话会一直保持，直到客户端的流播放结束。RTSP请求解析完成之后，服务器会以RTSP Route （路由）角色调用所有注册了该角色的模块，并传入一个RTSP对象。每个RTSP Route角色都可以使用RTSP对象中的属性值来确定是否要改变qtssRTSPReqRootDir属性的值，进而改变用于处理当前请求的目录。举例来说，如果语言的类型是French（法语），则模块可以把qtssRTSPReqRootDir 属性修改到包含法语版本的被请求文件的目录下。
任何处理RTSP Route角色的模块对客户端进行响应，会导致服务器跳过其它注册RTSPRoute 角色的模块，以及跳过注册了其它RTSP角色的模块，并且立即调用响应模块的RTSP Postprocessor （后处理）角色。在调用了所有RTSP Route角色之后，服务器就会以RTSP Preprocessor角色调用每个注册了该角色的模块。通常情况下，RTSP Preprocessor角色会通过qtssRTSPReqAbsoluteURL 属性值来确定当前请求是否和模块处理的请求的类型相匹配。kPreprocessingRequest：如果请求的类型互相匹配，则RTSP Preprocessor角色就调用QTSS_Write或者QTSS_WriteV函数来向客户发送数据，对客户端进行响应。如果只需要发送标准响应，则模块可以调用QTSS_SendStandardRTSPResponse，或者QTSS_AppendRTSPHeader和QTSS_SendRTSPHeaders函数。
任何处理RTSP Preprocessor角色的模块对客户端进行响应，都会导致服务器跳过注册了RTSP Preprocessor角色的所有其它模块，以及跳过注册了其它RTSP角色的所有模块，并且立即调用响应模块的RTSP Postprocessor角色。如果没有RTSP Preprocessor角色对RTSP的请求进行响应，则服务器就以RTSP Request（请求）角色调用成功注册了该角色的模块（第一个注册RTSP Request角色的模块，是唯一一个可以注册RTSP Request角色的模块）。RTSP Request角色负责响应所有没有被RTSP Preprocessor角色（的模块）处理过的RTSP请求。
RTSP Request角色对请求进行处理之后，服务器就调用注册了RTSP Postprocessor角色的模块。RTSP Postprocessor角色通常执行一些统计任务，比如记录各种统计信息。处理RTSP Preprocessor 或者RTSP Request角色的模块可能需要为特定的客户会话生成一些媒体数据。如果这样的话，模块可以通过调用QTSS_Play函数来实现，这个函数会使模块的RTP Send Packets（RTP发送数据包）角色被调用。RTP数据包发送：RTP Send Packets角色调用QTSS_Write或者QTSS_WriteV函数，在RTP会话的基础上向客户发送数据。当RTP Send Packets角色发送完成一些数据包之后，就会把控制权返回给服务器，并指定服务器下次调用模块的RTP Send Packets角色的间隔时间。这个周期会一直重复，直到所有的媒体数据包被发送完成，或者由于客户请求的原因需要暂停或中止客户会话为止。如图4-12RTP请求流程图。