• 我的订阅
  • 科技

H5直播技术起航

类别:科技 发布时间:2023-01-11 10:00:00 来源:京东云企业管家

作者:京东科技 吴磊

音视频基本概念

视频格式就是通常所说的.mp4,.flv,.ogv,.webm等。简单来说,它其实就是一个盒子,用来将实际的视频流以一定的顺序放入,确保播放的有序和完整性。

视频压缩格式和视频格式具体的区别就是,它是将原始的视频码流变为可用的数字编码。因为,原始的视频流非常大,打个比方就是,你直接使用手机录音,你会发现你几分钟的音频会比市面上出现的 MP3 音频大小大很多,这就是压缩格式起的主要作用。

首先,由原始数码设备提供相关的数字信号流,然后经由视频压缩算法,大幅度的减少流的大小,然后交给视频盒子,打上相应的dts,pts字段,最终生成可用的视频文件。 DTS(Decoding Time Stamp):即解码时间戳,这个时间戳的意义在于告诉播放器该在什么时候解码这一帧的数据。 PTS(Presentation Time Stamp):即显示时间戳,这个时间戳用来告诉播放器该在什么时候显示这一帧的数据。

视频编码

视频实际上就是一帧一帧的图片,拼接起来进行播放而已。而图片本身也可以进行相关的压缩,比如去除重复像素,合并像素块等等。不过,还有另外一种压缩方法就是,运动估计和运动补偿压缩,因为相邻图片一定会有一大块是相似的,所以,为了解决这个问题,可以在不同图片之间进行去重。

所以,总的来说,常用的编码方式分为三种:变换编码:消除图像的帧内冗余运动估计和运动补偿:消除帧间冗余熵编码:提高压缩效率 熵编码即编码过程中按熵原理不丢失任何信息的编码。信息熵为信源的平均信息量(不确定性的度量)。常见的熵编码有:香农(Shannon)编码、哈夫曼(Huffman)编码和算术编码(arithmetic coding)。

直播

现在,常用的直播协议有 RTMP,HLS,HTTP-FLV。最常用的还是 HLS 协议,因为支持度高,技术简单,但是延迟非常严重。这对一些对实时性比较高的场景,比如运动赛事直播来说非常的不友好。这里来细分的看一下每个协议。

协议对比

协议优势劣势延时HLS支持性广延时巨高10s 以上RTMP延时性好,灵活量大的话,负载较高1s 以上HTTP-FLV延时性好,游戏直播常用只能在手机 APP 播放2s 以上HLS

HLS 全称是 HTTP Live Streaming。这是Apple提出的直播流协议。

HLS 由两部分构成,一个是.m3u8文件,一个是.ts视频文件(TS 是视频文件格式的一种)。整个过程是,浏览器会首先去请求.m3u8的索引文件,然后解析m3u8,找出对应的.ts文件链接,并开始下载。

他的使用方式为:

H5直播技术起航

直接可以将m3u8写进src中,然后交由浏览器自己去解析。当然也可以采取fetch来手动解析并获取相关文件。HLS 详细版的内容比上面的简版多了一个playlist,也可以叫做master。在master中,会根据网络段实现设置好不同的 m3u8 文件,比如,3G/4G/wifi 网速等。比如,一个 master 文件中为:

#EXTM3U

#EXT-X-VERSION:6

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2855600,CODECS="avc1.4d001f,mp4a.40.2",RESOLUTION=960x540

live/medium.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=5605600,CODECS="avc1.640028,mp4a.40.2",RESOLUTION=1280x720

live/high.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1755600,CODECS="avc1.42001f,mp4a.40.2",RESOLUTION=640x360

live/low.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=545600,CODECS="avc1.42001e,mp4a.40.2",RESOLUTION=416x234

live/cellular.m3u8

大家只要关注BANDWIDTH(带宽)字段,其他的看一下字段内容大致就清楚了。假如这里选择high.m3u8文件,那么,里面内容为:

#EXTM3U

#EXT-X-VERSION:6

#EXT-X-TARGETDURATION:10

#EXT-X-MEDIA-SEQUENCE:26

#EXTINF:9.901,

http://media.example.com/wifi/segment26.ts

#EXTINF:9.901,

http://media.example.com/wifi/segment27.ts

#EXTINF:9.501,

http://media.example.com/wifi/segment28.ts

注意,其中以ts结尾的链接就是在直播中真正需要播放的视频文件。该第二级的m3u8文件也可以叫做media文件。该文件,其实有三种类型:live playlist: 动态列表。顾名思义,该列表是动态变化的,里面的 ts 文件会实时更新,并且过期的 ts 索引会被删除。默认,情况下都是使用动态列表。event playlist: 静态列表。它和动态列表主要区别就是,原来的 ts 文件索引不会被删除,该列表是不断更新,而且文件大小会逐渐增大。它会在文件中,直接添加 #EXT-X-PLAYLIST-TYPE:EVENT 作为标识。VOD playlist: 全量列表。它就是将所有的 ts 文件都列在 list 当中。如果,使用该列表,就和播放一整个视频没有啥区别了。它是使用 #EXT-X-ENDLIST 表示文件结尾。 https://developer.apple.com/library/archive/referencelibrary/GettingStarted/AboutHTTPLiveStreaming/about/about.html

HLS 缺陷

HLS 缺陷就是延迟性太大了。HLS 中的延时包括:TCP 握手m3u8 文件下载m3u8 文件下所有 ts 文件下载

这里先假设每个 ts 文件播放时长为 5s,每个 m3u8 最多可携带的 ts 文件数为 3~8。那么最大的延迟则为 40s。注意,只有当一个m3u8文件下所有的 ts 文件下载完后,才能开始播放。这里还不包括 TCP 握手,DNS 解析,m3u8 文件下载。所以,HLS 总的延时是非常令人绝望的。

那解决办法有吗? 有,很简单,要么减少每个 ts 文件播放时长,要么减少m3u8的中包含 ts 的数量。如果超过平衡点,那么每次请求新的 m3u8 文件时,都会加上一定的延时,所以,这里需要根据业务指定合适的策略。

RTMP

RTMP 全称为:Real-Time Messaging Protocol。它是基于FLV格式进行开发的,所以,第一反应就是,又不能用了!!!

H5直播技术起航

是的,在现在设备中,由于 FLV 的不支持,基本上 RTMP 协议在 Web 中,根本用不到。不过,由于MSE(MediaSource Extensions)的出现,在 Web 上直接接入 RTMP 也不是不可能的。基本思路是根据 WebSocket 直接建立长连接进行数据的交流和监听。RTMP 协议根据不同的套层,也可以分为:纯 RTMP: 直接通过 TCP 连接,端口为 1935RTMPS: RTMP + TLS/SSL,用于安全性的交流。RTMPE: RTMP + encryption。在 RTMP 原始协议上使用,Adobe 自身的加密方法RTMPT: RTMP + HTTP。使用 HTTP 的方式来包裹 RTMP 流,延迟性比较大。RTMFP: RMPT + UDP。该协议常常用于 P2P 的场景中,针对延时有变态的要求。

RTMP 内部是借由 TCP 长连接协议传输相关数据,所以,它的延时性非常低。并且,该协议灵活性非常好(所以,也很复杂),它可以根据 message stream ID 传输数据,也可以根据 chunk stream ID 传递数据。两者都可以起到流的划分作用。流的内容也主要分为:视频,音频,相关协议包等。

HTTP-FLV

该协议和 RTMP 比起来其实差别不大,只是落地部分有些不同:

RTMP 是直接将流的传输架在 RTMP 协议之上,而 HTTP-FLV 是在 RTMP 和客户端之间套了一层转码的过程,由于,每个 FLV 文件是通过 HTTP 的方式获取的,所以,它通过抓包得出的协议头需要使用chunked编码。

Content-Type:video/x-flv

Expires:Fri, 10 Feb 2017 05:24:03 GMT

Pragma:no-cache

Transfer-Encoding:chunked

它用起来比较方便,不过后端实现的难度和直接使用 RTMP 来说还是比较大的。

前端音视频流

由于各大浏览器的对 FLV 的围追堵截,导致 FLV 在浏览器的生存状况堪忧,但是,FLV 凭借其格式简单,处理效率高的特点,使各大视频后台的开发者都舍不得弃用,如果一旦更改的话,就需要对现有视频进行转码,比如变为 MP4,这样不仅在播放,而且在流处理来说都有点重的让人无法接受。而 MSE 的出现,彻底解决了这个尴尬点,能够让前端能够自定义来实现一个 Web 播放器,确实完美。(不过,苹果觉得没这必要,所以,在 IOS 上无法实现。)

MSE

MSE 全称就是Media Source Extensions。它是一套处理视频流技术的简称,里面包括了一系列 API:Media Source,Source Buffer等。在没有 MSE 出现之前,前端对 video 的操作,仅仅局限在对视频文件的操作,而并不能对视频流做任何相关的操作。现在 MSE 提供了一系列的接口,使开发者可以直接提供 media stream。

来看一下 MSE 是如何完成基本流的处理的。

var vidElement = document.querySelector('video');

if (window.MediaSource) {

var mediaSource = new MediaSource();

vidElement.src = URL.createObjectURL(mediaSource);

mediaSource.addEventListener('sourceopen', sourceOpen);

} else {

console.log("The Media Source Extensions API is not supported.")

}

function sourceOpen(e) {

URL.revokeObjectURL(vidElement.src);

var mime = 'video/webm; codecs="opus, vp9"';

var mediaSource = e.target;

var sourceBuffer = mediaSource.addSourceBuffer(mime);

var videoUrl = 'droid.webm';

fetch(videoUrl)

.then(function(response) {

return response.arrayBuffer();

})

.then(function(arrayBuffer) {

sourceBuffer.addEventListener('updateend', function(e) {

if (!sourceBuffer.updating && mediaSource.readyState === 'open') {

mediaSource.endOfStream();

}

});

sourceBuffer.appendBuffer(arrayBuffer);

});

}

上面这个例子可以简单理解为:

H5直播技术起航

第一步,通过异步拉取数据。第二步,通过 MediaSource 处理数据。第三步,将数据流交给 audio/video 标签进行播放。

而中间传递的数据都是通过Buffer的形式来进行传递的。

H5直播技术起航

中间有个需要注意的点,MS 的实例通过URL.createObjectURL()创建的 url 并不会同步连接到 video.src。换句话说,URL.createObjectURL()只是将底层的流(MS)和 video.src 连接中间者,一旦两者连接到一起之后,该对象就没用了。

MediaSource MediaSource 是 Media Source Extensions API 表示媒体资源 HTMLMediaElement 对象的接口。MediaSource 对象可以附着在 HTMLMediaElement 在客户端进行播放。

MS(MediaSource) 只是一系列视频流的管理工具,它可以将音视频流完整的暴露给 Web 开发者来进行相关的操作和处理。所以,它本身不会造成过度的复杂性。

MS 整个只挂载了 4 个属性,3 个方法和 1 个静态测试方法。

4 个属性:sourceBuffers: 获得当前创建出来的 SourceBufferactiveSourceBuffers: 获得当前正处于激活状态的 SourceBufferreadyState: 返回当前 MS 的状态,比如:closed,open,ended.duration: 设置当前 MS 的播放时长。

3 个方法:addSourceBuffer(): 根据给定的 MIME 创建指定类型的 SourceBufferremoveSourceBuffer(): 将 MS 上指定的 SourceBuffer 移除。endOfStream(): 直接终止该流

1 个静态测试方法:isTypeSupported(): 主要用来判断指定的音频的 MIME 是否支持。

最基本的就是使用addSourceBuffer该方法来获得指定的 SourceBuffer。

var sourceBuffer = mediaSource.addSourceBuffer('video/mp4; codecs="avc1.42E01E, mp4a.40.2"');

资料:https://developer.mozilla.org/zh-CN/docs/Web/API/MediaSource

SourceBuffer SourceBuffer 接口表示通过 MediaSource 对象传递到 HTMLMediaElement 并播放的媒体分块。它可以由一个或者多个媒体片段组成。

一旦利用 MS 创建好 SourceBuffer 之后,后续的工作就是将额外获得的流放进 Buffer 里面进行播放即可。所以,SourceBuffer 提供两个最基本的操作appendBuffer,remove。之后,就可以通过appendBuffer直接将 ArrayBuffer 放进去即可。

其中,SourceBuffer 还提供了一个应急的方法abort()如果该流发生问题的话可以直接将指定的流给废弃掉。

音视频的 ArrayBuffer 通过 MediaSource 和 SourceBuffer 的处理直接将

资料:https://developer.mozilla.org/zh-CN/docs/Web/API/SourceBuffer

基于flv.js实现H5直播

flv.js 简介

flv.js是来自Bilibli的开源项目。它解析FLV文件传给原生HTML5 Video标签播放音视频数据,使浏览器在不借助Flash的情况下播放FLV成为可能。

flv.js 优势由于浏览器对原生Video标签采用了硬件加速,性能很好,支持高清。同时支持录播和直播去掉对Flash的依赖

flv.js 限制FLV里所包含的视频编码必须是H.264,音频编码必须是AAC或MP3, IE11和Edge浏览器不支持MP3音频编码,所以FLV里采用的编码最好是H.264+AAC,这个让音视频服务兼容不是问题。对于录播,依赖 原生HTML5 Video标签 和 Media Source Extensions API对于直播,依赖录播所需要的播放技术,同时依赖 HTTP FLV 或者 WebSocket 中的一种协议来传输FLV。其中HTTP FLV需通过流式IO去拉取数据,支持流式IO的有fetch或者stream由于依赖Media Source Extensions,目前所有iOS和Android4.4.4以下里的浏览器都不支持,也就是说目前对于移动端flv.js是有局限性的。

flv.js 原理

flv.js只做了一件事,在获取到FLV格式的音视频数据后通过原生的JS去解码FLV数据,再通过Media Source Extensions API 传递给原生HTML5 Video标签。(HTML5 原生仅支持播放 mp4/webm 格式,不支持 FLV)

vue + flv.js

//下载flv.js包

npm i flv.js -S

//引入flv.js包

import flv from 'flv.js'

//HTML部分

//script部分

//创建一个Player实例,它接收一个MediaDataSource(必选), 一个Config(可选) flvjs.createPlayer(mediaDataSource: MediaDataSource, config?: Config)

export default {

data() {

return {

player: null,

}

},

created() {

if (flv.isSupported()) {

this.player = flv.createPlayer({

type: 'flv',

isLive: true,

url: 'https://api.tjdataspace.com/flv.flv'

}, {

enableWorker: true,

enableStashBuffer: false,

stashInitialSize: 128,

}

);

}

},

mounted() {

this.player.attachMediaElement(this.$refs.myVideo);

this.player.load();

this.player.play();

setInterval(() => {

if (!this.player.buffered.length) {return;}

let end = this.player.buffered.end(0);

let diff = end - this.player.currentTime;

if (diff >= 1.5) { //延时如果大于1.5秒,就让直播跳到当前时间位置播放

this.player.currentTime = end - 0.5;

}

}, 3 * 60 * 1000);

},

} flv.js资料:https://www.npmjs.com/package/flv.js

参考资料:

https://segmentfault.com/a/1190000008916399

https://segmentfault.com/a/1190000010440054

https://blog.csdn.net/An1090239782/article/details/108972491

https://zhuanlan.zhihu.com/p/47773064

https://juejin.cn/post/6900540290432499725返回搜狐,查看更多

责任编辑:

以上内容为资讯信息快照,由td.fyun.cc爬虫进行采集并收录,本站未对信息做任何修改,信息内容不代表本站立场。

快照生成时间:2023-01-11 11:45:09

本站信息快照查询为非营利公共服务,如有侵权请联系我们进行删除。

信息原文地址:

实时多人互动音视频直播技术的应用
实时多人互动音视频直播技术是一种允许用户在不同地点进行实时音视频通讯的技术。这种技术广泛应用于在线教育、远程医疗、企业会议、社交娱乐等多个领域,为用户提供了便捷、高效的沟通方式。
2024-06-13 11:53:00
音视频激荡40年:从9英寸的黑白电视,到4.56亿人的直播狂欢
...“云”上的无限空间。从9英寸的黑白世界杯到4.56亿人的直播狂欢,从1948年的香农定理到2022年的Imagine Computing的天池大赛
2022-12-23 19:27:00
MSU世界视频编码器大赛放榜 腾讯编码器斩获全场最佳
...解码标准H.266/VVC的云厂商。2023年2月,Tencent266上线腾讯云直播,助力腾讯云成为业界首个支持266直播的云厂商
2023-07-25 13:00:00
破解版2023adobe软件及更新功能介绍
...Photoshop和Illustrator,可以帮助设计师实现人物动态化,在直播或录制动画中使用都非常方便。Animate2023Flash与Html5制作工具
2023-02-13 08:00:00
自主标准突破:营造“线上即现场”体验
...9月23日正式开幕,中国移动咪咕公司(以下简称咪咕)在直播赛事服务中首次实现业内移动端AVS3+HDR Vivid国产化标准融合规模化商用,真实感与沉浸感兼具的超高清视频应用
2023-09-25 02:31:00
36氪研究院 | 2023年中国实时音视频(RTC)行业洞察报告
早在2015年左右,直播和短视频的兴起带动人们信息消费的内容逐渐从文字向语音、视频信息转变,加之全民“宅家”时期人们居家生活娱乐习惯的养成,促使视频会议、在线教育、电商直播等实时
2023-05-30 08:12:00
视频平台为了留住你,有多努力?
...艾瑞咨询的数据也显示,TOP 100 的 App 中,搭载了点播、直播、实时通信三个最主流音视频功能的比例达到 69%。不仅视频数据量暴增,边视频边连麦、边看电影边发弹幕,或
2023-08-24 11:52:00
...的使用规范》(标准编号ETSI TS 101 154 v2.8.1)中。此次AVS3技术标准被纳入ETSI标准体系,是被DVB(数字视频广播)标准体系采纳后,鹏城实验室推动中
2023-08-07 08:02:00
快手出席中国多媒体大会:产学研合作共赢,迎接AGI时代新机遇
...优化自2011年成立至今,快手已经发展成为国民级短视频直播数字社区,在用户、内容、商业等方面保持良性增长态势。而快手社区生态的蓬勃发展,离不开快手长期的巨大投入,以大规模自研
2023-08-08 15:39:00
更多关于科技的资讯: