大家好，又见面了，我是你们的朋友全栈君。
|
常见的可用于 HTML5 的直播技术共有3种协议：HLS、WebSocket与WebRTC。本文将对基于这3种协议的HTML5直播技术实现做下基础的介绍。
一. HLS
优点：CDN支持比较好
缺点：延时较高，无法进行互动直播
HLS（全称HTTP Live Streaming）是一个由苹果公司提出的基于HTTP的流媒体网络传输协议，是苹果公司QuickTime X和iPhone软件系统的一部分。它的工作原理是把整个流分成一个个小的基于HTTP的文件，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U (m3u8)playlist文件，用于寻找可用的媒体流。
用HLS协议实现直播的延时比较高，是因为每一小段的视频文件都需要延迟时间比如文件列表里面包含5个TS文件，每个TS文件包含5秒视频，那么整体的延迟就是25秒。
当然也可以缩短列表的长度和单个TS文件的大小来降低延迟，甚至可以缩减列表长度为1，TS视频时长为1s。但是这样设置无疑会增加请求次数，服务器压力自然也会增大，而且当网速慢时这样的设置会造成更多的缓冲。苹果官方推荐的TS时长是10s，这样就会大约有30s的延迟。
二. WebSocket+MSE 优点：实时性比较好，可以用于互动直播，前端可操作性更大 缺点：技术较新，一些旧浏览器不支持 1. WebSocket 通常的Web应用都是围绕着HTTP的请求/响应模式而构建的。所有的HTTP通信都是通过客户端来控制的，都是由客户端向服务器发出一个请求，服务器接收和处理完毕后再返回结果给客户端，客户端再将数据展现出来。这种模式不能满足实时应用的需求，于是出现了SSE，Comet等“服务器推”的长连接技术. WebSocket是直接基于TCP连接之上的通信协议，可以在单个TCP连接上进行全双工的通信。WebSocket在2011年被IETF定为标准RFC 6455，并被RFC7936所补充规范，WebSocketAPI被W3C定为标准。 WebSocket是独立的创建在TCP上的协议，HTTP协议中的那些概念都不复存在，和HTTP的唯一关联是使用HTTP协议的101状态码进行协议切换，使用的TCP端口是 80，可以用于绕过大多数防火墙的限制。 2. MSE MSE（全称：Media Source Extensions）是一个主流浏览器支持的新的Web API。MSE是一个W3C标准，允许Java动态的构建和 的媒体流。它定义了对象，允许Java传输媒体流片段到一个HTMLMediaElement。 通过使用MSE，你可以动态地修改媒体流而不需要任何的插件。这让前端Java可以做更多的事情，我们可以在Java进行转封装，处理，甚至转码。 三. WebRTC 优点：实时性好，延时低，基于UDP协议 缺点：缺少成熟的开源中转服务器方案 WebRTC（全称：WebReal-Time Communication），网页即时通信，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。 WebRTC 涉及到很多复杂技术，不过好在大多数复杂工作可以抽象成为下面三个 API： MediaStream：获取音频和视频流； RTCPeerConnection：用来建立和维护端到端连接，提供高效的音视频流传输； RTCDataChannel：用于支持端到端的任意应用数据交换。 这里的MediaStream对应的是JS里的navigator.getUserMedia() 方法，它负责从底层平台获取音视频流。音视频流经过WebRTC音视频引擎的自动优化、编码和解码，可以直接读取或者传输到各种目的地。比如，我们可以用getUserMedia获取视频流，再把每一帧都转成ASCII字符播放。MediaStream这个API设计得很简单，使用起来也很方便。 三种协议方式的实现难度依次递增，用户体验也依次递增。 HLS基于HTTP的协议，本质是一个文本协议，将点播转换成直播。 WebSocket本质上算流协议，除了Chrome要求按GoP送数据之外，不会有切片时列表和切片请求的延迟。相比之下，使用WebSocket+MSE进行流媒体数据的传输，实时性更高。 WebRTC由于目前缺少成熟的开源中转服务器方案，在技术落地方面一直在进行相关探索。 |
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/162886.html原文链接：https://javaforall.net
