在网络视频监控系统应用中，主要有两种数据需要传输，一种是视音频流的传输，即“数据通道”，一种是控制信息的传输， 即“信令通道”。其中视音频流的特点是数据信息量大，占用绝对的带宽资源，实时性要求高，但是少量的信息丢包是可以接受的； 而控制信息的特点是信息量比较少，但是传输要求绝对高质量、高可靠，不允许丢包。

IPC的数据通道及信令通道示意图如下所示：

视音频流传输过程中，视频流首先需要完成编码压缩、 然后用RTP协议进行封装打包，接着再用UDP协议对RTP数据包进行封装，即把RTP协议数据封装在UDP的消息字段，并叠加UDP包头，最后由IP网络层封装为IP数据包，经历上述完整的处理过程后，视音频才能发送到网络上进行传输。

视频流的封装过程图如下所示， MPEG-4数据流分别被封装上RTP报头、 UDP报头和IP报头，然后IP数据包通过网络发送。

RTP视频流的传输过程图如下所示：

RTP本身不提供可靠的传送机制以及流量控制或拥塞控制，它依靠RTCP提供这些服务。在RTP会话期间，各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。基于RTCP的反馈机制, 发送端可以评估网络状态和接收端情况，及时利用这些信息动态改变传输速率甚至有效载荷（Playload）类型，以尽可能地解决网络实时数据传输中出现的不可预测的延迟、抖动等问题。基于发送端的码率控制主要有改变编码量化参数、丢帧和帧率控制三种方法。

RTP协议

实时传输协议（RTP ，Real-Time Transport Protocol）是用于多媒体数据流在网络上传输的一种传输协议。传送音视频数据通常都会采用基于UDP的RTP协议传输， RTP为数据流提供时间信息和实现流同步。 RTP协议位于UDP协议之上，在功能上独立于下面的传输层   （UDP）和网络层，但不能单独作为一个层次存在，通常是利用低层的UDP协议对实时视音频数据进行组播（Multicast）或单播（Unicast），从而实现多点或单点视音频数据的传输。RTP数据流结构示意图如下所示：

视频流完成编码压缩后，在传输之前需要进行打包(RTP数据包由RTP包头和不定长的连续媒体数据载荷组成)，给MPEG-4视频流打包的目的是更好地适应网络传输，让解码显示端能够恢复MPEG-4数据流并进行回放。

  MPEG-4的视频流是以VOP为单位编码的，在传输前，将视频流加上包头信息，然后进行RTP打包封装，MPEG-4视频流是RTP数据包中的载荷(Payload)部分。 RTP数据包的结构如下图所示：

使用Wireshark工具抓取的RTP包内容如下：

RTSP协议

RTSP(Real-Time Stream Protocol)协议是一个基于文本的多媒体播放控制协议，属于应用层。RTSP以客户端方式工作，对流媒体提供播放、暂停、后退、前进等操作。该标准由IETF指定，对应的协议是RFC2326。

  RTSP作为一个应用层协议，提供了一个可供扩展的框架，使得流媒体的受控和点播变得可能，它主要用来控制具有实时特性的数据的发送，但其本身并不用于传送流媒体数据，而必须依赖下层传输协议(如RTP/RTCP)所提供的服务来完成流媒体数据的传送。RTSP负责定义具体的控制信息、操作方法、状态码，以及描述与RTP之间的交互操作。

• RTSP协议：负责服务器与客户端之间的请求与响应
• RTP协议：负责传输媒体数据
• RTCP协议：在RTP传输过程中提供传输信息

  rtsp承载与rtp和rtcp之上，rtsp并不会发送媒体数据，而是使用rtp协议传输。

  rtp并没有规定发送方式，可以选择udp发送或者tcp发送。

RTSP媒体服务协议框架如下图所示。

从图中可以看出，RTSP和RTP，RTCP配合使用。RTSP传输的一般是TS、MP4格式的流，其传输一般需要2~3个通道，命令和数据通道分离。使用RTSP协议传输流媒体数据需要有专门的媒体播放器和媒体服务器，也就是需要支持RTSP协议的客户端和服务器。

客户端要播放RTSP媒体流，就需要知道媒体源的URL，RTSP的URL格式一般如下：

rtsp://host[:port]/[abs_path]/content_name

host: 有效的域名或IP地址；

port: 端口号，缺省为554，若为缺省可不填写，否则必须写明。

例如，一个完整的RTSP URL可写为：rtsp://192.168.1.67:554/test

又如目前市面上常用的海康网络摄像头的RTSP地址格式为：

rtsp://[username]:[password]@[ip]:[port]/[codec]/[channel]/[subtype]/av_stream

RTMP协议

实时消息传输协议（Real-Time Messaging Protocol）是目前直播的主要协议，是Adobe公司为Flash播放器和服务器之间提供音视频数据传输服务而设计的应用层私有协议。RTMP协议是目前各大云厂商直线直播业务所公用的基本直播推拉流协议。

  RTMP协议主要的特点有：多路复用，分包和应用层协议。

  多路复用（multiplex）指的是信号发送端通过一个信道同时传输多路信号，然后信号接收端将一个信道中传递过来的多个信号分别组合起来，分别形成独立完整的信号信息，以此来更加有效地使用通信线路。

  简而言之，就是在一个 TCP 连接上，将需要传递的Message分成一个或者多个 Chunk，同一个Message 的多个Chunk 组成 ChunkStream，在接收端，再把 ChunkStream 中一个个 Chunk 组合起来就可以还原成一个完整的 Message，这就是多路复用的基本理念。

  RTMP协议的第二个大的特性就是分包，与RTSP协议相比，分包是RTMP的一个特点。与普通的业务应用层协议（如：RPC协议）不一样的是，在多媒体网络传输案例中，绝大多数的多媒体传输的音频和视频的数据包都相对比较偏大，在TCP这种可靠的传输协议之上进行大的数据包传递，很有可能阻塞连接，导致优先级更高的信息无法传递，分包传输就是为了解决这个问题而出现的。

  RTMP最后的一个特性，就是应用层协议。RTMP协议默认基于传输层协议TCP而实现，但是在RTMP的官方文档中，只给定了标准的数据传输格式说明和一些具体的协议格式说明，并没有具体官方的完整实现，这就催生出了很多相关的其他业内实现，例如RTMP over UDP等等相关的私有改编的协议出现，给了大家更多的可扩展的空间，方便大家解决原生RTMP存在的直播时延等问题。

RTMP是Macromedia公司的专有协议（现在归Adobe公司所有），在基于Flash的应用程序流行时非常流行。它有几个品种，支持TLS/SSL加密，甚至还有基于UDP的变种，即RTFMP（实时媒体流协议，用于点对点连接）。RTMP将数据流分割成片段，其大小可以动态变化。在通道内，与音频和视频有关的数据包可以交错和复用。

  RTMP会构建几个虚拟通道，在这些通道上传输音频、视频、元数据等。大多数CDN不再支持RTMP作为向终端客户分配流量的协议。然而，Nginx有自己的RTMP模块，支持普通的RTMP协议，它运行在TCP之上，使用默认的1935端口。Nginx可以作为一个RTMP服务器，分发它从RTMP流媒体接收的内容。另外，RTMP仍然是向CDN交付流量的流行协议，但在未来，流量将使用其他协议进行传输。

  目前，Flash技术已经过时，且不受支持：浏览器或是减少对它的支持，或是完全禁止使用。RTMP不支持HTML5，在浏览器中也难以使用（播放需要通过Adobe Flash插件）。为了绕过防火墙，他们使用RTMPT（封装到HTTP请求中，并使用标准的80/443而不是1935端口），但这大大影响了延迟和冗余（根据各种估计，RTT和整体延迟增加30%）。尽管如此，RTMP仍然很流行，例如，在YouTube上的广播或在社交媒体上（Facebook的RTMPS）。

  RTMP的主要缺点是缺乏对HEVC/VP9/AV1编码器的支持，以及只允许两个音轨的限制。此外，RTMP在数据包头中不包含时间戳。RTMP只包含根据帧率计算的标签，因此解码器并不确切知道何时解码这个流。这就需要一个接收组件均匀地生成用于解码的样本，因此缓冲区必须按数据包抖动的大小来增加。

  RTMP的另一个问题是重新发送丢失的TCP数据包。为了保持较低的回传流量，确认收到（ACK）并不直接到发件端。只有在收到数据包链后，才会向广播方发送ACKs或NACKs的确认信息。

根据各种估计，使用RTMP进行广播，通过完整的编码路径（RTMP编码器→RTMP服务器→RTMP客户端）的延迟至少是两秒。

RTMP广播用例如下图所示：

全文完。