Open BlackHole1 opened 5 years ago
最终还是选择了第三种方案,但是原来第三种方案是有bug的,在重新设置时间时,不能设置成0。否则视频将直接跳转到后面。最终代码如下:
let flag = true
let mt = $("video");
mt.currentTime = 1e101;
mt.ontimeupdate = function() {
if (flag) {
mt.currentTime = 0.001;
flag = false;
}
}
第一种方案我个人总觉得有误差,而且要很多额外的计算步骤
第二种方案,目前只有chrome支持,所以暂时不考虑
第四种方案,会让程序多出很多不必要的步骤。原本就直接把流推到S3了,现在的话还要先保存到本地,再由本地进行ffmpeg
进行转码。再发到S3上,所以暂时也不考虑。
最终选择了第二种方案,项目本身不需要额外的变动,消费方去加上如上代码就好。
原本想的是通过chrome的PPAPI
来对chrome植入一个ffmpeg
,但是水平太菜,折腾不好。。
介绍
当我们使用
getUserMedia
、MediaRecorder
等API生成的webm
视频时,会发现最终的webm是无法拖动进度条的。除非使用FFmpeg
把webm转成其他格式的视频文件,或者等webm视频播放完后,就可以拖动了。分析
经过几个小时的排查,发现并不是
MediaRecorder
使用有问题,因为在网上找的其他demo生成的webm也都不行。一开始把分析点放在了进度条那里,结果在网上没有搜到任何相关文章,尝试了各种关键词都不行。
后来想到,可以使用
FFmpeg
来对视频文件进行分析。于是使用ffprobe rebirth-demo.webm
命令进行分析:关键点来了,可以发现其中:
Duration
和bitrate
的值都是N/A
,这是不正常的,于是去搜一下webm duration
,果然网上有很多的说明文章。大体意思是,因为
getUserMedia
、MediaRecorder
在生成webm时,并没有提供相关Duration
和bitrate
。导致出现这种问题。解决方案
一、计算视频长度,分配给
blob
这种方法的核心就是,在
start
开始录制时,记录一个开始时间,然后在stop
停止录制后,把当前时间与记录的开始时间相减,在把时间赋值给blob
来解决这个问题。相关解决方案可见:fix-webm-duration二、通过给audio标签一个很大的时间
在播放webm视频时,可以动态的给audio一个很大的时间,来解决这个问题,但是目前只针对
chrome
有效。相关解决方案可见:How can I add predefined length to audio recorded from MediaRecorder in Chrome?三、跳到结尾,再跳到开头
因为上文说过,当视频播放完后,就可以拖动了,那么只需要通过
JS
来控制当前的视频位置就可以解决了。相关解决方案可见:hello-its-me四、通过ffmpeg来解决
第一个解决的命令如下:
ffmpeg -i rebirth-demo.webm xixi.webm
,但是这个命令会很漫长,不太推荐。30秒的视频,需要花费3分钟左右的时间。第二个命令是:
ffmpeg -i rebirth-demo.webm -vcodec copy -acodec copy new_rebirth-demo.webm
。这个十分的快,因为本身是直接复制,而不是转化:可见已经没有问题了
总结
我个人倾向于最后一种,因为前面几个方法并没有实际性解决这个问题。
目前chrome团队不认为这是一个BUG。之前社区也讨论过。
社区讨论地址:https://bugs.chromium.org/p/chromium/issues/detail?id=642012