另类投资公司网站建设规定,超市微信小程序怎么做,谷歌镜像网站怎么做,泉州做网站优化的公司本期作者 背景 Matroska是一种开放标准、功能强大的多媒体封装格式#xff0c;可容纳多种不同类型的视频、音频及字幕流#xff0c;其常见的文件扩展名为.mkv、.mka等。与应用广泛的MP4相比#xff0c;Matroska更加灵活开放#xff0c;可以同时容纳多个字幕#xff0c;甚至…本期作者 背景 Matroska是一种开放标准、功能强大的多媒体封装格式可容纳多种不同类型的视频、音频及字幕流其常见的文件扩展名为.mkv、.mka等。与应用广泛的MP4相比Matroska更加灵活开放可以同时容纳多个字幕甚至可以包含章节、标签等信息成为了许多用户的偏爱。B站Web投稿页上传的所有视频中封装格式为Matroska的视频占比超过2%是除MP4以外占比最高的格式。
Web投稿页作为稿件生产的第一个环节在获取到用户上传的视频后会根据视频内容为用户投稿提供辅助其中包含 获取视频元信息为快速转码提供预分析缩短转码等待时间同时为页面其他功能提供视频的基本数据。 获取视频抽帧画面对视频画面进行计算根据计算结果进行AI智能推荐及自动填写如封面推荐、分区推荐等为用户填写稿件信息提供辅助。
而这些内容的实现都基于对视频文件的解析其中又包含了解封装和解码两个部分。 通用方案 此前Web投稿页的实现方案为使用Emscripten将FFmpeg编译为WebAssembly后在Web平台运行借助FFmpeg的音视频处理能力来进行解封装和解码。这种方案的优点是支持的视频格式齐全可以解析几乎所有视频格式但其缺点也很明确——解析速度慢无法使用硬件加速性能不佳内存消耗大甚至可能导致页面崩溃。 升级方案 针对MP4格式视频的解析Web投稿页已经实现了方案升级改为使用mp4boxhttps://www.npmjs.com/package/mp4box进行解封装然后结合WebCodecs API进行解码方案升级后获取视频信息和视频画面效率提高了70%。Matroska格式是除MP4以外占比最高的格式在Web投稿始终占据着一席之地对其解析方案进行改造升级势在必行。使用WebCodecs API进行解码实现起来并不复杂已有诸多成熟的实践需要着重解决的问题就是如何对Matroska视频进行高效解封装。 技术调研 Matroska简介 Matroska是一种多媒体封装格式是EBML在多媒体领域的应用。EBML是一种八位位组对齐的二进制格式由一系列Elements元素组成各个Element可顺序排列可层层嵌套能够灵活地表示和存储各种数据。而EBML中的所存储的具体数据内容随着EBML文件类型的不同而不同由文件类型所定义的EBML Schema来确定详见附录1。Matroska继承了EBML的层级化结构在EBML基础上定义了一套独特的Schema模式以实现其强大的功能和特性详见附录2。
从宏观结构上看Matroska文件仅由两个主要的Element组成EBML Header和 Segment而Segment中又存储着8个可能的Element称为Top Element。其中 SeekHead对Matroska解析非常重要其内部包含了其他Top Element的位置索引可用于方便快速搜索需要的信息比如从Info、Tracks中获取视频的元信息从Cues、Cluster获取具体的视频数据详见附录3。 从微观组成上看无论是EBML Header、Segment还是SeekHead等等Matroska中的每个Element都是标准的EBML Element有着确定的解析方式。 由此遵循Matroska特定的EBML Schema结构按照EBML Element的组成和编码方式进行逐个解析即可对整个Matroska文件的内容进行读取。 相关开源项目 在MDN文档的WebCodecs API部分可以看到文档中提及了一些对视频进行解封装的开源项目对于MP4格式的文件可以使用mp4box来进行解封装对于WebM文件则可以使用jswebmhttps://www.npmjs.com/package/jswebm。 WebM是一种基于Matroska的多媒体封装格式其规范与Matroska规范基本一致只是对视频编码和音频编码作出了一些限制见附录4。jswebm在解析过程中对文件的音视频编码进行了判定如果不符合则抛出错误。如果将这部分判定功能进行忽略jswebm是可以同时解析Matroska、WebM文件的。
jswebm使用起来非常简单相关代码如下
const demuxer new JsWebm();
demuxer.queueData(buffer);
while (!demuxer.eof) {demuxer.demux();
}
console.log(demuxer);
console.log(total video packets : ${demuxer.videoPackets.length});
console.log(total audio packets : ${demuxer.audioPackets.length}); 而细读源码可以发现其工作方式非常简单明了就是顺序暴力读取
1.文件读取层面 将整个文件的ArrayBuffer传入SDK支持将文件一次性完整传入也可进行切片顺序传入按照传入的方式将文件内容按顺序存储在列表中 对存好的ArrayBuffer列表从头分片读取分片大小和数量与传入时一致 内容解析过程中如果当前分片已用尽则继续读取下一个分片直到完成整个文件的解析。
2.内容解析层面 首先读取EBML Header中的内容然后获取到Segment部分按照各个Top Element在Segment部分中的实际存储顺序用递归的方式顺序解析 根据Element Id的不同对各个Element Data采用不同的解析方式并对解析结果进行存储
初步使用下来从功能上来讲我们想要的信息jswebm最终的确都能获取到但想要在生产环境进行使用有几个关键的问题不可忽略 jswebm的文件读取方式决定了它内存占用极大相当于整个视频文件都要读取到内存中且浏览器对转换为ArrayBuffer的文件大小有限制对于较大的视频文件转换会直接失败 只能对整个文件进行完整解析而实际使用时并不需要整个文件的完整信息效率低 API不完善没有提供诸如获取视频元信息、获取某个时间点的视频帧数据等常用方法需要根据解析后吐出的结果来进行二次复杂运算 错误处理比较粗糙视频文件有异常时解析过程无法正常抛出错误
因此直接使用jswebm来对视频进行解析并不可行无法满足Web投稿的实际需要。 方案实现 方案设计 Web投稿页对视频的解析需要在较短的时间内完成这样才能确保计算结果能够及时曝光给用户能够给用户投稿提供有效的帮助。这个过程中内存的占用是非常重要的指标如果内存占用过大引发页面崩溃则会打断投稿流程。实际生产环境使用时有以下诉求 内存占用不能过大需要进行有效控制不能随着视频文件大小的增大而线性增大 提高解析效率缩短解析时间 提供API单独获取视频元信息 提供API获取某个时间点的视频帧数据后续可结合WebCodecs API进行解码
因此需要设计更加灵活、更加高效的工作流打造更高性能、更实用的Matroska解封装SDK。
针对Web投稿页的实际诉求主要进行以下设计
1.数据读取层面 直接传入文件的引用地址不需要预先转换为ArrayBuffer 从头开始读取文件对当前读取位置进行记录根据传入的分片大小配置及当前位置动态获取当前位置的ArrayBuffer分片 除了可以从头顺序读取文件外还允许从给定的文件位置开始读取记录读取位置并获取分片 内容解析过程中如果当前分片已用尽则更新当前读取位置重新获取新的分片直到完成整个文件的解析
2.内容解析层面 读取EBML Header中的内容获取Segment部分优先解析Segment中SeekHead的内容记录各个Top Element在文件中的的实际位置 提供API允许直接获取视频元信息或视频帧数据。根据所调用API的不同去解析文件的不同部分 如果需要获取视频元信息则根据SeekHead中记录的位置直接去解析Tracks和Info部分 如果需要获取视频帧数据则根据SeekHead中记录的位置直接去解析Cues和Cluster部分 根据Element Id的不同对各个Element Data采用不同的读取方式并对解析结果进行存储 定义解析过程中的通用错误类型补充异常场景的错误抛出
根据Web投稿的实际应用需求实现三个功能模块分别进行文件预处理、视频基础信息获取、视频帧数据获取。各个模块之间存在一定的依赖关系会对前置模块的运行结果进行校验。例如获取视频基础信息时会使用到文件的索引信息因此会预先检查文件是否完成了预处理工作。 每个功能模块内部又包含着一些子功能来对视频文件进行不同的处理和分析
1、文件预处理 文件初始化用于接收文件按照传入的参数设置文件读取时的每个分片大小。分片大小可以根据实际需要来进行合理设置当设置的分片大小过大时文件分片会占据较大的内存当设置的分片大小过小时会频繁触发文件分片的动态获取对解析耗时产生影响。 解析文件索引信息获取文件的Segment元素优先搜索Segment中的SeekHead元素对SeekHead中的内容进行解析读取获取Segment中各个Top Element的索引位置并进行存储。
2、视频基础信息获取 获取视频元信息根据SeekHead中所记录的Tracks和Info的位置对两者进行解析获取视频宽、高、视频编码、音频编码等信息。
3、视频帧数据获取 获取全部视频帧数据根据SeekHead中所记录的Cues和Cluster的位置对两者进行解析获取视频所有帧数据及是否是关键帧等信息。 获取某时间点视频帧数据根据SeekHead中所记录的Cues的位置对其进行解析计算与所需时间点最接近的关键帧存储位置和时间索引根据关键帧存储位置对视频帧数据进行解析和输出。
新的方案中SDK的工作方式和代码逻辑改变很大因此需要另起炉灶创建新的SDK——mkv-demuxerhttps://www.npmjs.com/package/mkv-demuxer。
mkv-demuxer重点解决了内存问题优化了解析过程中的异常处理并提供了几个有用的API基本满足了Web投稿页的应用需求。 使用方式 mkv-demuxer的使用非常简单首先创建一个解封装器实例将文件进行传入配置解析时的分片大小然后根据实际需要调取相应的API即可。
import MkvDemuxer from mkv-demuxer
const demuxer new MkvDemuxer()
const filePieceSize 1 * 1024 * 1024
await demuxer.initFile(file, filePieceSize)
const meta await demuxer.getMeta()
const data await demuxer.getData()
const frame await demuxer.seekFrame(10) 其中getMeta可以获取视频文件基本的容器信息以及视频轨道、音频轨道的编码信息返回的内容的格式为
{info: {duration: 10000,muxingApp: Lavf58.47.100,...},video: {codecID: V_VP9,width: 1280,height: 720,...},audio: {codecID: A_OPUS,channels: 2,rate: 48000,...},
} getData可以获取到视频轨、音频轨的所有数据packet信息包含每个packet在文件中的位置、所在时间戳。同时cues中存储了视频所有关键帧的时间戳和相对位置信息可与其他信息结合得到关键帧在文件中具体位置。getData所返回内容的格式为
{cues: [{cueTime: 50,cueTrackPositions: {cueClusterPosition: 660,cueRelativePosition: 2539,cueTrack: 1,},},...],videoPackets: [{end: 3311,isKeyframe: true,keyframeTimestamp: 0.05,size: 51,start: 3260,timestamp: 0.05,},...],audioPackets: [{end: 1998,size: 1273,start: 725,timestamp: 0.001,},...],
}; seekFrame可以根据给定的时间戳返回最接近该时间戳的关键帧数据信息所返回的内容为
{end: 3311,isKeyframe: true,keyframeTimestamp: 0.05,size: 51,start: 3260,timestamp: 0.05,
}; 性能表现 对于改造前后两个SDK的性能表现可以抽取不同的视频进行测试验证改造效果。经过多次测试和对比发现改造后内存占用大大减小不再受到视频本身体积的影响能够平稳保持在较低水平解析视频速度大大提高基本都能在一秒内完成。尤其对于高分辨率、大体积的视频文件使用两个SDK进行解析时性能表现差异极大优化效果最为明显。
以一个4K视频为例其基本信息如下 属性名 值 视频大小 1.61G 视频编码 VP9 分辨率 3840x2160 码率 10023 kb/s 对改造前后的内存占用变化及解析视频时间进行记录可以得到如下结果 改造后内存占用减少了98.34%解析视频时间减少97.21%。改造后的mkv-demuxer性能表现良好可以在生产环境进行使用。 Web投稿实际应用 Web投稿页在获取到用户上传的视频后会分别获取视频元信息和视频抽帧画面用以计算推荐封面和推荐分区推荐结果获取的速度对用户体验有着直接的影响。 推荐封面的获取从视频中截取至多30张低清截帧画面对低清图片进行AI打分基于打分结果排序重新截取10张高清截帧画面作为推荐封面 推荐分区的获取从视频中均匀截取10张截帧画面对截帧画面进行打包上传压缩包等待AI计算将计算结果作为推荐分区 将Matroska视频的截帧方案进行升级使用mkv-demuxer完成解封装调用WebCodecs API对视频帧数据进行高性能解码再结合WebGL以更快的速度绘制截帧画面当用户投递Matroska视频时获取到推荐封面和推荐分区的速度会变快。当视频无法解析或浏览器不支持WebCodecs API时则会自动降级为旧方案因此成功率不会受到影响。 数据结果 将升级方案与通用的FFmpegWebAssembly方案进行对比可以得到如下结果 视频画面截帧过程耗时缩短在80%以上视频分辨率越高效果越明显 推荐封面获取总耗时减少2.29s缩短了16.93% 推荐分区获取总耗时减少8.13s缩短了21.36%
具体数据如下
推荐封面获取总耗时 推荐分区获取总耗时 由于推荐封面总流程和推荐分区获取总流程中除了画面截帧还包含了许多其他步骤且受限于WebCodecs API的兼容性实验组用户中很大比例的用户最终使用的还是旧版降级方案因此与本地进行的截帧性能测试数据相比耗时减少的效果得到了一定的稀释。但整体来说新的方案对用户投稿体验的改善是比较可观的且随着未来WebCodecs在Web平台的逐渐兼容优化效果会越加明显。 后续规划 基于Web投稿页的实际运作需求以及mkv-demuxer现有的解析能力可以规划如下优化策略
一、针对Web投稿页上的Matroska视频可以利用mkv-demuxer的解封装能力优化视频边传边转流程。在这一过程中mkv-demuxer能够更加快速地获取视频帧数据并进行逐帧遍历精确计算视频的比特率、大小等关键数据。将这些信息更早地同步至视频云可以加速视频转码的整体流程提升用户体验。
二、进一步提升mkv-demuxer的解析能力完善对Matroska格式的全面支持。通过增加对Tag、Attachments等内容的解析能力兼容对EBML Stream的解析可以更全面地解析Matroska文件提取更多有用的信息。 相关资料 EBML相关 https://datatracker.ietf.org/doc/html/rfc8794 https://docs.racket-lang.org/ebml/index.html
Matroska相关https://www.matroska.org/index.html
WebM相关 https://www.webmproject.org/ https://cloudinary.com/guides/video-fomats/webm-format-what-you-should-know
工具推荐 Hex Fiend MKVToolNix
项目地址及npm包 github仓库https://github.com/SuperYanjun/mkv-demuxer npm包https://www.npmjs.com/package/mkv-demuxer 附录 1. EBML的结构 EBML文件仅由两个部分组成EBML header和 EBML body。EBML必须以EBML header开头用以声明如文件类型、编写/读取EBML所需版本等重要信息提供对EBML body处理方式的声明。而EBML body中的内容随着EBML文件类型的不同而不同又包含很多其他的EBML Element。 2. Matroska基于EBML的限制 Matroska本身是基于EBML的只是在通用的EBML基础上制定了Matroska独特的EBML Schema同时做出了一些规定和限制 EBML Header中的DocType值必须是matroskaEBMLMaxIDLength必须是4EBMLMaxSizeLength必须为18 至少包含一个EBML Document更复杂的Matroska可包含多个EBML Document形成EBML Stream 每个EBML Document必须以EBML Header开始随后跟着一个Segment 存在8个可能的顶级Top Element 3. Matroska的Top Element Matroska不同的Top Element存储了文件的不同内容 SeekHead包含了其他Top Element的位置索引由于Matroska对8个Top Element的位置顺序没有进行规定如果没有位置索引想要寻找其中某个元素则需要对整个文件进行搜索。 Info包含了Segment内容的整体信息如标题、时长等。 Tracks包含了每个轨道的信息如轨道类型、分辨率、采样率、编码等。 Chapters包含了所有章节内容有了章节划分便可以在视频中进行跳转。 Cluster包含了每个轨道的具体数据内容每个Cluster中包含了至少一个SimpleBlock或BlockGroup元素存储了视频具体的数据信息每个Cluster都包含一个时间戳用于表明该Cluster中第一个元素的播放开始时间这种组织形式有利于对视频数据进行查找和进行错误恢复。 Cues用于播放时进行时间索引每个Cues元素都包含至少一个CuePoint元素用于存储该索引下BlockGroup或SimpleBlock的位置。 Attachments用于为Matroska文件增加附件如图片、字体、网页等。
Tags包含了对文件的描述数据和额外信息如歌手、流派、评论、导演等。 4. WebM与Matroska的区别 WebM由Google推出目标是构建一个开放的、免费的视频格式。WebM在互联网中使用非常方便因为它通常压缩率高体积较小使得共享和传输媒体内容变得更加容易也节省了存储空间。WebM是基于Matroska多媒体容器格式进行开发的所不同的是WebM对视频编码和音频编码作出了一定限制并且定义了新的DocType的值 视频编码必须是VP8或VP9 音频编码必须是Vorbis或Opus EBML Header中的DocType必须是webm
