文章目录
RTSP (Real-Time Streaming Protocol) 实时流式协议
RTP (Real-Time Transport Protocol) 实时运输协议
RTCP (RTP Control Protocol)实时运输控制协议
RTP over TCP
SIP (Session Initiation Protocol) 会话初始协议
SDP(Session Description Protocol 会话描述协议)
RTMP (Real Time Message Protocol, 实时消息协议)
GB/T 28181 -- 2016
WebRTC (Web Real-Time Communications, Web 实时通信)
WebSocket
WebAssembly
流媒体相关著名项目
多媒体信息的数据量往往很大
例如音频：标准的PCM编码的立体声音乐(采样速率44.1kHz，采样脉冲16位编码)信号的比特率超过了1.4Mbit/s。
例如视频：分辨率1280×720，每个像素采用24位RGB编码，帧率24fps，则其比特率将超过60Mbit/s。
因此网络传输多媒体信息都无一例外地采用各种压缩技术，如MP3(128kbit/s)，MP4(40Mbit/s).
传输多媒体数据对时延和时延抖动要求较高
数字化后的多媒体数据，在发送端其分组往往是等时地发送的，但互联网本身并非等时的，而接收端只有按照原视频文件的规定速率读取帧才能正常播放，因而又是等时的。解决该问题的一个可行方法是在接收端设置适当大小的缓存。当缓存中的分组达到一定数量时再以恒定速率取出分组进行还原播放。缓存使得所有不定时到达的分组都经受了时延，导致了固定的播放时延，但在很大程度上消除了时延抖动。
互联网传输实时数据的分组有可能差错或丢失，如果利用TCP协议对这些丢失分组进行重传，那么延时就会大大增加。因此实时数据的传输在运输层就当采用用户数据报协议UDP而不是TCP协议。也就是说我们宁可丢失分组，也不要太晚到达的分组。另外，分组到达不一定按序，而分组播放又需要按序，因此分组中应当含有序号。分组还应当增加一个时间戳以使接收端知道分组是何时产生的。这些都需要新的协议支持才行。
互联网上的多媒体服务大体有：流式(streaming)存储多媒体，流式(streaming)实况多媒体，实时交互式多媒体
播放流媒体，服务端通常有两个分开的服务器，一个普通的服务器，一个媒体服务器。用户和普通服务器建立连接以获取元文件，通过元文件中的信息，请求媒体服务器中的源视频。
现代的流媒体通信协议栈
RTSP (Real-Time Streaming Protocol) 实时流式协议
由IETF MMusic小组开发，已成为互联网建议标准[RFC 2326]。RTSP本身并不传送数据，而仅仅是是媒体播放器能控制多媒体流的传送，暂停播放，快进快退等。实际媒体数据的传输可以用RTP协议或其他专用协议。RTSP以客户-服务器方式工作，它是一个应用层的多媒体播放控制协议。它和Http协议有些相似，但它不像Http，而是有状态的，而且可以在TCP和UDP上传输。默认端口554。
RTP (Real-Time Transport Protocol) 实时运输协议
由IETF AVT小组开发，已成为正式标准，同时也是ITU-T的标准[RFC 3550, 3551]。RTP为实时应用提供端到端的运输，但不提供对服务质量的保证，需要RTCP来保证质量。RTP类似于一个协议框架，它只包含实时应用所需的共同功能，其本身并不对多媒体数据做任何处理，而只是在应用层数据前追加了一些附加信息，让应用层知道该如何处理。另外，应用层数据被封装成的RTP分组只包含RTP数据，而控制是由另一个配套使用的协议RTCP提供的。RTP没有分发机制，它必须与UDP一起使用。RTP必须为偶数端口号，而下一奇数UDP端口留给同一会话中的RTCP使用。默认情况，RTP端口为5004，RTCP端口为5005。
有效载荷类型：7位，指出后面的RTP数据的媒体格式，让接收应用知道如何处理。如音频：a律PCM(8), G.722(9); 视频：JPEG(26), H.264(96)
序号：每发送一个RTP分组，其序号加1。初始值是随机的。
时间戳：反映的是RTP分组中数据的第一个字节的采样时刻。时间戳的粒度(也即增量)取决于发送的数据类型。
RTCP (RTP Control Protocol)实时运输控制协议
与RTP配合使用的协议，也是RTP协议中不可分割的一部分。RTCP的主要功能：服务质量的监督和反馈，媒体数据间的同步，以及多播组中成员的标志。RTCP分组很短，通常多个分组封装在一个UDP数据报中。
RTP over TCP
由于使用UDP存在端口占用较多，互联网上的网关路由器或者防火墙常常设置分组过滤，从而导致UDP数据包被拦截产生丢包等问题，后来又出现了RTP over TCP技术，产生了面向连接的传输数据包帧实时传输协议(RTP) 和实时传输控制协议(RTCP)。RTP/RTCP和RTSP的控制命令和数据都通过一个端口，即RTSP的端口进行交互。会使得RTP包封包和解包的过程变得更加复杂。TCP是可靠的传输协议，但正是因为如此，会导致在实时流媒体中的延时。
Below will describe the essential for using RTSP/RTP over TCP
SETUP
To use TCP communication, you need to request TCP connection during RTSP SETUP. You have to sent SETUP command with Transport：
Transport: RTP/AVP/TCP;interleaved=0-1 This will tell the server to send media data with TCP and interleave the data in channel 0 and 1.
Given in the specification, data channel is even number and control channel is odd (data_ch_num + 1). So, if you data channel is 0, your control channel will be 0 + 1 = 1. Below is an example of TCP SETUP；
After the setup, RTP data will be sent through the TCP socket that is used for RTSP commands. The RTP data will be encapsulate in the following format
| magic number | channel number | embedded data length | data |
magic number - 1 byte value of hex 0x24 RTP数据标识符，"$"
channel number - 1 byte value to denote the channel
embedded data length - 2 bytes to denote the embedded data length
data - data packet, ie RTP packet, with the total length of the embedded data length
RTP和RTCP数据会以$符号＋1个字节的通道编号＋2个字节的数据长度，共4个字节的前缀开始，RTSP数据是没有前缀数据的。RTP数据和RTCP数据的区别在于第二个字节的通道编号，如前所述。
Below is a full example of the communication exchanged
Also, as RTSP is a application protocol, it has no way to control how TCP timeout the connection. Thus, during the RTSP SETUP, a Session is given to identify the connected stream
Session = "Session" ":" session-id [ ";" "timeout" "="delta-seconds ]
If Session is given, each subsequence RTSP command must be sent with the session so that the server can identify the stream.
Also, please note that timeout is an optional value. The default value for timeout is 60 seconds.
So, it is advisable to send a RTSP command to the server every 60 second to keep the TCP connection alive.
Read RFC 2326 Section 10.12 Embedded (Interleaved) Binary Data for more details
SIP (Session Initiation Protocol) 会话初始协议
由IETF MMusic小组开发，互联网建议标准[RFC 3261-3264]。该应用层的协议并不完全依赖于TCP或UDP，而有一套自己的可靠传输机制。
SIP系统只有两种构件，即 用户代理(user agent, UA) 和 网络服务器。
用户代理为逻辑终端实体，由 用户代理客户(UAC) 和 用户代理服务器(UAS) 组成，UAC发起呼叫，UAS接收呼叫并作出响应。(这里容易产生歧义，注意并不是某终端实体的UAC发起呼叫，自己的UAS接收呼叫，而是另一个终端实体的UAS接收呼叫。UAC和UAS的关系就像人类的口耳。)
网络服务器分为代理(proxy)服务器和重定向(redirect)服务器。注意：不要把这里的服务器和用户代理服务器或者和SIP的客户端-服务器特点搞混。SIP服务器是一个逻辑实体，实际实现上可能有多种类型或者在不同条件下提供不同的服务。正如这里所划分的那样，而且还可能存在其他类型。
代理服务器接收UAC的呼叫请求，将其转发给被呼叫用户或下一跳代理服务器，然后下一跳代理服务器再把呼叫请求转发给被叫用户的UAS，并把UAS的响应转发回UAC。
一个请求消息有可能通过若干个代理服务器来传送, 每一个代理服务器独立地确定路由; 响应消息沿着请求消息相反的方向传递。代理通常需要数据库或位置服务的辅助来完成确定下一跳地址。代理服务器就像一个路由器，只不过工作在应用层。 代理服务器有3个特点：它不发起请求，仅响应来自UA的请求，CANCEL和ACK除外；它没有媒体功能；它不解析消息体，仅依赖消息头。
重定向服务器负责规划SIP呼叫路由，它不接受呼叫。它响应告诉呼叫方下一跳代理服务器的地址，由呼叫方根据此地址向下一跳代理服务器发起呼叫，此后重定向服务器退出呼叫过程。
另外，SIP有一套跟踪用户的机制，通过使用SIP注册服务器(Registrar)可以找出被叫用户使用的IP。每一个用户都有一个相关联的SIP注册器，用户在任何时候发起SIP应用时，都应当向SIP注册器发送SIP REGISTER报文，报告当前使用的IP地址，让注册器备案。SIP注册器通常和SIP代理服务器在同一台主机上。
为何有 2：？SIP 代理发送响应401, 并在响应的消息头 WWW_Authenticate 字段中给出适合SIP 代理的认证体制和参数;
这里的SIP代理是：SIP 客户端、 网关、SIP 设备、 联网系统等 SIP 代理(SIP UA) 注册和注销时应进行认证,
认证方式应支持数字摘要认证方式, 高安全级别的宜支持数字证书的认证方式, SIP 代理注册成功则认为SIP 服务器为在线状态,
注册失败则认为SIP 服务器为离线状态;SIP 服务器在SIP 代理注册成功后认为其为在线状态,SIP 代理注册过期则认为其为离线状态。
SIP地址，支持邮件地址，电话号码和IP地址等，如IPv4：sip:jiang@192.168.1.25
SIP会话共有三个阶段：建立会话，通信和关闭会话。中间的通信阶段使用传送实时数据的协议。SIP是一个带外协议，即发送和接收SIP报文使用了一个不同于发送和接收媒体数据的套接字。SIP报文和Http类似。SIP要求所有报文都有确认，因此它能在UDP或TCP上运行。
SIP充分借鉴了HTTP协议，操作过程类似HTTP的请求，响应事务模型。每个操作的调用体现为一个事务，它包含一个请求和一到多个响应。请求消息：其Method字段标识了调用操作的类型，有REGISTER，INVITE，ACK，CANCEL，BYE，OPTIONS；SUBSCRIBE，REFER，INFO，MESSAGE。响应消息：返回处理结果。类似于HTTP的状态码，1XX-6XX。
一个示例INVITE报文：
INVITE sip:support@chaos.example.org SIP/2.0
Via: SIP/2.0/UDP 45.2.32.1:5060 ;branch=z9hG4bK67865
Max-Forwards: 70
To: <sip:support@chaos.example.org>
From: A. N. Sarkovskii <sip:sarkovskii@45.2.32.1>;tag=7643545
Call-ID: 0140092501
CSeq: 1 INVITE
Subject: Bifurcation Question
Contact: <sip:sarkovskii@45.2.32.1>
Content-Type: application/sdp
其中，信令1、8、9、10、11、12为SIP服务器接收到客户端的呼叫请求后通过 B2BUA 代理方式建立媒体流接收者与媒体服务器之间的媒体流信令过程,信令2~ 7为SIP服务器通过三方呼叫控制建立媒体服务器与媒体流发送者之间的媒体流信令过程,信令13~ 16为媒体流接收者断开与媒体服务器之间的媒体流信令过程,信令17~ 20为 SIP 服务器断开媒体服务器与媒体流发送者之间的媒体流信令过程。
SIP进一步学习
SDP(Session Description Protocol 会话描述协议)
SIP还有一个配套协议就是SDP。SDP用于描述媒体详情和媒体协商的协议。SDP是互联网建议标准[RFC 2327,4566–2006] 。SIP终端之间通过SDP交换媒体信息，WebRTC中也使用了SDP。
==Session description:==
v= (protocol version)
o= (owner/creator and session identifier)
s= (session name)
u= * (URI of description)
c= * (connection information-not required if included in all media)
==Time description:==
t= (time the session is active)
==Media description:==
m= (media name and transport address)
c= * (connection information-optional if included at session-level)
b= * (bandwidth information)
a= * (zero or more media attribute lines)
y= * (SSRC)
f= * (媒体描述)
部分字段用法说明：
► a 字段:
a=rtpmap: <payload type> <encoding name>/<clockrate>[/<encoding parameters>] 如：a=rtpmap:96 DAHUA/90000;
a=downloadspeed: 下载倍速(取值为整型)
a=downloadspeed: 下载倍速(取值为整型)
a=setup:TCP 连接方式(表示本 SDP 发送者在 RTP over TCP 连接建立时是主动还是被动发起 TCP 连接, “active”为主动, “passive”为被动)
a=connection:new (表示采用 RTP over TCP 传输时新建或重用原来的 TCP 连接, 可固定采用新建 TCP 连接的方式)
a=svcspace: 空域编码方式
a=svctime: 时域编码方式
► s 字段:
使用s字段标识请求媒体流的操作类型。 “Play”代表实时点播; “Playback”代表历史回放; “Download”代表文件下载; “Talk”代表语音对讲
► u 字段:
u应填写视音频文件的URI。 普通方式采用http://存储设备ID[/文件夹]* /文件名, [/文件夹]* 为0-N 级文件夹
► m 字段:
m 字段描述媒体的媒体类型、 端口、 传输层协议、 负载类型等内容。 传输方式采用“RTP/AVP”标识传输层协议为 RTP over UDP, 采用“TCP/RTP/AVP”标识传输层协议为 RTP over TCP。
如：“m=video 6000 RTP/AVP 96” 标识媒体类型为视频或视音频, 传输端口为6000, 采用 RTP over UDP 传输方式, 负载类型为96。
► t 字段:
当回放或下载时, t 行值为开始时间和结束时间, 用“ ”分隔
► f 字段:
f = v/编码格式/分辨率/帧率/码率类型/码率大小 a/编码格式/码率大小/采样率
v表视频，编码格式：1. MPEG-4 2. H.264 3. SVAC 4. 3GP 帧率(十进制整数字符串表示) : 0~99
a表音频，编码格式：1. G.711 2. G.723.1 3.G.729 4. G.722.1
音频编码码率:
1———5.3 kbps (注: G.723.1 中使用)
2———6.3 kbps (注: G.723.1 中使用)
3———8 kbps (注: G.729 中使用)
4———16 kbps (注: G.722.1 中使用)
5———24 kbps (注: G.722.1 中使用)
6———32 kbps (注: G.722.1 中使用)
7———48 kbps (注: G.722.1 中使用)
8———64 kbps (注: G.711 中使用)
采样率:
1———8 kHz (注: G.711/ G.723.1/ G.729 中使用)
2———14 kHz (注: G.722.1 中使用)
3———16 kHz(注: G.722.1 中使用)
4———32 kHz(注: G.722.1 中使用)
目前主要的开源SIP协议栈包括有:
1. OPAL。它是基于Openh323的架构前提, 优化音视频的编解码和传输内容, 对所有的VOIP协议进行多层次的抽象, 处于不断成熟和完善的阶段
2. ReSIProcate。是支持新一代的rfc3261的独立SIP协议栈, 体现出高稳定性、兼容性强的特性
3. osip2。在对原有协议栈进行封装处理的前提下, 由C语言编写而成的SIP开发源码的协议栈, 具有较大的开发难度和工作量, 且必须与其他协议栈相整合使用
4. PJSIP。由C语言编写而成的一种开源协议栈, 适用于嵌入式SIP功能的开发和应用, 也是智能家居网关设计开发的首选
RTMP (Real Time Message Protocol, 实时消息协议)
RTMP是由Adobe公司提出的一种应用层的协议，用来解决多媒体数据传输流的多路复用（Multiplexing）和分包（packetizing）的问题。
RTMP协议是应用层协议，是要靠底层可靠的传输层协议（通常是TCP）来保证信息传输的可靠性的。在基于传输层协议的链接建立完成后，RTMP协议也要客户端和服务器通过“握手”来建立基于传输层链接之上的RTMP Connection链接，在Connection链接上会传输一些控制信息，如SetChunkSize,SetACKWindowSize。其中CreateStream命令会创建一个Stream链接，用于传输具体的音视频数据和控制这些信息传输的命令信息。
RTMP协议传输时会对数据做自己的格式化，这种格式的消息我们称之为RTMP Message，而实际传输的时候为了更好地实现多路复用、分包和信息的公平性，发送端会把Message划分为带有Message ID的Chunk，每个Chunk可能是一个单独的Message，也可能是Message的一部分，在接受端会根据chunk中包含的data的长度，message id和message的长度把chunk还原成完整的Message，从而实现信息的收发。
播放一个RTMP协议的流一般经过以下三步：握手（Handshake），建立连接（connect），建立流（CreateStream），播放（play）。
客户-服务器间只能建立一个连接，但可以创建多个流，每个流代表了收发流媒体的一个通道。
握手完成
建立连接完成
创建流，开始播放
RTMP进一步学习
GB/T 28181 – 2016
本标准规定了公共安全视频监控联网系统(以下简称联网系统) 的互联结构, 传输、 交换、 控制的基本要求和安全性要求, 以及控制、 传输流程和协议接口等技术要求。
随着国内视频监控应用产业的迅猛发展，基于不同接入协议的视频监控前端设备及联网系统大量涌现，造成省部级及国家级层面的视频集中调阅和通过实时监控视频进行远程指挥调度等业务功能实现起来变得十分复杂。在该背景下 GB/T 28181 协议标准应运而生。
本标准主要定义SIP及其配套协议的流程等的传输规范。现如今大多数视频监控设备都支持该规范。
优秀项目学习：GB2818.Solution ， ZLMediaKit 等
WebRTC (Web Real-Time Communications, Web 实时通信)
WebRTC 协 议 由 W3C WEBRTC 和IETF RTCWEB工作组共 同 制 定 提 出， WebRTC 协议是面向连接的流媒体技术代表之一，实 现 了 基 于 网 页 的 视 频 会 议 通 信。
WebRTC 是一项实时通讯技术，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Peer）的连接，实现视频流和（或）音频流或者其他任意数据的传输。WebRTC包含的这些标准使用户在无需安装任何插件或者第三方的软件的情况下，创建点对点（Peer-to-Peer）的数据分享和电话会议成为可能。
2021年1月26日，W3C（万维网联盟）和 IETF （互联网工程任务组）同时宣布 WebRTC现发布为正式标准，将音视频通信带到 Web 上任何地方。
WebRTC 由用于 Web 实时通信的 JavaScript API 和一组通信协议构成，支持网络上的任何已连接设备成为 Web 上潜在的通信端点。WebRTC 已成为线上通信及协作服务的基石。所有Web 应用程序都可接入实时音视频通信系统。WebRTC 框架提供了构建块，Web 和应用程序开发人员可以从这些构建块无缝地将视频聊天添加到一系列应用程序，包括远程教育和远程医疗，娱乐和游戏，专业和工作场所协作。通过将基础标准化并作为免版税功能部署在 Web 浏览器以及其他设备和平台中，利用 WebRTC 建立安全的视听通信系统已成为一种内置功能，从而无需安装插件或下载单独的应用程序。
但目前WebRTC协议仍在不够成熟，技术难度较高实现较复杂。不过这次正式标准的发布，一定将极大地推进WebRTC在视频直播，流媒体传输领域的改革，相信不远的将来音视频通信领域将是WebRTC的天下。
WebRTC 标准文档：https://www.w3.org/TR/webrtc/
这个文档定义了一套WebIDL中的ECMAScript接口，使多媒体和一般的应用程序数据能够被发送到或者接收自其他实现了实时流协议的浏览器或设备。该规范和IETF RTCWEB开发的协议规范以及访问本地媒体设备的接口规范一同被开发。
WebRTC主要让浏览器具备三个作用。
获取音频和视频
进行音频和视频通信
进行任意数据的通信
WebRTC共分成三个API，分别对应上面三个作用。
MediaStream （又称getUserMedia）
RTCPeerConnection
RTCDataChannel
WebSocket
WebSocket 是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。
WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据（这是HTTP协议无法做到的）。在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。
在 WebSocket API 中，浏览器和服务器只需要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。
浏览器通过 JavaScript 向服务器发出建立 WebSocket 连接的请求，连接建立以后，客户端和服务器端就可以通过 TCP 连接直接交换数据。
当你获取 Web Socket 连接后，你可以通过 send() 方法来向服务器发送数据，并通过 onmessage 事件来接收服务器返回的数据。
WebSocket 协议本质上是一个基于 TCP 的协议。
为了建立一个 WebSocket 连接，客户端浏览器首先要向服务器发起一个 HTTP 请求，这个请求和通常的 HTTP 请求不同，包含了一些附加头信息，其中附加头信息"Upgrade: WebSocket"表明这是一个申请协议升级的 HTTP 请求，服务器端解析这些附加的头信息然后产生应答信息返回给客户端，客户端和服务器端的 WebSocket 连接就建立起来了，双方就可以通过这个连接通道自由的传递信息，并且这个连接会持续存在直到客户端或者服务器端的某一方主动的关闭连接。
WebSocket进一步学习
WebAssembly
Web页面可通过比较高效的WebAssembly技术进行解码渲染。
WebAssembly 是由主流浏览器厂商组成的 W3C 社区团体 制定的一个新的规范。
WebAssembly/wasm WebAssembly 或者 wasm 是一个可移植、体积小、加载快并且兼容 Web 的全新格式
WebAssembly是一种可以使用非JavaScript编程语言编写代码并且能在浏览器上运行的技术方案。
高效：WebAssembly 有一套完整的语义，实际上 wasm 是体积小且加载快的二进制格式， 其目标就是充分发挥硬件能力以达到原生执行效率 安全：WebAssembly 运行在一个沙箱化的执行环境中，甚至可以在现有的 JavaScript 虚拟机中实现。在web环境中，WebAssembly将会严格遵守同源策略以及浏览器安全策略。
开放：WebAssembly 设计了一个非常规整的文本格式用来、调试、测试、实验、优化、学习、教学或者编写程序。可以以这种文本格式在web页面上查看wasm模块的源码。 标准：WebAssembly 在 web 中被设计成无版本、特性可测试、向后兼容的。WebAssembly 可以被 JavaScript 调用，进入 JavaScript 上下文，也可以像 Web API 一样调用浏览器的功能。当然，WebAssembly 不仅可以运行在浏览器上，也可以运行在非web环境下。
WebAssembly进一步学习
流媒体相关著名项目
FFmpeg
VLC
live555
EasyDarwin
NGINX-RTMP
ZLMediaKit
在过去的10多年时间里（从2004年到2018年），网页视频播放一直是Flash技术的天下，我们所熟悉的众多视频网站和新闻门户网站一直都在使用Flash技术来播放网页视频。这里的主要原因是IE浏览器的高比例占有量和Flash插件在客户端的普及，还有就是主要流媒体服务器产品对rtmp协议和flv视频格式的广泛支持，这是这一个时期的视频生态系统。
随着IE浏览器的衰落和新型浏览器（Chrome,Firefox,Safari等）的崛起，Flash视频播放进入了被淘汰的进程，HTML5 Video正在成为视频播放的主流技术。Youtube从2010年就开始尝试使用没有Flash的视频播放技术，到2018年前后完全实现了去Flash播放，国内的视频网站也在积极地进行这去flash的技术改进，相信也很快不再使用Flash播放器。Chrome浏览器在2020年彻底抛弃Flash技术，几大科技巨头包括Flash的母公司Adobe联合宣布将放弃Flash。这无疑会大大促进众多整个互联网行业的去Flash进程。
HTML5 Video与MSE（Media Source Extensions ）一起能够提供更加强大的视频播放和扩展应用（如双向视频）等。
要实现去Flash应当在播出时摒弃rtmp协议，采用HLS、HTTP-FLV、WebRTC、WebSocket来传输直播视频流，客户端使用MSE扩展实现数据接收和视频播放
HTML5的Video控件标签支持HLS协议播放，经测试确实支持m3u8的播放。
HTML5视频解码器没有指定，由浏览器开发者决定。当前各主流浏览器video元素主要支持三种视频格式ogg, mp4, webm。MPEG4 = 带有 H.264 视频编码和 AAC 音频编码的 MPEG 4 文件