| 平台 | 内核版本 |
|---|---|
| RK1108 | Linux3.1 |
流媒体服务器架构
在网络带宽上传输实时的视音频流媒体数据时要求传输实时性必须远高于传输可靠性。但是，由于互联网络并不是完全的等时系统，在数据包传送的过程中可能会出现延迟、抖动或不按顺序到达的情况，这就需要在传输层之上添加额外的流媒体传输及控制协议来解决这些问题。于是IETF提出了RTSP和RTP`RTCP等一系列新的协议来满足实时数据的传输要求。根据这些协议的功能特点，可将它们分为数据传输协议和控制协议两部分。  在实际的VLC`画面中各协议：
RTSP协议标准化了客户端与服务器的信令和信息交互；RTP协议则完成了组合、分片或直接封装已编码压缩的视频数据的工作，并将之交予底层网络发送至客户端；RTCP协议负责统计和发送数据包接收情况，辅助客户端、服务器和第三方监控系统即时应对网络拥塞，控制网络流量，提高服务质量。
网络摄像机首先采集摄像头中的视频数据，然后按帧对其进行H.264 软件编码，最后交由RTP 模块将视频数据发送到客户端。通常情况下，RTP和 RTCP 模块会使用相邻 UDP 端口号，如果 RTP 使用的端口号为 8000，那么RTCP 将会使用 8001 端口号。
RTSP协议
实时流协议（RTSP，Real Time Streaming Protocol）是由 Netscape、哥伦比亚大学（Columbia University）和 Real Networks 三方1998年共同提出的、用于控制实时数据传输的应用层协议。
该协议提供了一个基于文本描述的可扩展框架，添加新方法或者新参数都非常的简便。它很出色地分离了实时数据流的控制和传输，在大多数情况下并不负责发送连续媒体流，实时数据则一般交由 RTP/RTCP 协议处理。它使用 RTSP 会话（RTSP session）完成了从客户端到服务器的控制，并将若干数据流抽象为表示（Presentation），进一步方便了客户端对多个同步流的统一控制、管理。
因此，RTSP 更像是一部由客户端掌控的“网络遥控器”，实现了远程控制媒体服务器的录制、回放、播放和暂停等操作
RTSP 消息
RTSP 是基于文本的协议，采用ISO 10646 字符集和 UTF-8 编码方案。消息是RTSP媒体服务器与客户端互相通讯的基本单位，分为请求消息和响应消息两大类，都可能包括一个起始行、若干头部域、表示头部域结束的空行和一个可选的消息主体。
请求消息
RTSP 请求消息的结构如下图所示，在请求消息中，起始行由方法（Method）、请求 URI（Request-URI）、RTSP 版本三部分内容组成，各部分之间使用空格符分隔开，并在行尾以 CRLF 结束。它向服务器传达了需要处理的资源、作用于资源的方法和消息的版本信息。
一般来说，RTSP 版本字段为“RTSP/1.0”，请求 URI 是一个 RTSP URL 格式的地址，如“rtsp://media.example.com:8554/live”。其中“rtsp”前缀要求使用 TCP等可靠协议发出命令，而“rtspu”前缀则说明使用 UDP 等不可靠协议。如果端口为空或没指定，则缺省为 554端口。
请求 URI主要用于描述媒体服务器向客户端提供的网络资源（如音频流、视频流）。它既可以指向一个表示，也可以指向一个流，但是并不暗含服务器的具体文件系统结构。另外，RTSP 消息中的 OPTIONS、SETUP、PLAY 和 TEARDOWN 四种方法必须实现。
应答消息
一般来说，应答消息是从服务器反馈给客户端的，格式如图所示。其首行即是状态行，该行由协议版本、数字形式的状态码（Status-Code）以及与状态码对应的原因解释（Reason-Phrase）依序组成，各元素间以空格分隔，并以 CRLF结尾。
协议版本与请求消息一致，内容为“RTSP/1.0”。状态码由 3 位数字组成，
- “
1XX”用于告知客户端请求已收到，继续处理； - “
2XX”指示操作成功收到，并已处理完毕； - “
3XX”表明要完成请求必须进一步操作； - “4XX”告知请求发生错误，无法受理；
- “5XX”说明服务器端发生错误
对于媒体服务器而言，常用的状态码有“200”（成功），“250”（存储空间不足）和“400”（错误的请求）等。原因解释（Reason-Phase）是用简短的文字来描述状态码产生的原因，这仅是为了方便人的查看，并不需要程序对其进行解析。请求接收方可以在响应头部域（Response Header）中附加更多的响应信息，这些信息包括服务器和资源访问信息等。
交互流程
实时流协议是控制媒体服务器实时发送音视频等实时数据的应用层协议。在大部分时候，它与 RTP/RTCP协议密切配合，分别完成流媒体的控制和传输。
客户端与服务器的交互流程如下：
- 客户端使用 OPTIONS 方法去询问服务器支持的方法；服务器则在 Public 头部域（Public Header Field）里列出它所支持的所有方法；
- 客户端调用 DESCRIBE 方法从服务器取得请求 URL（Request-URL）所标识的表示或者媒体对象的描述，主要是提供多媒体资源的
RTSP URL 地址等媒体初始化（Media Initialization）信息； - 针对某个 URI 的 SETUP 消息详细说明了将要用于流媒体的传输机制，它主要包括客户端所支持的传输协议等传输初始化（Transport initialization）信息；
- 客户端发送
PLAY或PAUSE请求消息，可让服务器分别执行播放或暂停请求URL所标记的媒体资源； TEARDOWN请求会通知服务器停止所给 URI 的流传输，释放与它相关的资源。例如，释放与资源相关的会话标识和媒体数据的传输端口等。
RTP协议
实时传输协议（RTP，Real-Time Transport Protocol）设计之初是用于传输声音文件，并在 1991 年 8 月由美国的一个实验室发布了第一版。经过一系列发展，RTP 协议已经能够提供非常好的实时性，适用于音视频等实时数据的传输，最新的协议规范在 RFC3550 文档中阐述。
为了简化传输层处理，提高该层的效率，RTP 只负责数据的有序打包与发送，并完全依靠 RTCP 协议提供流量控制和拥塞控制的服务，其常见工作方式如图 所示。
RTP 包头格式
RTP 协议没有为实时服务提供资源预留，若需要则可以使用 RSVP 协议完善；并不保证顺序传送和接收，但可以根据 RTP 报头的序列号（SN，Sequence Number）进行包的重排序。该协议被设计成与底层传输网络无关，支持几乎所有通信协议，并主要选择 UDP 承载提供了非常好的实时性。
RTP 包头格式如图 所示，负载类型（PT）占 7 比特，代表有效载荷的格式，如 H.263++、MPEG-4 或 H.264 等视频格式。序列号的初始值是随机的，但是每发送一个数据包序列号加 1，主要用于检测丢包和重建包序列。时间戳（Time Stamp）的初始值应当也是随机的，它表明包中首字节数据的采样时间。SSRC，即同步源标识，应该在 RTSP 会话中尽量保持唯一，因此它也应当是一个随机值。
H.264 编码技术
H.264/AVC 是由国际电信联盟标准化组织的视频图像专家组（VCEG）和国际标准化组织的运动图像专家组（MPEG）共同组成的联合视频组（JVT）所开发的视频编码标准，被称作 ISO/IEC14496-10 或MPEG-4/AVC。
H.264/AVC 视频编解码标准具有网络适应性强、低码率和强容错能力等特点。它的分层结构是经过精心设计的，如图显示，最大的特点是取消了序列层和图像层，并将原本属于序列和图像头部的大部分句法元素游离出来，分别形成了序列参数集（SPS）和图像参数集（PPS），而其余的部分则放入片（Slice）层中。
同时，因为取消了图像层，片成为实际存在的最大的图像单元，每个片都携有所属图像的编号、大小等基本信息。这使得通信的鲁棒性大大增强，也很好地适应不同传输网络的最大传输单元长度（MTU size，Maximum Transfer Unit Size）。
该标准适用于各种传输网络，最主要是因为将图像压缩系统分成网络抽象层（NAL，Network Abstraction Layer）和视频编码层（VCL，Video Coding Layer），从而实现了压缩编码与网络传输的分离，如图 所示。VCL 包括核心压缩引擎和块、宏块及片的语法级别的定义；而 NAL 则负责将 VCL 产生的比特字符串适配到各种各样的网络环境中，它覆盖了所有片级别以上的语法级别。
如图上所示，一个 NAL 单元（NAL Unit）包含有两个部分：一个字节的 NALHeader 和一个原始字节序列载荷（RBSP，Raw Byte Sequence Payload）。RBSP可以是编码片、A/B/C 型数据分片、序列参数集、图像参数集等。根据 RBSP 的类型，NAL 单元分为 VCL-NAL 单元和非 VCL-NAL 单元。NAL Header 为一个字节，由定长的 NAL 类型、禁止位（F）和 NRI 三部分组成。NAL 单元类型如表所示
RTCP协议
实时传输控制协议（Real-time Transport Control Protocol，RTCP）使用与发送多媒体数据包相同的机制，周期性地向会话中的参与者发送控制包。它要求底层协议必须提供数据包与控制包的多路复用，比如使用不同的 UDP 端口号。该协议能够提供流量控制、Qo S（服务质量）和拥塞控制等服务，与 RTP 联合为终端系统提供更加稳定的实时数据。
它主要提供如下服务：
- ⑴通过发送报告和接收报告的统计数据反馈数据传输质量。
- ⑵使用规范名（CNAME，Canonical Name）作为传输层识别符，标记每一个RTP 源，可以用来同步同一个终端系统的语音和图像。
- ⑶与会成员变动非常大的时候，各个成员可以依据反馈信息独立调整发包速率。
- ⑷控制信息量最小化，使得数据信息最大化，这能够适应大规模实时数据业务。
RTCP 协议提供有 5种包类型，用户可以根据应用场合进行选择，包类型通过公共报文头的 PT字段来区分，分为发送者报告（SR）、特定应用包（APP）、接收者报告（RR）、源描述包（SDES）和离开包（BYE）五类。
接收者报告
对于网络摄像机而言，它需要处理接收者报告，分析网络传输环境，通过调整音频或者视频码率，来控制好 RTP 包的发包速率，从而提升视频服务质量。
接收者报告（RR）大部分时候由两个部分组成，见图 。第一部分用于提供版本（V）信息、接收报告块计数(RC)、包类型（PT）和包长度（Length）等信息；若填充位（P）置 1，则 RTCP 包在末端包含一些非控制信息的附加填充比特，可以用于固定长度块的加密算法。
第二部分是若干接收报告块，其块数等于从上一个报告以来该接收者侦听到的源的数目，每个接收报告块传输从某个同步源来的数据包的接收统计信息，这些信息有 SSRC（同步源标识符）、丢包率（Fraction Lost）、累计丢包数（CumulativeNumber of Packets Lost）和间隔抖动（Interarrival Jitter）等重要接收质量信息。
源描述包（SDES）
源描述包（SDES）是一个三层结构，包括一个头部域和若干块（Chunk）。头部域中的包类型值为 202，如图 。每一个块都单独地描述一个特定的数据源，如音频源、视频源等。这些源的描述信息由多条项目（Item）给出，并且紧跟在对应的 SSRC/CSRC 标识符之后。
终端系统应该发送一条 SDES 包，专门用于描述自己的 SSRC 标识符；混合器（Mixer）也应该发送一条描述各个贡献源（ContributingSource）的 SDES 包。如图 所示，每一个项目包括一字节的类型（Type）域、一字节的指示文本长度的长度（Length）域和文本（Text）内容。文本长度以字节为单位，并且不计前两个字节头。CNMAE 的类值为 1，这也是每个源所必须含有的标志性属性。当类型值为 2、3 分别表示 NAME 和 EMAIL 属性。
来源：CSDN
作者：雪松研究所
链接：https://blog.csdn.net/qq_33487044/article/details/104649579