Libx

直播技术初探

字数统计: 1,761阅读时长: 6 min
2019/10/06 Share

前言

当说起音频和视频,作为一个前端开发者可能最先想到的是<video><audio>,但具体都用了什么技术呢?最近突然想起来这个问题,于是去翻了一些文档和博客,现在来做一个总结

先来谈谈视频

首先从我们的日常生活来看一下表象,我们目前所看的视频视频分为两种,直播录播。 这个大家实际都接触过,比如用直播看比赛什么的,比赛结束你去看回放那就是录播了,看电影/短视频也是一样的道理。录播可以通过下载完整个视频后再看,或者通过流媒体边下边看。看直播只能通过流媒体看最新的画面。

直播

具体在实践中的流程,以腾讯云直播为例:

先来谈谈在直播中常用的几种协议:

  • RTMP: 底层基于TCP,在浏览器端依赖Flash。
  • HTTP-FLV: 基于HTTP流式IO传输FLV,依赖浏览器支持播放FLV。
  • WebSocket-FLV: 基于WebSocket传输FLV,依赖浏览器支持播放FLV。WebSocket建立在HTTP之上,建立WebSocket连接前还要先建立HTTP连接。
  • HLS: Http Live Streaming,苹果提出基于HTTP的流媒体传输协议。HTML5可以直接打开播放。
    RTP: 基于UDP,延迟1秒,浏览器不支持。

HLS协议

HLS(Http Live Streaming),是由苹果提出基于HTTP的流媒体传输协议。HLS包括来一个m3u(8)的索引文件、TS媒体分片文件和key加密串文件。HLS有一个非常大的优点:HTML5可以直接打开播放;这个意味着可以把一个直播链接通过微信等转发分享,不需要安装任何独立的APP,有浏览器即可,所以流行度很高。社交直播,HLS可以说是刚需 。HLS 主要是一个 m3u8 的文件,每个文件都是一些 ts 小片段组合在一起。具体文档在此

这里就出现了一个名词:m3u8

先从M3U说起,M3U是一种播放多媒体列表的文件格式,它的设计初衷是为了播放音频文件,比如MP3,但是越来越多的软件现在用来播放视频文件列表。很多播放器和软件都支持M3U文件格式。M3U8是用UTF-8编码的M3U,。M3UM3U8文件都是HLS的基础,简而言之,M3U8就是一个播放列表。

我这里也找了一个m3u8的文件来测试,https://iptv-org.github.io/iptv/channels/cn.m3u文件的内容格式是这样的:

主索引文件
#EXTM3U 每个M3U文件第一行必须是这个tag,起标示作用
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=409037,RESOLUTION=416x234,CODECS="mp4a.40.2, avc1.42001e"
Gear1/prog_index.m3u8

#EXT-X-STREAM-INF标签的属性列表中直接指明当前流是VIDEO还是AUDIO
包含属性 :

  • BANDWIDTH 指定码率
  • PROGRAM-ID 唯一ID
  • CODECS 指定流的编码类型
  • RESOLUTION:分辨率
    子索引文件
    #EXTM3U m3u文件头,必须放在第一行
    #EXT-X-MEDIA-SEQUENCE 第一个TS分片的序列号
    #EXT-X-TARGETDURATION 每个分片TS的最大的时长
    #EXT-X-ALLOW-CACHE 是否允许cache
    #EXT-X-ENDLIST m3u8文件结束符
    #EXTINF extra info,分片TS的信息,如时长,带宽等
    #EXTM3U
    #EXT-X-TARGETDURATION:11#EXT-X-VERSION:3#EXT-X-MEDIA-SEQUENCE:0#EXT-X-PLAYLIST-TYPE:VOD
    #EXTINF:10.133333,
    fileSequence0.ts
    xxx
    #EXT-X-ENDLIST

主索引文件与子索引文件的区别:

  • 主索引文件和子索引文件都是.M3U8的playlist
  • 主索引文件只需下载一次,但对于直播节目子索引文件定期重新加载

ts 文件,就是存放视频的文件:每一个 .m3u8 文件,分别对应若干个 ts 文件,这些 ts 文件才是真正存放视频的数据,m3u8 文件只是存放了一些 ts 文件的配置信息和相关路径

HLS只请求基本的HTTP报文,与实时传输协议(RTP)不同,HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。

大致流程:

RTMP 协议

文档

RTMP(Real Time Messaghing Protocal)协议,是由Adobe为Flash推出的音视频和数据传输开发的协议,基于TCP。首先、强依赖于Flash在更早的一段时间还是非常好的特性,web平台基本都会支持Flash,这给开发者带来了非常多的便利.但是目前Flash在被抛弃的边缘,所以就会出现比较尴尬的局面.

协议中的基本数据单元为消息(Message),传输的过程中消息会被拆分为更小的消息块(Chunk)单元。最后将分割后的消息块通过 TCP 协议传输,接收端再反解接收的消息块恢复成流媒体数据。

RTMP 主要有以下几个优点:RTMP 是专为流媒体开发的协议,对底层的优化比其它协议更加优秀,同时它 Adobe Flash 支持好,基本上所有的编码器(摄像头之类)都支持 RTMP 输出。

但是目前来讲一方面是它是基于 TCP 传输,非公共端口,可能会被防火墙阻拦;另一方面,也是比较坑的一方面是 RTMP 为 Adobe 私有协议,很多设备无法播放,特别是在 iOS 端,需要使用第三方解码器才能播放。

HTTP-FLV

HTTP-FLV: 基于HTTP流式IO传输FLV,依赖浏览器支持播放FLV。其结合了 RTMP 的低延时,并且可以复用现有 HTTP 分发资源的流式协议。将音视频数据封装成FLV,然后通过HTTP协议传输给客户端。

WebRTC

部分浏览器直接支持,目前存在的架构是在推流端将视频推向Server的阶段使用WebRTC.而在服务器分发直播视频时,依然使用RTMP、FLV等传统方案进行处理.

常见直播协议延迟与性能数据以下数据只做对比参考,数据来源于(https://github.com/gwuhaolin/blog/edit/master/source/_posts/使用flv.js做直播.md)

传输协议 播放器 延迟 内存 CPU
RTMP Flash 1s 430M 11%
HTTP-FLV Video 1s 310M 4.4%
HLS Video 20s 205M 3%

流媒体加密

为什么要加密视频?

付费观看视频的模式是很多平台的核心业务,因此对视频服务进行加密的技术变得尤为重要。
两种加密方式:
防盗链:通过验证的用户才能访问到没有加密的视频内容,但视频很容易就被下载的风险,严格来说这不属于加密。本质是资源访问授权。
加密视频本身:通过对称加密算法加密视频内容本身,用户获得加密后的视频内容,通过验证的用户可以获取解密视频的密钥,在客户端解密后播放。这种方式实现起来流程复杂,带来更多的计算量。

CATALOG
  1. 1. 前言
    1. 1.1. 直播
      1. 1.1.1. HLS协议
        1. 1.1.1.1. 主索引文件
        2. 1.1.1.2. 子索引文件
      2. 1.1.2. RTMP 协议
      3. 1.1.3. HTTP-FLV
      4. 1.1.4. WebRTC
      5. 1.1.5. 常见直播协议延迟与性能数据以下数据只做对比参考,数据来源于(https://github.com/gwuhaolin/blog/edit/master/source/_posts/使用flv.js做直播.md)
    2. 1.2. 流媒体加密