使用wfs.js库播放音视频

最新推荐文章于 2025-05-26 16:53:33 发布

转载最新推荐文章于 2025-05-26 16:53:33 发布 · 3.8k 阅读

3 ·

CC 4.0 BY-SA版权

原文链接：https://blog.youkuaiyun.com/jacke121/article/details/88067078

文章标签：

#html5 #javascript #视音频

视音频专栏收录该内容

1 篇文章

订阅专栏

本文探讨了桌面虚拟化在移动端的低延时直播实现，对比分析了RTMP、HLS等传统流媒体方案，重点介绍了使用MSE扩展实现HTML5 video tag的流式直播方案，通过优化延时、解码、画面旋转等问题，实现了100ms以内的延时效果。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

use html5 video tag with MSE for h264 live streaming

本编博客记录桌面虚拟化移动端预研。

完整demo： https://github.com/MarkRepo/wfs.js

常见的直播方案有RTMP RTSP HLS 等等，由于这些流都需要先传输到服务器，然后进行推流，延时比较大，RTMP可以优化到1s，hls延时最高，大概10s左右。

虚拟桌面要求延时能在100ms以内。经过google查找资料发现有以下几种方案可以实现：

1. 用websocket 传输h264编码数据，在浏览器中使用broadway开源库进行解码，调用html5 canvas绘制图像。在github上有一个demo，经过测试，broadway解码效率不高。（测试环境 chrome book）

参考： https://github.com/131/h264-live-player

2. 使用webRTC 进行点对点直播，找了一个demo，搭建了一个聊天室测试，延时效果大概在500ms左右，应该可以优化。webRTC的接口封装的很好，只有三个接口。

demo: https://github.com/LingyuCoder/SkyRTC-demo 参考:https://segmentfault.com/a/1190000000436544

上面的demo有一个地方需要注意：使用http服务无法获取到视频流，浏览器报错，提示需要https服务。改成https服务之后，测试成功。

这个方案可行，但是需要自己去改webRTC的源码，工作量比较大，所以没有采用。

3. 使用MSE（Media Source Extension, 具体参考W3C标准）扩展实现 HTML5 video tag的流式直播。（最终采用的方案）

方案描述：使用websocket 从服务端传输h264编码数据到浏览器，在浏览器端使用JS 解析h264数据，封装成fMP4 fragment, 喂给media source 中的sourceBuffer，浏览器video tag自动获取sourceBuffer中的数据进行解码渲染。

最后实现的demo体验效果良好，延时能达到100ms以内，使用笔记本软解、硬解， chrome book 软解表现都很完美，唯独chrome book 硬解会缓冲一帧数据，是一个瑕疵，不过这个缺点可以在服务器端多发一帧数据解决。（见后文）

下面主要记录预研过程中出现的重要问题和解决方案：

（1）解析h264数据，封装fMP4 fragment。

　　这一步比较复杂，由于之前没有JS开发经验，没有选择自己写，在github找了一个开源实现。参考：https://github.com/ChihChengYang/wfs.js；根据wfs.js搭建的直播方案，主要出现三个问题（只有第一个延时是wfs.js库的问题，其余是自己的问题）：

（2）第一个是延时问题，延时很大，在3~5s左右

原因有两个： 1. wfs.js库中做了缓存，收到一定的数据之后才执行fMP4 fragment的封装。

　　　　　　 2. chrome浏览器的解码器默认不是以直播流的模式解码视频帧，所以会在解码的时候缓存4帧数据。

解决方法： 1. 把wfs.js库中的缓存去掉，每来一帧数据都执行fMP4 fragment的封装

　　　　　　2. 设置mvhd.duration = 0，如果有mehd的话，设置mehd.fragmentDuration = 0，这样chrome 会进入“low delay mode”，不会缓存数据。

具体参考： https://stackoverflow.com/questions/36364943/frame-by-frame-decode-using-media-source-extension

　　　　　 https://bugs.chromium.org/p/chromium/issues/detail?id=465324

（3）第二个就是解码问题，解码花屏

原因：虚拟机spice服务端使用了websokify代理（python 写的）。首先，这个代理服务器是流式的（出现数据帧被分割和合并的现象），浏览器端js没有进行数据帧边界的解析；第二，代理缓冲区过小，导致数据帧被分割传输。

解决方法：1. 修改websokify代理的接收缓冲区大小。

　　　　 2. 在wfs.js库中对收到的数据进行解析，一帧一帧的提交数据，封装fMP4 fragment。

（4）第三是屏幕倒转问题

原因： spice服务端发过来的h264数据就是倒的，在终端平台，是由终端处理的。

解决方法：利用css的画面旋转功能，以x轴为旋转轴，旋转180度。如：

（5）关于chrome book硬解码缓存一帧问题解决办法

通过看chrome源码 decoder部分，发现decoder处理几个数据类型会直接flush缓冲区，所以可以在wfs.js每收到一帧数据，

就构造一帧这种类型的空数据，喂给video tag，把缓冲的一帧flush出来，同时把播放时间缩短一半即可（否则会帧堵塞）。示例：

var copy2 = new Uint8Array(4);
copy2[0] = 0, copy2[1] = 0, copy2[2] = 1, copy2[3] = 10; //类型10,11 都可以，但是10可以兼容软解　　　　　
this.wfs.trigger(Event.H264_DATA_PARSING, {data: copy2});