关于视频录制的一些问题
录制的mp4格式的视频,会有加快倍率播放的现象
因为目前mp4格式的录制,是按照固定25FPS来录制的。所以如果直播流的fps 只有20,那么录制出来的视频在播放的时候,就会有加快倍率的现象。
录制的mp4格式的视频,为啥不支持音频数据。
目前mp4格式的文件,只支持AAC格式封装的音频。但是目前的直播流,音频一般都是G711格式的,所以目前mp4格式的录制,不支持音频数据。
虽然也有一些直播流,音频是AAC格式的,但是目前pro的音频解码是放wasm里面做的。所以处理起来会麻烦很多。所以暂不支持音频数据。
jessibuca-pro.js 和 jessibuca-pro-multi.js 的区别
jessibuca-pro-multi.js 内部是引用了jessibuca-pro.js,并且额外支持了多屏的需求。
所以如果只是单屏的需求,可以直接引用jessibuca-pro.js。
如果有多屏的需求,可以直接引用jessibuca-pro-multi.js。
同一时间只能引入一个js文件,不要同时引入
jessibuca-pro.js和jessibuca-pro-multi.js。
当引用了
jessibuca-pro-multi.js之后,由于jessibuca-pro-multi.js内部引用了jessibuca-pro.js,所以不需要再引用jessibuca-pro.js。
jessibuca-pro-multi.js文件会比jessibuca-pro.js文件大一些,因为jessibuca-pro-multi.js内部引用了jessibuca-pro.js,所以文件会大一些。
如果只是单屏的需求,可以直接引用
jessibuca-pro.js,文件会小一些。
jessibuca-pro.js提供的全局对象
window.JessibucaPro ;
window.JbPro;
window.WebPlayerPro;
jessibuca-pro-multi.js提供的全局对象
window.JessibucaPro ;
window.JbPro;
window.WebPlayerPro;
window.JessibucaProMulti;
window.JbProMulti;
window.WebPlayerProMulti;
decoder-pro-simd.js 与 decoder-pro-f-simd.js 的区别
decoder-pro-simd.js 是基于安卓搞的的simd解码器,decoder-pro-f-simd.js 是基于ffmpeg的simd解码器。
目前经过大量的测试,发现两个在在解码性能上面差别不是很大,主要是在兼容性上面,总体来说
decoder-pro-f-simd.js更好一些。
但是有些流的解码出来的数据,
decoder-pro-f-simd.js是直接花屏/绿屏,而decoder-pro-simd.js是直接不返回这一帧的解码出来的yuv数据,所以在这种情况下,decoder-pro-simd.js更好一些。
具体使用哪个,可以根据自己的业务需求来选择。
打包需要支持es5
目前的打包配置是只支持es6的
如果需要支持es5
修改 package.json
{
"browserslist": [
"last 1 version",
"> 1%"
]
}
JbPro container has been created and can not be created again 错误
如果出现这个错误,说明container已经被创建了,不能重复创建。
一般这个报错,是出现在销毁播放器之后,又重新创建播放器的时候。
destroy 是个promise,需要等待播放器内部的资源全部销毁之后,才能重新创建。
const player = new window.JessibucaPro({
container: dom,
})
重建播放器的正确姿势
//
player.destroy().then(() => {
// 销毁完成之后,才能重新创建
const player = new window.JessibucaPro({
container: dom,
})
})
或者
// 或者
await player.destroy();
const player = new window.JessibucaPro({
container: dom,
})
关于如何配置使用wasm、wasm(simd)多线程解码
localhost
不限制 http或者 https协议
需要在线申请一个origin trial token https://developer.chrome.com/origintrials/?utm_source=devtools#/view_trial/303992974847508481
然后配置到index.html中
<meta http-equiv="origin-trial" content="your origin trial token">
服务器
需要https协议下。否则无法使用。
需要在服务器上配置cross-origin-isolated头
以node 为例
app.use((req, res, next) => {
res.setHeader('Cross-Origin-Opener-Policy', 'same-origin')
res.setHeader('Cross-Origin-Embedder-Policy', 'require-corp')
next()
})
nginx 配置
add_header Cross-Origin-Opener-Policy same-origin;
add_header Cross-Origin-Embedder-Policy require-corp;
wasm编译打包 之后报:uncaught referenceError:module is not defined
一般是因为wasm没有编译成功,导致的。
检查下有没有严格按照 wasm编译打包 执行。
小窗口模式下画面出现锯齿状花纹
这种一般是出现在播放器拉伸等逻辑,所以才会出现这个的
只需要配置videoRenderSupportScale:false,isResize:true就行了。
不触发拉伸逻辑就不会有问题了。
配置了pauseAndNextPlayUseLastFrameShow:true,但是在暂停的时候,暂停的画面会拉伸下展示。
检查下播放器内部的video标签的object-fit属性是否被业务层给锁死了。因为最后一帧画面是通过object-fit来实现的。
video {
object-fit: contain !important;
}
如果业务层配置了参数isResize: false的话,播放器内部是通过设置video的object-fit属性来实现的。
会设置video的object-fit属性为contain。
video.style.objectFit = 'contain';
如果业务层直接锁死了object-fit属性,导致video 还是按照object-fit属性来展示的话,就会出现暂停的时候,画面会拉伸的现象(因为最后一帧画面会按照objectFit = 'contain'显示)。
关于播放Hls直播流的时候,画面会有卡顿现象
检查下Hls的ts/mp4单个文件的时长,如果时长超过5s的话,会触发播放器内部的低延迟控制,导致画面卡顿。
一般来说,直播流的ts/mp4文件时长都是2s左右的。
解决方案:设置 videoBufferDelay:10 即可。
在调用录制视频的时候,UI上面显示的时间会发生跳跃,不是匀速变化的
这是由于流的码率不稳定导致的。比如第一秒来的数据量是1s,这个时候UI上面显示的也是00:00:01,但是下一秒只来了0.5s的数据量,这个时候UI上面还是会显示00:00:01,然后下一秒来了1.5s的数据量,这个时候UI上面显示的就是00:00:03了。
这个一般会在回放流的时候出现,因为回放流的码率是不稳定的。直播流的码率相对比较稳定。
网络不好的情况下,当播放器还没有完成初始化的时候,就调用的销毁播放器的方法,然后再次创建播放器,这个时候会导致decoder初始化失败。
这是因为加载decoder worker的时候,网络不好,导致decoder worker加载失败,但是播放器已经销毁了,再次创建播放器的时候,decoder worker还是加载失败的。
目前播放器内部还没有啥好的解决方案,所以需要业务层自己处理。
解决方案:等待播放器初始化完成之后,再销毁播放器。
if(jessibuca._hasLoaded()){
jessibuca.destroy().then(() => {
// 重新创建播放器
jessibuca = new window.JessibucaPro({
container: dom,
});
jessibuca.play('new url');
});
}
else{
jessibuca.on('load',()=>{
jessibuca.destroy().then(() => {
// 重新创建播放器
jessibuca = new window.JessibucaPro({
container: dom,
});
jessibuca.play('new url');
});
})
}