首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >flv.js怎么用?全面解读flv.js代码

flv.js怎么用?全面解读flv.js代码

作者头像
smy
发布2019-01-07 16:21:34
7.6K0
发布2019-01-07 16:21:34
举报
文章被收录于专栏:smysmy

flv.js项目的代码有一定规模,如果要研究的话,我建议从demux入手,理解了demux就掌握了媒体数据处理的关键步骤,前面的媒体数据下载和后面的媒体数据播放就变得容易理解了。

先普及点背景知识,为什么HTML5视频播放要用 flv 格式?

因为Flash。我标题图片用的是“flash RIP”,flash快死了,但是它的影响力还在,flash技术是过去10多年的互联网视频基础技术,大量相关基础设施都是围绕Flash构建的,比如 CDN 普遍支持的 RTMP 和 flv over http协议。做互联网直播的公司为了能兼容Web上的Flash播放,不约而同地选择了flv的媒体格式。在从Flash到 HTML5过渡的时期,如果HTML5能支持flash的协议是再好不过了,可以平滑过渡,然而HTML5并不原生支持flash协议。flv.js这个项目解决了HTML5支持flash协议的问题,这就是flv.js应运而生短期爆红的历史背景。

flv.js 中的demux就是一套 FLV 媒体数据格式的解析器,如果要理解FLV格式,下面的文档是必须熟读的。 Adobe官方的flv格式说明 http://www.adobe.com/content/dam/Adobe/en/devnet/flv/pdfs/video_file_format_spec_v10.pdf

flv.js怎么用? 下面进入正题,flv.js代码解读:demux部分

打开代码 https://github.com/Bilibili/flv.js/blob/master/src/demux/flv-demuxer.js

    static probe(buffer) {
        let data = new Uint8Array(buffer);
        let mismatch = {match: false};
        // 0x46 0x4c 0x56 这几个数字其实就是 'F' 'L' 'V' 的ascii码,表示flv文件头
        // 0x01是flv格式的版本号,用这来检测数据是不是 flv 格式。
        if (data[0] !== 0x46 || data[1] !== 0x4C || data[2] !== 0x56 || data[3] !== 0x01) {
            return mismatch;
        }

        ...

        let offset = ReadBig32(data, 5);

        if (offset < 9) {
            return mismatch;
        }

        return {
            match: true,
            consumed: offset,
            dataOffset: offset,
            hasAudioTrack: hasAudio,
            hasVideoTrack: hasVideo
        };
    }

0x46 0x4c 0x56 这几个数字其实就是 'F' 'L' 'V' 的ascii码,表示flv文件头,后面的0x01是flv格式的版本号,用这来检测数据是不是 flv 格式。

// 取出第五个字节,它的第六 和 第八 bit 分别表示是否存在 音频和视频数据,其它位是保留位可以忽略。
// 4二进制为:00000100
// 1二进制位:00000001
let hasAudio = ((data[4] & 4) >>> 2) !== 0;
let hasVideo = (data[4] & 1) !== 0;

这个probe是被 parseChunks 调用的,当读取了至少13个字节后,就判断下是否是一个flv数据,然后再继续后面的分析。为什么是13,因为flv的文件头就是13个字节,参考 上面 PDF里的 “The FLV header”,这13个字节包括了后面的一个四字节的size,这个size表示前一个tag的大小,但是由于第一个tag是不存在前一个的,所以第一个size总是 0。取出第五个字节,它的第六 和 第八 bit 分别表示是否存在 音频和视频数据,其它位是保留位可以忽略。

parseChunks 后面的代码就是在不断解析 tag,flv把一段媒体数据称为 TAG,每个tag有不同的type,实际上真正用到的只有三种type,8、9、18 分别对应,音频、视频和Script Data。

// 解析媒体tag,获取tag类型,只用到视频(0x08)、音频(0x09)、script data(0x12),对应着十进制8, 9 ,18
if (tagType !== 8 && tagType !== 9 && tagType !== 18) {
         Log.w(this.TAG, `Unsupported tag type ${tagType}, skipped`);
        // consume the whole tag (skip it)
        offset += 11 + dataSize + 4;
        continue;
}

tag header的格式为:UI 表示 unsigned int,后面的是bit数。这段代码就在判断tag type,注意看 那个 数字 11,因为tag header是11个字节,后面就是tag body了,所以offset加上这些偏移是为了跳到下一个tag的位置。

UI8 tag type
UI24 data size
UI24 timestamp
UI8 TimestampExtended
UI24 StreamID

你看是不是正好 11 个字节,adobe为了节约流量,能用24bit表示的绝不用32bit,但是还是给timestamp设置了一个 扩展位存放最高位的字节,这个设计很蛋疼,于是导致了下面这段奇葩代码,先取三个字节按照Big-Endian转换成整数再在高位放上第四个字节。

let ts2 = v.getUint8(4);
let ts1 = v.getUint8(5);
let ts0 = v.getUint8(6);
let ts3 = v.getUint8(7);

// ts3: 7xxxxxxx 00000000 00000000 00000000
// ts2: 00000000 4xxxxxxx 00000000 00000000
// ts1: 00000000 00000000 5xxxxxxx 00000000
// ts0: 00000000 00000000 00000000 6xxxxxxx
let timestamp = ts0 | (ts1 << 8) | (ts2 << 16) | (ts3 << 24);

解析完了 tag header后面分别按照不同的 tag type调用不同的解析函数。

switch (tagType) {
       case 8:  // Audio
              this._parseAudioData(chunk, dataOffset, dataSize, timestamp);
                    break;
       case 9:  // Video
              this._parseVideoData(chunk, dataOffset, dataSize, timestamp, byteStart + offset);
                    break;
      case 18:  // ScriptDataObject
              this._parseScriptData(chunk, dataOffset, dataSize);
                    break;
}

TAG type:8 音频

音频结构比较简单,AUDIODATA的第一个字节表示音频格式,其实基本都是 ACC 16bit 立体声 44.1kHz采样,所以最常见的数字就是 0xAF,后面一般就是 AACAUDIODATA了

TAG type : 9 视频

重点看的是视频,

let frameType = (spec & 240) >>> 4;

let codecId = spec & 15;

_parseAVCVideoPacket 用来解析 AVCVIDEOPACKET 结构,就是H.264的视频包这里取两个重要的值,frameType表示帧类型 1 是关键帧 2 是非关键帧,codeId是编码类型。虽然flv支持 六种视频格式,但是实际上互联网点播直播真正在用的基本只有H.264一种。所以codecId基本都是7。这里作者用了十进制的数,其实就是按位取值,用16进制的数会更好理解。

let packetType = v.getUint8(0);

let cts = v.getUint32(0, !le) & 0x00FFFFFF;

这里有个坑,参考adobe的文档,这是CTS是个有符号的24位整数,SI24,就是说它有可能是个负数,所以我怀疑flv.js解析cts的代码有bug,没有处理负数情况。因为负数的24位整型到32位负数转换的时候要手工处理高位的符号位和补码问题。(我只是怀疑,没有调试确认过,但是我在处理YY直播数据的时候是踩过这个坑的,个别包含 B frame的视频是会出现CTS为负数的情况的)解释下 CTS的概念,CompositionTime,我们前面在tag header里拿到过一个 timestamp,这个在视频里对应于DTS,就是解码时间戳,而CTS实际上是一个offset,表示 PTS相对于DTS的偏移量,就是 PTS和DTS的差值。

2.png
2.png

packetType有两种,0 表示 AVCDecoderConfigurationRecord,这个是H.264的视频信息头,包含了 sps 和 pps,AVCDecoderConfigurationRecord的格式不是flv定义的,而是264标准定义的,如果用ffmpeg去解码,这个结构可以直接放到 codec的extradata里送给ffmpeg去解释。

flv.js作者选择了自己来解析这个数据结构,也是迫不得已,因为JS环境下没有ffmpeg,解析这个结构主要是为了提取 sps和pps。虽然理论上sps允许有多个,但其实一般就一个。

let config = SPSParser.parseSPS(sps);

packetTtype 为 1 表示 NALU,NALU= network abstract layer unit,这是H.264的概念,网络抽象层数据单元,其实简单理解就是一帧视频数据。pps的信息没什么用,所以作者只实现了sps的分析器,说明作者下了很大功夫去学习264的标准,其中的Golomb解码还是挺复杂的,能解对不容易,我在PC和手机平台都是用ffmpeg去解析的。SPS里面包括了视频分辨率,帧率,profile level等视频重要信息。

NALU的头有两种标准,一种是用 00 00 00 01四个字节开头这叫 start code,另一个叫mp4风格以Big-endian的四字节size开头,flv用了后一种,而我们在H.264的裸流里常见的是前一种。

TAG type : 18 Script Data

除了音视频数据外还有 ScriptData,这是一种类似二进制json的对象描述数据格式,JavaScript比较惨只能自己写实现,其它平台可以用 librtmp的代码去做。

我觉得作者处理解决flv播放问题外,也为前端贡献了 amf 解析,sps解析,Golomb解码等基础代码,这些是可以用在其他项目里的。

在用传输协议获取了flv数据流后,用demux分离出音视频数据的属性和数据包,这为后面的播放打下了基础,从demux入手去读代码是个不错的切入点,而且一定要配合 flv file format spec一起看,反复多看几遍争取熟记在心。我现在已经可以从wireshark的抓包数据里人肉分析flv数据包了,对于debug相当有帮助。

以上就是flv.js怎么用?全面解读flv.js代码的详细内容,更多请关注php中文网其它相关文章!

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2019-01-03 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云直播
云直播(Cloud Streaming Services,CSS)为您提供极速、稳定、专业的云端直播处理服务,根据业务的不同直播场景需求,云直播提供了标准直播、快直播、云导播台三种服务,分别针对大规模实时观看、超低延时直播、便捷云端导播的场景,配合腾讯云视立方·直播 SDK,为您提供一站式的音视频直播解决方案。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档