整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

HLS(m3u8直播文件)在线直播实现

LS (HTTP Live Streaming),Apple的动态码率自适应技术。主要用于PC和Apple终端的音视频服务。包括一个m3u(8)的索引文件,TS媒体分片文件和key加密串文件。

HLS (HTTP Live Streaming)

常用的流媒体协议主要有 HTTP 渐进下载和基于 RTSP/RTP 的实时流媒体协议,这二种基本是完全不同的东西,目前比较方便又好用的是用 HTTP 渐进下载方法。在这个中 apple 公司的 HTTP Live Streaming 是这个方面的代表。它最初是苹果公司针对iPhone、iPod、iTouch和iPad等移动设备而开发的流.现在见到在桌面也有很多应用了,HTML5 是直接支持这个。

但是HLS协议的小切片方式会生成大量的文件,存储或处理这些文件会造成大量资源浪费。如果要实现数天的时移,索引量将会是个巨额数字,并明显影响请求速度。因此,HLS协议对存储I/O要求相当苛刻。对此,也有公司提出了非常好的解决方案。

新型点播服务器系统,独创了内存缓存数据实时切片技术,颠覆了这种传统实现方法,从根本上解决了大量切片的碎片问题,使得单台服务器的切片与打包能力不再是瓶颈。其基本原理如下:

不将TS切片文件存到磁盘,而是存在内存当中,这种技术使得服务器的磁盘上面不再会有“数以吨计”的文件碎片,极大减少了磁盘的I/O次数,延长了服务器磁盘的使用寿命,极大提高了服务器运行的稳定性。同时,由于使用这种技术,使得终端请求数据时直接从服务器的内存中获取,极大提高了对终端数据请求的反应速度,优化了视频观看体验。


使用下面两个工具

1、ffmpeg(下载地址:http://ffmpeg.org/download.html)

ffmpeg用来负责把直播流(RTSP)切片成*.ts文件

主要参数:

-i 设定输入流

-f 设定输出格式

-ss 开始时间

视频参数:

-b 设定视频流量,默认为200Kbit/s

-r 设定帧速率,默认为25

-s 设定画面的宽与高

-aspect 设定画面的比例

-vn 不处理视频

-vcodec 设定视频编解码器,未设定时则使用与输入流相同的编解码器

-keyint_min 60 最小关键帧间隔

-g 60 GOP 长度

-sc_threshold 0 根据视频的运动场景,自动为你添加额外的I 帧,所以会导致你编出来的视频关键帧间隔不是你设置的长度,

这是只要将它设为0

音频参数:

-ar 设定采样率

-ac 设定声音的Channel 数

-acodec 设定声音编解码器,未设定时则使用与输入流相同的编解码器

-an 不处理音频

----------------------------------------------------分隔线----------------------------------------------------

主要参数

-i 设定输入档名。

-f 设定输出格式。

-y 若输出档案已存在时则覆盖档案。

-fs 超过指定的档案大小时则结束转换。

-ss 从指定时间开始转换。

-title 设定标题。

-timestamp 设定时间戳。

-vsync 增减Frame 使影音同步。

影像参数

-b 设定影像流量,默认为200Kbit/秒。( 单位请参照下方注意事项)

-r 设定FrameRate 值,默认为25。

-s 设定画面的宽与高。

-aspect 设定画面的比例。

-vn 不处理影像,于仅针对声音做处理时使用。

-vcodec 设定影像影像编解码器,未设定时则使用与输入档案相同之编解码器。

声音参数

-ab 设定每Channel(最近的SVN 版为所有Channel 的总合)的流量。( 单位请参照下方注意事项)

-ar 设定采样率。

-ac 设定声音的Channel 数。

-acodec 设定声音编解码器,未设定时与影像相同,使用与输入档案相同之编解码器。

-an 不处理声音,于仅针对影像做处理时使用。

-vol 设定音量大小,256 为标准音量。(要设定成两倍音量时则输入512,依此类推。)

注意事项

以-b 及ab 参数设定流量时,根据使用的ffmpeg 版本,须注意单位会有kbits/sec 与bits/sec 的不同。(可用ffmpeg -h 显

示说明来确认单位。)

例如,单位为bits/sec 的情况时,欲指定流量64kbps 时需输入‘ -ab 64k ’;单位为kbits/sec 的情况时则需输入‘ -ab 64 ’。

以-acodec 及-vcodec 所指定的编解码器名称,会根据使用的ffmpeg 版本而有所不同。例如使用AAC 编解码器时,会有输入aac

与libfaac 的情况。此外,编解码器有分为仅供解码时使用与仅供编码时使用,因此一定要利用ffmpeg -formats 确认输入的

编解码器是否能运作。

2、WEB服务器(IIS,Apache,Nginx)分发切片

web服务器配置在这里就不多说了。


demo:http://live.16it.wang


如有需要源码的可以联系我:519468341

享 | 刘博(又拍云多媒体开发工程师)

又小拍:

如何实现HTML5直播技术是直播创业团队一直想要攻克的难题。12月1日20:00,深度参与“又拍直播云”开发的工程师刘博就如何利用WebSocket+MSE实现HTML5直播在微信群里进行了分享。小拍马不停蹄将刘博的分享内容整理成了文字,并插入一些PPT便于大家了解。全文整理如下:

下面就是分享内容啦~

当前为了满足比较火热的移动Web端直播需求,一系列的HTML5直播技术迅速的发展起来。

常见的可用于HTML5的直播技术有HLS、WebSocket与WebRTC。今天我向大家介绍WebSocket与MSE相关的技术要点,并在最后通过一个实例来展示具体用法。

分享大纲

⊙WebSocket协议介绍

⊙WebSocket Client/Server API介绍

⊙MSE介绍

⊙fMP4介绍

⊙Demo展示

WebSocket

通常的Web应用都是围绕着HTTP的请求/响应模型构建的。所有的HTTP通信都通过客户端来控制,由客户端向服务器发出一个请求,服务器接收和处理完毕后再返回结果给客户端,客户端将数据展现出来。由于这种模式不能满足实时应用需求,于是出现了SSE、Comet等 "服务器推" 的长连接技术。

WebSocket是基于TCP连接之上的通信协议,可以在单个TCP连接上进行全双工的通信。WebSocket在2011年被IETF定为标准RFC 6455,并被RFC 7936补充规范,WebSocket API被W3C定为标准。

WebSocket是独立地创建在TCP上的协议,HTTP协议中的那些概念都和WebSocket没有关联,唯一关联的是使用HTTP协议的101状态码进行协议切换时,使用的TCP端口是80,可以绕过大多数防火墙的限制。

WebSocket握手

为了更方便地部署新协议,HTTP/1.1引入了Upgrade机制,使得客户端和服务端之间可以借助已有的HTTP语法升级到其它协议。这个机制在RFC7230的6.7 Upgrade一节中有详细描述。

要发起HTTP/1.1协议升级,客户端必须在请求头部中指定这两个字段 ▽

Connection: Upgrade

Upgrade: protocol-name[/protocol-version]

如果服务端同意升级,那么需要这样响应 ▽

HTTP/1.1 101 Switching Protocols

Connection: upgrade

Upgrade: protocol-name[/protocol-version]

[... data defined by new protocol ...]

可以看到,HTTP Upgrade响应的状态码是101,并且响应正文可以使用新协议定义的数据格式。

WebSocket握手就利用了这种HTTP Upgrade机制。一旦握手完成,后续数据传输直接在TCP上完成。

WebSocket JavaScript API

目前主流的浏览器提供了WebSocket的API接口,可以发送消息(文本或者二进制)给服务器,并且接收事件驱动的响应数据。

Step1. 检查浏览器是否支持WebSocket

if(window.WebSocket) {

// WebSocket代码

}

Step2. 建立连接

var ws = new WebSocket('ws://localhost:8327');

Step3. 注册回调函数以及收发数据

分别注册WebSocket对象的onopen、onclose、onerror以及onmessage回调函数。

通过ws.send()来进行发送数据,这里不仅可以发送字符串,也可以发送Blob或ArrayBuffer类型的数据。

如果接收的是二进制数据,需要将连接对象的格式设为blob或arraybuffer。

ws.binaryType = 'arraybuffer';

WebSocket Golang API

服务器端WebSocket库我推荐使用Google自己的golang.org/x/net/websocket,可以非常方便的与net/http一起使用。也可以将WebSocket的handler function通过websocket.Handler转换成http.Handler,这样就可以跟net/http库一起使用了。

然后通过websocket.Message.Receive来接收数据,通过websocket.Message.Send来发送数据。

具体代码可以看下面的Demo部分。

MSE

在介绍MSE之前,我们先看看HTML5<audio>和<video>有哪些限制。

HTML5<audio>和<video>标签的限制

  • 不支持流

  • 不支持DRM和加密

  • 很难自定义控制, 以及保持跨浏览器的一致性

  • 编解码和封装在不同浏览器支持不同

MSE是解决HTML5的流问题。

Media Source Extensions(MSE)是Chrome、Safari、Edge等主流浏览器支持的一个新的Web API。MSE是一个W3C标准,允许JavaScript动态构建<video>和<audio>的媒体流。它定义了对象,允许JavaScript传输媒体流片段到一个 HTMLMediaElement。

通过使用MSE,你可以动态地修改媒体流而不需要任何插件。这让前端JavaScript可以做更多的事情—— 在JavaScript进行转封装、处理,甚至转码。

虽然MSE不能让流直接传输到media tags上,但是MSE提供了构建跨浏览器播放器的核心技术,让浏览器通过JavaScript API来推音视频到media tags上。

Browser Support

通过caniuse来检查是否浏览器支持情况。

通过MediaSource.isTypeSupported()可以进一步地检查codec MIME类型是否支持。

fMP4

比较常用的视频封装格式有WebM和fMP4。

WebM和WebP是两个姊妹项目,都是由Google赞助的。由于WebM是基于Matroska的容器格式,天生是流式的,很适合用在流媒体领域里。

下面着重介绍一下fMP4格式。

我们都知道MP4是由一系列的Boxes组成的。普通的MP4的是嵌套结构的,客户端必须要从头加载一个MP4文件,才能够完整播放,不能从中间一段开始播放。

而fMP4由一系列的片段组成,如果服务器支持byte-range请求,那么,这些片段可以独立的进行请求到客户端进行播放,而不需要加载整个文件。

为了更加形象的说明这一点,下面我介绍几个常用的分析MP4文件的工具。

  • gpac,原名mp4box,是一个媒体开发框架,在其源码下有大量的媒体分析工具,可以使用testapps;

  • mp4box.js,是mp4box的Javascript版本;

  • bento4,一个专门用于MP4的分析工具;

  • mp4parser,在线MP4文件分析工具。

fragment mp4 VS non-fragment mp4

下面是一个fragment mp4文件通过mp4parser(http://mp4parser.com)分析后的截图 ▽

下面是一个non-fragment mp4文件通过mp4parser分析后的截图 ▽

我们可以看到non-fragment mp4的最顶层box类型非常少,而fragment mp4是由一段一段的moof+mdat组成的,它们已经包含了足够的metadata信息与数据, 可以直接seek到这个位置开始播放。也就是说fMP4是一个流式的封装格式,这样更适合在网络中进行流式传输,而不需要依赖文件头的metadata。

Apple在WWDC 2016大会上宣布会在iOS 10、tvOS、macOS的HLS中支持fMP4,可见fMP4的前景非常的好。

值得一提的是,fMP4、CMAF、ISOBMFF其实都是类似的东西。

MSE JavaScript API

从高层次上看,MSE提供了

  • 一套 JavaScript API 来构建 media streams

  • 一个拼接和缓存模型

  • 识别一些 byte 流类型:

  • WebM

  • ISO Base Media File Format

  • MPEG-2 Transport Streams

MSE内部结构

MSE本身的设计是不依赖任务特定的编解码和容器格式的,但是不同的浏览器支持程度是不一样的。

可以通过传递一个MIME类型的字符串到静态方法:MediaSource.isTypeSupported来检查。比如 ▽

MediaSource.isTypeSupported('audio/mp3'); // false

MediaSource.isTypeSupported('video/mp4'); // true

MediaSource.isTypeSupported('video/mp4; codecs="avc1.4D4028, mp4a.40.2"'); // true

获取Codec MIME string的方法可以通过在线的mp4info(http://nickdesaulniers.github.io/mp4info),或者使用命令行mp4info test.mp4 | grep Codecs,可以得到类似如下结果 ▽

mp4info fmp4.mp4| grep Codec

Codecs String: mp4a.40.2

Codecs String: avc1.42E01E

当前,H.264 + AAC的MP4容器在所有的浏览器都支持。

普通的MP4文件是不能和MSE一起使用的, 需要将MP4进行fragment化。

检查一个MP4是否已经fragment的方法 ▽

mp4dump test.mp4 | grep "\[m"

如果是non-fragment会显示如下信息 ▽

mp4dump nfmp4.mp4 | grep "\[m"

[mdat] size=8+50873

[moov] size=8+7804

[mvhd] size=12+96

[mdia] size=8+3335

[mdhd] size=12+20

[minf] size=8+3250

[mdia] size=8+3975

[mdhd] size=12+20

[minf] size=8+3890

[mp4a] size=8+82

[meta] size=12+78

如果已经fragment,会显示如下的类似信息 ▽

mp4dump fmp4.mp4 | grep "\[m" | head -n 30

[moov] size=8+1871

[mvhd] size=12+96

[mdia] size=8+312

[mdhd] size=12+20

[minf] size=8+219

[mp4a] size=8+67

[mdia] size=8+371

[mdhd] size=12+20

[minf] size=8+278

[mdia] size=8+248

[mdhd] size=12+20

[minf] size=8+156

[mdia] size=8+248

[mdhd] size=12+20

[minf] size=8+156

[mvex] size=8+144

[mehd] size=12+4

[moof] size=8+600

[mfhd] size=12+4

[mdat] size=8+138679

[moof] size=8+536

[mfhd] size=12+4

[mdat] size=8+24490

[moof] size=8+592

[mfhd] size=12+4

[mdat] size=8+14444

[moof] size=8+312

[mfhd] size=12+4

[mdat] size=8+1840

[moof] size=8+600

把一个non-fragment MP4转换成fragment MP4。

可以使用FFmpeg的 -movflags来转换。

对于原始文件为非MP4文件 ▽

ffmpeg -i trailer_1080p.mov -c:v copy -c:a copy -movflags frag_keyframe+empty_moov bunny_fragmented.mp4

对于原始文件已经是MP4文件 ▽

ffmpeg -i non_fragmented.mp4 -movflags frag_keyframe+empty_moov fragmented.mp4

或者使用mp4fragment ▽

mp4fragment input.mp4 output.mp4

DEMO TIME

刘博在分享的最后阶段,展示了两个demo,分别是MSE Vod Demo、MSE Live Demo

MSE Vod Demo

  • 展示利用MSE和WebSocket实现一个点播服务

  • 后端读取一个fMP4文件,通过WebSocket发送给MSE,进行播放

MSE Live Demo

  • 展示利用MSE和WebSocket实现一个直播服务

  • 后端代理一条HTTP-FLV直播流,通过WebSocket发送给MSE,进行播放

  • 前端MSE部分做了很多工作, 包括将flv实时转封装成了fMP4,这里引用了videojs-flow的实现

Q & A

Q1:对于没有公网iIP的客户如何通过RTMP协议推流?

A1:用户客户端进行RTMP推流,不需要公网IP,推到直播系统分配给你的地址就可以了。

Q2:MSE客户端做很多东西,可以转码、解码, 这个会有性能问题吗? 还有这个技术,目前有公司在大批量用吗?

A2:目前该技术在实验阶段,转封装的话,对性能要求不高,我们在各自型号的手机上测试都没有问题。目前除了微信内置浏览器对MSE支持不好,大部分浏览器对MSE支持都比较好。

Q3:没做过相关内容,能简单介绍一下HTTP-FLV么?

A3:HTTP-FLV就是将FLV流以HTTP长连接的形式分发出去,目前在各大直播平台都用的比较多。大家可以关注下又拍云微信公众账号,之前专门有一篇文章介绍HTTP-FLV。

Q4:不大了解HTTP-FLV,既然是长时间的状态性连接,为什么不用tcp/socket呢?

A5: FLV不能在<video>标签直接播放,所以需要通过MSE转封装成MP4,再吐到<video>标签进行播放。

Q5:哔哩哔哩H5播放器是基于WebSocket与MSE技术实现的嘛?

A5:B站开源的flv.js是一个非常好的项目,是基于 MSE 实现的,实时性做的也比较好,B 站自己已经在网站播放器上使用了。

Q6:VLC器播放和网页播放,哪个快啊?

A6:播放器端延时,一个重要指标是播放器的缓存区大小。VLC的默认缓存区比较大,所以,VLC通常延时会大一些。

Q7:可以介绍下秒开技术么,以及秒开的原理?

A7:秒开可以在服务器端多缓存一个GoP来实现,这样播放器请求的第一帧能保证是I帧,可以立即播放,以此达到秒开的效果.

Refs

WebSocket

  • rfc6455

  • HTTP Upgrade

  • WebSocket API

  • MDN WebSocket

  • videojs-flow

MSE

  • W3C

  • MDN MSE

  • HTML5 Codec MIME

着直播行业大火,游戏、乐秀、教育、发布会等直播类产品层出不穷,能够满足各方人员的需求。在直播中,总能在其中找到适合自己的产品内容。喜欢玩游戏的可以看游戏直播,想学点工作技能的,也可以观看大牛现场授课,甚至你能通过直播跟各大主播实时互动。看了这么多直播,你好像发现了一个小秘密,不同类型的直播延时有所不同,像与主播实时互动的一般延迟比较短,而相对的,在线教育这一类就比较长了。这就是我今天想给大家讲解的一些东西,除了网络环境以外,对延时影响较大的就是直播架构中选择的直播协议。接下来,我就给大家简单介绍下常见的直播协议吧。

常见的直播协议

国内常见的直播协议有几个:RTMP、HLS、HTTP-FLV,下面我们来一一介绍。

RTMP,全称 Real Time Messaging Protocol,即实时消息传送协议。Adobe 公司为 Flash 播放器和服务器之间音视频数据传输开发的私有协议。工作在 TCP 之上的明文协议,默认使用端口 1935。协议中的基本数据单元成为消息(Message),传输的过程中消息会被拆分为更小的消息块(Chunk)单元。最后将分割后的消息块通过 TCP 协议传输,接收端再反解接收的消息块恢复成流媒体数据。

RTMP 主要有以下几个优点:RTMP 是专为流媒体开发的协议,对底层的优化比其它协议更加优秀,同时它 Adobe Flash 支持好,基本上所有的编码器(摄像头之类)都支持 RTMP 输出。现在 PC 市场巨大,PC 主要是 Windows,Windows 的浏览器基本上都支持 Flash。另外RTMP适合长时间播放,曾经有过测试,联系 100 万秒,即 10 天多连续播放没有出现问题。最后 RTMP 的延迟相对较低,一般延时在 1-3s 之间,一般的视频会议,互动式直播,完全是够用的。

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

FLV (Flash Video) 是 Adobe 公司推出的另一种视频格式,是一种在网络上传输的流媒体数据存储容器格式。其格式相对简单轻量,不需要很大的媒体头部信息。整个 FLV 由 The FLV Header, The FLV Body 以及其它 Tag 组成。因此加载速度极快。采用 FLV 格式封装的文件后缀为 .flv。

而我们所说的 HTTP-FLV 即将流媒体数据封装成 FLV 格式,然后通过 HTTP 协议传输给客户端。

HTTP-FLV 依靠 MIME 的特性,根据协议中的 Content-Type 来选择相应的程序去处理相应的内容,使得流媒体可以通过 HTTP 传输。相较于 RTMP 协议,HTTP-FLV 能够好的穿透防火墙,它是基于 HTTP/80 传输,有效避免被防火墙拦截。除此之外,它可以通过 HTTP 302 跳转灵活调度/负载均衡,支持使用 HTTPS 加密传输,也能够兼容支持 Android,iOS 的移动端。

说了这么多优点,也来顺便说下 HTTP-FLV 的缺点,由于它的传输特性,会让流媒体资源缓存在本地客户端,在保密性方面不够好。因为网络流量较大,它也不适合做拉流协议。

上述两个协议都是有Adobe公司推出的,而下面要讲的 HLS (HTTP Live Streaming) 则是苹果公司基于 HTTP 的流媒体传输协议。主要应用于 iOS 设备,包含(iPhone, iPad, iPod touch) 以及 Mac OSX 提供音视频直播服务和录制内容(点播)等服务。

相对于常见的流媒体协议,HLS 最大的不同在于它并不是一下请求完整的数据流。它会在服务器端将流媒体数据切割成连续的时长较短的 ts 小文件,并通过 M3U8 索引文件按序访问 ts 文件。客户端只要不停的按序播放从服务器获取到的文件,从而实现播放音视频。

相较 RTMP 而言,使用 HLS 在 HTML5 页面上实现播放非常简单:

直接:

或者:

HLS 的优势:

  • Apple 的全系列产品支持:由于 HLS 是苹果提出的,所以在 Apple 的全系列产品包括 iPhone、 iPad、safari 都不需要安装任何插件就可以原生支持播放 HLS, 现在 Android 也加入了对 HLS 的支持。
  • 穿透防火墙。基于 HTTP/80 传输,有效避免防火墙拦截
  • 性能高。通过 HTTP 传输, 支持网络分发,CDN 支持良好,且自带多码率自适应,Apple 在提出 HLS 时,就已经考虑了码流自适应的问题。

HLS 的劣势:

  • 实时性差,延迟高。HLS 的延迟基本在 10s+ 以上
  • 文件碎片。特性的双刃剑,ts 切片较小,会造成海量小文件,对存储和缓存都有一定的挑战

流媒体协议 RTMP, HTTP-FLV, HLS 简单对比


RTMP 协议为流媒体而设计,在推流中用的比较多,同时大多 CDN 厂商支持RTMP 协议。

HTTP-FLV 使用类似 RTMP流式的 HTTP 长连接,需由特定流媒体服务器分发的,兼顾两者的优点。以及可以复用现有 HTTP 分发资源的流式协议。它的实时性和 RTMP 相等,与 RTMP 相比又省去了部分协议交互时间,首屏时间更短,可拓展的功能也更多。

HLS 作为苹果提出的直播协议,在 iOS 端占据了不可撼动的地位,Android 端也同时提供相应的支持。

又拍云一站式直播解决方案基于又拍云 CDN,支持 RTMP、HTTP-FLV 和 HLS 三大直播协议,并且通过智能调度、链路保障、追帧处理、丢帧处理以及业界首创的 HLS+ 技术,将 RTMP、HTTP-FLV 直播延迟控制在1秒内,将 HLS 直播延时控制在 4 秒左右。