WebRTC → WebRTC与直播相关原理

1、前置知识

1.1 前世今生

在线教育、在线会议、在线面试、在线社交、在线医疗、金融证券在线开户、智能家居都已经非常普及了，将常见的线下场景转至线上，而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对证书进行验证，确认其没有在传输中被篡改

        • 可以通过「指纹」的方式对证书进行加解密操作，实现数据的校验和验证

          • 「指纹」是指：用来判断公钥证书在传递过程中有没有被篡改，进行证书完整性判断，通过哈希算法对证书内容进行计算从而获取到指纹

          • 在获取到「指纹」后，在发送前需要进行指纹加密，生成数字签名，然后和公钥一起发送给对等端，对等端通过该公钥和对应的哈希算法进行解密，然后再对比从而判断证书是否正确

        • WebRTC安全机制

      • 但还有一个问题是不能确定对方是不是冒充的

        • 解决该问题可以利用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系统还支持「多端同步」

    • 消息的存储

      • 即消息的持久化保存

      • 传统的消息系统智能支持消息在接收端的本地存储，数据基本不具备可靠性

      • 现代消息系统是支持消息的服务端的在线存储，功能上实现的就是「消息漫游」，「消息漫游」的好处就是可以实现账号在任一端登录都可以查看所有的历史消息

    • 消息的检索

      • 消息一般是文本格式呈现，所以一般是支持检索的功能，不管是传统的本地存储还是现在的在线存储检索

  • 现代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通信就显得有点吃力，这时就需要通过媒体服务器来减少客户端需要接收或发送的数量，做中继作用

    • WebRTC 媒体管理 

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

6、推荐文献

声网-音视频

全民K歌推流直播Web实践

H5直播调研

原文链接：WebRTC → WebRTC与直播相关原理 - 掘金