1、前置知识
1.1 WebRTC前世今生
在线教育、在线会议、在线面试、在线社交、在线医疗、金融证券在线开户、智能家居都已经非常普及了，将常见的线下场景转至线上，而WebRTC就是实现这些场景的主要手段；
WebRTC的使命是使丰富、高质量的RTC应用程序可以为浏览器、移动平台和loT设备开发，并允许所有人通过一组通用的协议进行通信
1.2 WebRTC解决的问题(主要相对于RTC)
-
互联网网络复杂
-
不同的NAT、防火墙对媒体P2P的建立带来了很大的挑战；而WebRTC为浏览器提供了端到端的直接通信；
-
WebRTC技术包含了STUN、TURN、ICE、RTP-over-TCP的关键NAT和防火墙穿透技术，并支持代理
-
WebRTC里面有P2P打洞的开源项目libjingle、支持STUN、TURN等协议
-
-
延时敏感
-
早期的RTC技术中，由于TCP技术的缺陷，只能需要UDP传输，需要开发者解决重传、乱序等问题
-
WebRTC提供了NACK、PEC技术，不再需要通过服务器进行路由，减少了延迟和宽带消耗
-
直接通信可以提高数据传输和文件共享的速度
-
-
流畅性
-
网络中存在不稳定性，例如网络的抖动等问题，此时就需要一套自适应的算法来应对网络拥塞、平滑发送等问题
-
WebRTC中提供了TCC+SVC+PACER+JitterBuffer等技术解决这些问题
-
-
语音清晰
-
由于终端设备和环境的问题，会有噪声、回声等干扰，WebRTC提供了3A算法+NetEQ，让实时环境中的声音处理以及互动体验得到了极大的提升
-
1.3 WebRTC的安全问题
所有WebRTC媒体数据都必须经过加密
WebRTC不是一个插件，也不依赖于任何插件，因此所有应用都可以在浏览器的沙箱中运行，并不用再额外创建新进程，正因为如此，WebRTC有效的阻止了恶意软件进入用户系统
-
WebRTC的媒体处理
-
对于WebRTC的媒体处理上，已经使用了DTLS-SRTP技术，使用DTLS类似的SSL证书方式来协商加解密密钥，使用SRTP实现对于媒体(音视频)数据加密和完整性保护，实现媒体传输的安全保护
-
-
信令协商
-
也需要采取TLS/DTLS进行信令数据传输的保护，当然是取决于各厂商的具体实现方式(如HTTPS、SIPS)
-
针对信令服务器，其信令通信都是对互联网开放的，其受攻击的基本都是DOS/DDOS攻击(如TCP半链接攻击，HTTP Flood攻击)，目的就是破坏性的让信令服务器无法提供服务
-
信令协议本身就有挺多的缺陷的，针对单用户的攻击，SIP这种通用的RTC协商信令协议，有很多方法可以使得攻击者将合法用户禁掉
-
-
WebRTC潜在的危险
-
针对信令服务器
-
进行针对用户设备的DOS暴力破解攻击
-
攻击者快速频繁且反复地发送注册请求
-
伪造报文将用户去注册
-
伪造结束报文非法结束用户的通话
-
-
针对媒体服务器/媒体终端
-
由于媒体地址和媒体端口都是通过SDP协商的，SDP消息如果被恶意篡改，就会导致媒体处理者的媒体报文自我循环，从而造成媒体处理方无法提供服务
-
终端与媒体服务器之间是加密的(如SRTP加密)，但在媒体服务器中解密的处理会存在媒体明文暴露点，也就存在了安全风险
-
-
其他风险
-
交换公钥时存在被黑客截取到的风险
-
WebRTC利用DTLS协议就可以有效的解决各端之间交换公钥时被窃取的问题
-
进行DTLS协商，交换公钥证书以及协商密码相关信息，同时通过fingerprint对证书进行验证，确认其没有在传输中被篡改
-
可以通过「指纹」的方式对证书进行加解密操作，实现数据的校验和验证
-
「指纹」是指：用来判断公钥证书在传递过程中有没有被篡改，进行证书完整性判断，通过哈希算法对证书内容进行计算从而获取到指纹
-
在获取到「指纹」后，在发送前需要进行指纹加密，生成数字签名，然后和公钥一起发送给对等端，对等端通过该公钥和对应的哈希算法进行解密，然后再对比从而判断证书是否正确
-
-
-
但还有一个问题是不能确定对方是不是冒充的
-
解决该问题可以利用STUN协议进行身份认证，从而拦截黑客冒充的身份进行交互窃取信息
-
-
安全描述的作用
-
进行网络连通性检测时，对用户身份进行验证
-
收发数据时，对用户身份的认证，以免受到对方的攻击
-
-
-
-
-
WebRTC使用两种标准的加密协议
-
加密的首选方法是在DTLS(数据报传输层安全性)捂手中使用PFS密码来安全的交换关键数据
-
对于音视频传输，可以使用密钥数据生成AES(高级加密标准)密钥，然后由SRTP(安全实时传输协议)使用AES密钥对媒体进行加密和解密
-
-
数据报传输层安全性(DTLS)
-
浏览器内置的标准化协议。是基于传输层协议(TLP)的数据流加密
-
由于DTLS使用用户数据协议(UDP)，因此保留了传输的语义
-
他是安全套接字层(SSL)的拓展，任何SSL协议均可用于保护WebRTC数据，从而允许端到端加密
-
-
安全实时传输协议(SRTP)
-
用于媒体流加密
-
是对实时传输协议(RTP)的拓展，该协议没有任何内置的安全性机制
-
为实时传输协议(RTP)提供加密、完整性保证和消息身份验证
-
但是不会对表头进行加密，只会对RTP数据包加密
-
-
-
可以说如果 WebRTC 直接拿过来商用的话，几乎是不太可能的，当下普遍的解决方案是自研，根据自身的业务场景进行二次定制开发，或者更简单一点使用第三方 SDK。Agora WebSDK 是基于 WebRTC 封装的API集合，极致简单，对开发者更加友好，能十行之内完成一个简单的 demo 并上线；
-
媒体协商拓展
-
基本步骤
-
呼叫端 Amy 创建 Offer(createOffer)并将 offer 消息（内容是呼叫端 Amy 的 SDP 信息）通过信令服务器传送给接收端 Bob,同时调用 setLocalDesccription 将含有本地 SDP 信息的 Offer 保存起来
-
接收端 Bob 收到对端的 Offer 信息后调用 setRemoteDesccription 方法将含有对端 SDP 信息的 Offer 保存起来，并创建 Answer(createAnswer)并将 Answer 消息（内容是接收端 Bob 的 SDP 信息）通过信令服务器传送给呼叫端 Amy
-
-
呼叫端 Amy 收到对端的 Answer 信息后调用 setRemoteDesccription 方法将含有对端 SDP 信息的 Answer 保存起来
-
-
-
完成P2P通信过程的媒体协商之后，通过信令服务器将各自的网络信息(Candidate)发送给对等端之后就可以打通P2P通信的网络通道，并通过监听onaddstream事件拿到对方的视频流进而完成整个过程的视频通话
-
2、即时通信(IM)和实时通信(RTC)
2.1 简介
即时通信(IM)和实时通信(声网Agora.io)都是一套网络通信系统，其本质都是对信息进行转发，其最大的特点就是对信息传递的时间规定
-
时通信(IM：Instant Messaging)：是一个实时通信系统，终端服务，允许两人或多人使用网络实时传输的文字消息、文件、语音与视频交流；
-
本质是客户端与客户端进行消息的实时传递，技术基础就是基于Socket连接的实时数据读写
-
按使用用途分为：企业即时通信和网站即时通信
-
根据装载对象又可以分为手机即时通信和PC即时通信
-
主要的产品：钉钉、微信、QQ等以IM为核心的产品，其他的如在线游戏、社交应用 - 可以说IM系统是任何一个带有社交属性的应用需要具备的基础功能
-
最核心的部分是：消息系统
-
消息系统中最核心的功能是消息的同步、存储和检索
-
消息的同步
-
将消息完整的、快速的从发送方传递到接收方就是消息的同步
-
最重要的衡量标准就是消息传递的实时性、完整性以及可以支撑的消息规模
-
功能上来说：一般至少支持在线和离线推送，高级的IM系统还支持「多端同步」
-
-
消息的存储
-
即消息的持久化保存
-
传统的消息系统智能支持消息在接收端的本地存储，数据基本不具备可靠性
-
现代消息系统是支持消息的服务端的在线存储，功能上实现的就是「消息漫游」，「消息漫游」的好处就是可以实现账号在任一端登录都可以查看所有的历史消息
-
-
消息的检索
-
消息一般是文本格式呈现，所以一般是支持检索的功能，不管是传统的本地存储还是现在的在线存储检索
-
-
-
2.1.1 场景与需求点分析
-
即时通信
-
包括常见的文字聊天、语音消息发送、文件传输、音视频播放等
-
主要要求可靠，在意送达率
-
-
实时通信
-
场景包括语音、视频电话会议、网络电话等
-
主要要求低延时和接通率
-
2.2 相关技术、协议和解决方案
-
即时通信
-
XMPP，MQTT
-
-
实时通信
-
WebRTC、Tokbox
-
-
即时通信
-
消息发送和确认、「消息接入端、服务端消息逻辑处理、服务端消息缓存和存储、转发、服务端用户状态管理、心跳机制、消息发送端」、消息接受和确认
-
为了保证连接的可靠性、最常用的是TCP协议或者类TCP连接协议
-
造成的后果就是为了追求连接的可靠性、而造成延迟的不可控性
-
TCP封装了消息的重传机制，在丢包的情况下，延时问题比较严重，甚至在超过30%丢包的情况下延时会达到几十分钟，甚至容易断开连接，而UDP还可以传输数据，TCP就无法进行实时通信了
-
-
-
实时通信
-
技术环节：采集、前处理、编码、「服务端接入、转发、服务端接入」解码、播放和渲染
-
声网Agora.io采用UDP作为基础传输协议，在设计低延时的实时通信服务时，UDP表现要比TCP好的多
-
【学习地址】：FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发
【文章福利】：免费领取更多音视频学习资料包、大厂面试题、技术视频和学习路线图，资料包括（C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等等）有需要的可以点击1079654574加群领取哦~
3、WebRTC基本概念
-
RTP协议
-
实时互动直播系统采用UDP进行传输，但一般在传输数据流的时候，并不直接将音视频数据交给UDP传输，而是先给音视频数据加个RTP头，然后再交给UDP进行传输
-
-
WebRTC原生支持Web浏览器进行实时通信
-
实时通信数据包括语音、音视频、和任意其他类型的数据，无需下载任何插件
-
可以通过WebRTC传输任意数据，这个过程在WebRTC中的数据通道(data channel)中进行，当你需要在浏览器时间传输信息不通过任何服务器时(还是需要一个TURN服务器转发消息)就可以使用数据通道
-
数据通道可以配置成可靠或非可靠、有序或无序传输消息
-
-
WebRTC是使用JavaScript API的媒体引擎
-
WebRTC只是一个媒体引擎，其上层是JavaScript API
-
-
WebRTC P2P发送数据原理
-
P2P可以实现直接在浏览器之间发送数据
-
需要先通过信令服务器交换彼此的数据，目的是得到对方的网络信息
-
信令服务器用于交换三种类型的信息
-
会话控制消息：初始化/关闭，各种业务逻辑消息以及错误报告
-
网络消息：外部可以识别的IP地址和端口(ICE消息)
-
为了连接媒体通道，实现了ICE(有时需要通过TURN转发消息)
-
ICE(Interactive Connectivity Establishment：交互式连接建立)，可以整合各种NAT穿越的技术如STUN、TURN(Traversal Using Relay NAT 中继NAT实现的穿透)
-
STUN服务器位于公网上，其做的事情就是获取自己的IP、Port和NAT信息，然后通过信令服务器交换这些信息，最后让两个客户端根据自己得到的IP、Port和NAT信息进行对应的穿透
-
-
ICE会先使用STUN(NAT会话穿越应用程序-获取面向公众的IP地址)，尝试建立一个基于UDP的连接，如果失败了就会去用TCP，还是失败时就会使用一个中继的TURN(中继穿透NAT)服务器
-
ICE会尝试找到最好的路径来让用户端建立连接，或尝试所有可能的选项，然后选取最合适的
-
-
媒体能力：客户端能控制的编解码器、分辨率、以及想和谁通信(SDP信息)
-
-
信令一旦发送成功，就可以直接在两个浏览器之间发送消息，Web服务器不会获取到这些信息
-
-
WebRTC需要通过网络进行两种类型的交互
-
信令传输
-
发生在HTTPS连接或者WebSocket上，通过JS代码实现
-
在信令中需要做的就是：用户找到彼此并开启对话
-
目前业界中使用较多的是WebSocket+JSON/SDP的方案，其中WebSocket用来提供信令传输通道，JSON/SDP用来封装信令的具体内容
-
WebSocket建立在TCP之上，提供了长连接的能力，解决了HTTP仅支持半双工，header信息冗余等的低效问题
-
SDP(Session Description Protocol)是一个会话描述协议，用来封装流媒体能力协商的信令内容，两个WebRTC代理会将建立连接所需的所有状态通过此协议来分享
-
协议是个标准/约定，而协议栈是协议的实现，可以理解为代码，函数库、供上层应用调用
-
-
-
传输媒体
-
需要用到媒体渠道(Media channels)、使用SRTP(用于语音和视频)和SCTP(用于数据通道)实现
-
SCTP 与 SRTP被用于为多路复用、提供拥塞和流控制，以及部分在UDP之上提供部分可靠的传递和其他附加服务
-
DTLS用于保护对端的数据传输
-
-
与信令不同，媒体选择了一条不同的路线在网络上传输，且表现也不尽相同
-
-
-
WebRTC处理媒体和视频
-
WebRTC使用VoIP技术处理媒体，并将其通过网络发送，这一切都在SRTP(RTP的安全、加密版本)之上进行
-
WebRTC的音频和视频使用编解码器中进行工作，编解码器用于压缩和解压缩视频和音频数据的已知算法
-
-
WebRTC工作原理简述
-
可以实时发送音频、视频或者任意的数据
-
需要通过NAT穿越机制使得浏览器之间相互访问
-
有时，P2P必须经过中继服务器(TURN)
-
使用WebRTC需要考虑到信令和媒体，彼此分离
-
当然也可以通过媒体服务器实现P2P的相关功能，而非必须使用P2P
-
媒体服务器：当多人进行音视频通话时，常规的对等P2P通信就显得有点吃力，这时就需要通过媒体服务器来减少客户端需要接收或发送的数量，做中继作用
-
-
4、相关工作原理
4.1 H.265在Web端的硬解支持
在旧版的Web端浏览器是不支持H.265的，但是其需求是一直存在，另一种解决方式是通过软解的方式进行播放，但是软解的方式对性能的损耗是比较严重的，因此一般都不支持H.265格式的编码；
在22年9月，Chrome发布了M106版本，默认开启H.265硬解，使得实时预览支持H.265硬解具备可行性； 但是WebRTC本身支持的视频编码格式仅包括VP8、VP9、H.264、AV1，并不支持H.265，短期内也没有计划去支持H.265，因此需要自研实现WebRTC变相支持H.265编码，具体方式有
-
实现WebRTC对H.265的支持方式
-
通过
DataChannel
实现
-
DataChannel是专门用来传输除音视频数据之外的任何数据的通道(当然也是支持音视频数据传输的)，本质上就是一条socket通道 -
DataChannel
使用的协议是SCTP(stream control transport Protocol)是一种与TCP、UDP同级的传输协议，可以直接在IP协议之上运行；
-
在WebRTC中，SCTP通过安全的DTLS隧道进行隧道传输，该隧道本身在UDP之上运行，同时支持流控、拥塞控制、按消息传输、传输模式可配置性等特性，但需要注意的是单次发送消息不能超过maxMessageSize(只读，默认65535字节)
-
DataChannel可以配置在不同模式下，一种是使用重传机制的可靠传输模式(默认模式)，可以确保数据成功传输到对等端；另一种是不可靠的传输模式，该模式下可以通过设置maxRetransmits指定最大重传次数，或通过设置maxPacketLife设置传输间隔时间实现；两种配置是互斥的，不可同时设置，当同时为null时使用可靠传输模式，有一个值不为null时为不可靠传输模式
-
-
数据通道支持String类型或ArrayBuffer类型，即二进制流或者字符串数据
-
-
4.2 信令服务器工作原理
为了高效的利用CPU，信令服务器采用了事件驱动的工作模式；即当没有网络事件(网络请求)时，空闲出来的CPU可以处理其他任务；当有网络事件时，可以及时响应网络事件
-
事件驱动
-
事件驱动是设计/开发网络服务器最经典、最流行的模型；
-
事件驱动模式可以由不同的API来实现，如select、poll、epoll等，这些API各有各的优势，对于peerconnection_server而言是通过select API实现的
-
5、直播协议和视频监控方案
5.1 WebRTC(RTP)、FLV(RTMP)和HLS协议 → 不同类型的视频流协议
5.1.1 视频流协议
视频流协议是一组规则，用于管理视频数据如何从一个点传输到另一个点；有助于确保数据完好无损并以正确的顺序到达
-
流式传输协议可以用于通过Internet或本地网络上的设备之间流式传输视频
-
较流行的流媒体协议有
-
HTTP实时流式传输(HLS：HTTP Live Streaming)
-
原理就是服务端将整个流切分成一片片小的媒体流片段，客户端通过下载一个包含源数据的extend M3U(m3u8)playlist文件用于寻找可用的媒体流，随后开始下载格式为MPEG-TS的媒体片段
-
其限制的编码格式是H264+AAC编码
-
PC端浏览器大多只能解析H264/HEVC播放视频，wasm可以解析H265，因此在进行音视频解析播放时需要考虑降级的方案
-
Chrome已经实现对H.265/HEVC的硬件支持，对HEVC硬件支持的代码已经合进了Chromium的仓库，这将意味着只要是使用Chromium内核的浏览器本质上也可以支持H.265/HEVC硬解
-
HEVC(High Efficiency Video Coding)高效视频编码，也称H.265和MPEG-H part 2，是视频压缩标准，与AVC比较，HEVC在相同视频质量的前提下提供大约两倍的数据压缩比，或者以相同的比特率显示着提高视频质量，支持高达8192×4320的分辨率，包括8K UHD
-
-
如：将WebRTC作为直播的首选方案，保证体验的优先；以CDN直播作为降级方案，确保用户能看
-
-
是由Apple开发的一种协议，它使用分段文件格式通过HTTP传输视频内容
-
例如将固定长度的FLV进行切片转成ts与m3u8，但因为切片时间、网络传输时间、等待固定长度的FLV格式的文件就需要较大的时间
-
m3u8是一种基于HLS文件视频的文本格式，主要是存放整个视频的基本信息和分片(Segment)组成
-
-
一级m3u8文件记录了不同比特率视频流的二级index文件，客户端可以根据自己相关网络设备状况决定播放哪一路视频流，同样的也可以在网络变化时平滑的切换到匹配的视频流
-
HLS是把流分成一个个小的基于HTTP的文件来下载，每次只下载一部分
-
-
-
HLS协议由三部分组成：HTTP(传输协议)、m3u8(索引文件)、TS(音视频媒体信息)
-
每一个.m3u8文件分别对应若干个TS文件，基于HTTP来下载，每次只卸载一小部分；
-
.m3u8文件只是存放了一些TS文件的配置信息和相关路径，当视频播放时，.m3u8是动态变化的，在通过解析器(如hls.js)解析这些文件，并找到对应的TS文件来播放，因此一般为了加快速度，.m3u8文件放在Web服务器上，TS文件放在CDN上
-
-
HLS使用的是HTTP的短连接，传输方式上本就不存在优势，对网络要求也较高
-
与其他协议不同点在于：直播客户端获取到的并不是一个完整的数据流，该协议在服务端将直播流数据流式存储为连续的、很短时长的媒体文件(MPEG-TS格式)，客户端则不断地下载并播放这些小文件
-
可以理解为HLS是以点播的技术方式来实现直播，数据通过HTTP传输
-
-
其特点是：基于HTTP短连接，延迟一般在10~15S,可与更广泛的设备兼容、但具有更高的延迟
-
在目前ed视频流媒体中，低延迟HLS流媒体是为数不多的实现低延迟、自适应码率流媒体直播的方式之一
-
优势
-
穿透防火墙：基于HTTP/80传输，有效避免了防火墙拦截
-
高性能：通过HTTP传输，支持网络分发，CDN支持良好，且自带多码率自适应
-
-
劣势
-
实时性差，延迟高，基本延迟在10s+之上
-
文件碎片：ts切片较小，会导致海量的小文件，需要直播流分片拉取，客户端也需要频繁的进行HTTP请求，对存储和缓存都有一定的挑战
-
通过video标签进行HLS播放，无法很好的在业务层进行定制化操作以及数据监控
-
HTML5直接支持(video)，适合APP直播，PC端只有Safari、Edge支持
-
由于HLS是由Apple提出的，所以在iOS手机或电脑上，可以直接用Safari浏览器的video标签来播放m3u8格式的视频文件，而其他浏览器则需要借助hls.js来兼容m3u8
var video = document.getElementById("video"); if (Hls.isSupported()) { var hls = new Hls(); hls.loadSource( "https://yunqivedio.alicdn.com/2017yq/v2/0x0/96d79d3f5400514a6883869399708e11/96d79d3f5400514a6883869399708e11.m3u8" ); hls.attachMedia(video); hls.on(Hls.Events.MANIFEST_PARSED, function () { video.play(); }); } else if (video.canPlayType("application/vnd.apple.mpegurl")) { video.src = "https://video-dev.github.io/streams/x36xhzz/x36xhzz.m3u8"; video.addEventListener("loadedmetadata", function () { video.play(); }); } 复制代码 -
-
-
-
-
实时消息协议(RTMP: Real Time Messaging Protocol)
-
由Adobe公司开发，底层是基于TCP协议的
-
TCP的ACK机制，发送方会等接收方确认才继续发送下一个数据包
-
特点
-
TCP长连接，默认端口号是1935，协议中的基本数据单元为消息(message)，传输的过程中消息会被拆分为更小的消息块(chunk)单元，最后将分割后的消息块通过TCP协议传输，接收端再反解接收的消息块恢复成流媒体数据
-
延迟在3~5s
-
RTMP协议是专门为流媒体开发的协议，对底层的优化比其他协议更加优秀，基本上所有的编码器(摄像头之类)的都支持RTMP输出
-
RTMP支持长时间播放，延迟也相对较低，一般在1~3s之间，一般的视频会议、互动式直播完全是够用的
-
兼容性方面必须支持Flash
-
缺点是
-
基于TCP传输，非公共端口，可能会被防火墙阻拦
-
RTMP为Adobe私有协议，很多设备无法播放，特别是在iOS端，需要使用第三方解码器才能播放
-
-
-
-
实时流协议(RTSP: Real Time Streaming Protocol)
-
实时流媒体会话协议，是用来控制声音或影视的多媒体串流协议；
-
提供了一个可拓展框架，使得实时数据的受控与点播成为了可能
-
是一种双向的实时数据传输协议，允许客户端向服务器端发送请求，如生成回放、快进、待退等操作
-
内部可基于RTP来传输数据，也可以选择TCP、UDP、组播UDP等通道来发送数据，具有较好的拓展性
-
-
WebRTC
-
是一种开源协议，允许在浏览器之间双向传输音频、视频数据和文本
-
-
安全可靠传输(SRT)
-
HTTP FLV
-
基于HTTP流式IO传输FLV，将流媒体数据封装成FLV格式，然后通过HTTP传输给客户端
-
HTTP-FLV依靠MIME(Multipurpose Internet Mail Extensions)的特性，根据协议中的Content-Type来选择对应的程序去处理相应的内容，从而使得流媒体可以通过HTTP传输，例如通过配置MIME类型为
flv-application/octet-stream来达到这个目的，但MIME只是一个描述，并非非得输入上述示例 -
MIME类型就是设定某种扩 展名的文件用一种应用程序来打开的方式类型，当该扩展名文件被访问的时候，浏览器会自动使用指定应用程序来打开。多用于指定一些客户端自定义的文件名，以 及一些媒体文件打开方式
-
是将RTMP封装在HTTP协议之上的用于传输FLV格式的协议，其传输的http_flv是一个文件大小无上限的HTTP流的文件；
-
不需要服务端进行直播流的切片处理，因此具有低延迟的特点，平均延迟只有1~2s
-
HTTP FLV还具有一定的避免防火墙干扰(基于HTTP/80传输)，兼容302跳转灵活调度/负载均衡，支持HTTPS通道加密等优势
-
局限性：HTTP FLV的支持需要依赖于MSE(Media Source Extensions)API和fetch+stream API，而iOS浏览器不支持MSE API，因此FLV流无法直接在iOS端播放
-
在支持浏览器的协议里，延迟的排序是：RTMP ≈ HTTP-FLV ≈ WebSocket-FLV < HLS
-
在支持浏览器的协议里，性能的排序是：RTMP > HTTP-FLV ≈ WebSocket-FLV > HLS
-
-
-
兼容方案
-
PC端
-
优先使用HTTP-FLV，因为它延迟小，性能不差，可以流畅播放1080P
-
尝试使用flv.js进行流媒体播放
-
不支持flv.js就使用Flash播放器播RTMP流，兼容性好但是现在大多都被禁用了
-
使用HLS，但是PC端只有Safari支持HLS
-
-
移动端
-
优先使用HTTP-FLV，因为它延迟小，性能不差，可以流畅播放1080P
-
尝试使用flv.js进行流媒体播放
-
使用HLS，但是PC端只有Safari支持HLS
-
H5端不支持Flash
-
-
业务流控
-
通过心跳上报，统计不同类型的直播的平台的实时并发流量
-
根据在线并发量，相应新进入房间的学生应该切到哪种直播方式
-
-
监控日志
-
监控并实时上报各项指标并告警
-
-
-
拓展
-
MSE(Media Source Extension：媒体流拓展)
-
是为了让H5支持流媒体操作(用户层面就是播放)的一个标准
-
原视频文件通过编码来压缩文件大小，再通过封装将压缩视频、音频、字幕组合到一个容器内，可以将
<video>标签看作是拥有解封装、解码功能的浏览器自带的播放器； -
仅依赖
<video>标签是无法识别的TS流文件的，因此就引入了MSE拓展来帮助浏览器识别并处理TS文件，将其变回原来的可识别的媒体容器格式以使得<video>可以正常播放该视频流
-
-
现阶段支持移动端播放flv格式的js SDK主要有以下几种
-
flv.js的工作原理：通过MSE将flv流转码成fmp4给video进行播放，其本质还是依赖于MSE，所以无法支持iOS
-
由于依赖于MSE，所以目前IOS和Android4.4.4(2013年发布4.4系统，现在最新的是6.0)以下的浏览器不支持
-
FLV是Adobe公司推出的另一种视频格式，是一种在网络上传输的流媒体数据存储容器格式，其格式相对简单，不需要很大的媒体头部信息
-
编码格式：H264(视频)+AAC/MP3(音频)
-
使用HTTP的流式IO(fetch或stream)或WebSocket协议流式的传输媒体内容
-
延迟大多在2~5s的延迟，首帧比RTMP更快
-
优势：
-
由于浏览器对video标签采用了硬件加速，性能很好，支持高清
-
同时支持直播和录播
-
不用依赖于Flash
-
-
原理
-
在获取到FLV格式的音视频数据后通过原生的JS去解码转换FLV数据，再通过MSE API喂给原生video标签(原生video标签仅支持mp4/webm格式，不支持FLV)
-
FLV容器格式相比于MP4格式更简单，解析起来更方便
-
-
拓展 → mp4分类
-
nMP4：嵌套的Boxes，需要加载整个文件进行播放
-
fMP4：是由一系列的片段组成，不需要加载整个文件进行播放
-
-
-
NodePlayer.js工作原理：通过ASM.js软解码H.264+AAC流，利用WebGL视频渲染，WebAudio音频播放来实现移动端flv直播流的播放；
-
WXInlinePlayer与ffmpeg-player工作原理基本类似：
-
数据流获取：从云端的HTTP-FLV流媒体获取直播流数据
-
WASM解码层：
-
利用WebWorker开启子线程
-
通过获取视频流的metaData信息后，对视频进行解封装
-
将视频流转换为YUV，音频流格式转换为PCM
-
最后将转换好的数据回调给渲染层
-
-
渲染层：
-
将获取到的视频数据和音频数据存入渲染缓存池中
-
WebGL在Canvas上绘制视频画面
-
WebGL渲染器强依赖于手机硬件性能，因此对低端手机会出现降级情况(720分辨率的流降级到540P，或者将FLV降级为HLS)
-
-
Web Audio API播放音频数据
-
-
解码库依赖方面
-
ffmpeg-player是在Web侧复用了FFmpeg中的H.265解码模块实现前端解码，整套解码器在依赖h264、acc、flv的同时还依赖了HEVC，因此ffmpeg-player同时支持了H.264和H.265两种格式的视频流，因此输出的wasm文件体积较大，约1.3M
-
WXInlinePlayer提供了三种构建方案，开发者根据需求来选择不同的解码器
-
baseline(不使用OpenH264)
-
all(在baseline的基础上支持OpenH264)
-
h265(基于OpenH265)
-
-
-
-
总体开发思路
-
通过wasm来编解码器从而实现现在前端进行FLV格式的解码，输出YUV视频数据以及PCM音频数据，利用webGL渲染YUV和webAudio API播放PCM音频最终实现FLV播放
-
K歌解析FLV的流程图解
-
-
-
5.1.2 比较WebRTC和HLS协议
-
交付方法比较
-
WebRTC视频流采用双向点对点连接进行实时通信
-
可以实现客户端之间的视频流数据直接相互发送 - 几乎无延迟
-
-
WebRTC是基于UDP的
-
HLS使用客户端-服务器模型
-
需要使用服务器将视频流发送给客户端 - 产生延迟
-
-
HLS是使用TCP(传输控制协议)
-
总结：WebRTC可以提供更低的延迟
-
-
视频质量比较
-
WebRTC采用点对点的流式传输，允许客户端之间直接进行通信
-
WebRTC可以提供更高的视频流数据
-
-
可拓展性比较
-
WebRTC采用点对点协议，意味着可以拓展到大量用户而不会降低质量
-
拓展性WebRTC较好
-
-
安全性比较
-
WebRTC采用DTLS进行加密
-
HLS采用TLS
-
-
灵活性和兼容性比较
-
兼容性都较好
-
移动端IOS和Android都支持HLS协议，做好视频采集、视频推流服务之后，就可以直接在H5页面通过video标签进行播放直播流
-
<video<source id="source" src="http://xxxx/video.m3u8" type="application/x-mpegURL" /></video>5.2 监控方案
安防类项目中都需要有视频监控方案的需求，视频监控客户端主要是Native应用的形式，在Web端需要利用NPAPI、ActiveX之类的插件技术实现
5.2.1 B/S架构实时视频监控解决方案
-
音视频编码
-
常见的音频编码算法包括：MP3、Vorbis、AAC
-
常见的视频编码算法包括：H.264、HEVC、VP8、VP9
-
-
音视频编解码格式
-
视频：AVI、MOV、MPEG/MPG/DAT、Real Media、QuickTime、ASF、H264/X264/AVC、H.263、MPEG-1、MPEG-2、MPEG-4、Sorensen Spark、VC-1、JPEG、RV、DivX、On2 TrueMotion VP6
-
音频：PCM、WAV、OGG、APE、AAC、MP3、Vorbis、Opus...
-
-
video和Audio支持的格式
-
video：MP4、webm、ogv
-
Audio：MP3、wav、ogg
-
视频的编解码方式取决于Codec(数字信号编解码器，可以对音视频进行压缩CO和解压缩DEC，该技术可以有效减少数字存储占用的空间，在计算机中可以节省CPU的资源，提高系统的运行效率)，如MP4根据编解码的不同分为nMP4、fMP4
-