
场景一:自动播放
autoPlay 布尔属性;指定后,视频会立即自动开始播放,不会停下来等着数据载入结束。
视频自动播放可以在页面打开且资源加载足够的状况下使视频自动播放,减少一次客户点击的交互,同时可以应用在动效背景、H5仿视频通话的功能。不过鉴于各种因素,自动播放无论在PC端抑或移动端都有不同程度的限制。
移动端
IOS
早期应该应有用户手势(user gesture)video标签才可以播放; 从版本10开始设置了video的规则,苹果放宽了inline和autoplay,策略如下(仅适用于Safari浏览器):

安卓
早期同样必须用户手势才可以播放; 安卓的 ****chrome 53 后放宽了自动播放策略,策略不同于IOS的Safari,需要同时对 video 设置 autoplay 和 muted(是否禁音),才允许手动播放; 安卓的 FireFox 和 UC 浏览器支持任何状况下的手动播放; 安卓的其它浏览器暂时不知道状况;
PC端
早期是支持自动播放,但最近 Safari、Chrome 陆续设置了手动播放的策略……
Safari 浏览器

Safari 10 后带音频的视频跟音频默认禁止手动播放,更多信息可以参考这篇文章();
Chrome 浏览器
禁音的视频仍然可以播放,带声音的视频会按照媒体参加指数来决定是否自动播放,那什么是媒体参加指数?官方帮了解释跟相关的维度:
MEI 是一个评估客户对于当前站点的外媒参与程度的指数,它取决于下面几个维度:
用户在媒体上停留时间达到了 7秒以上
音频需要是展现出来,并且没有静音
与 video 之间有过交互
媒体的规格不大于 200×140.
检测是否自动播放?
好在无论是 Safari 还是 Chrome,在限制了自动播放的同时,提供了测试视频能否能自动播放的模式,以便于开发者在看到能够自动播放时有备选方案:
var promise = document.querySelector('video').play();if (promise !== undefined) { promise.catch(error => { // Auto-play was prevented // Show a UI element to let the user manually start playback }).then(() => { // Auto-play started });}
为什么早期禁止视频自动播放?

because it can be disruptive, data-hungry and many users don’t like it. (因为它是破坏性的、需要长期流量同时这些客户不喜欢它)
为什么又允许自动播放?
有些开发者使用其它形式如 canvas、gif 等来实现视频自动播放的效果,但是性能上、流量消耗上都远不如视频播放;
现在流量便宜了、手机软件越来越好了;
用户可以借助修改来禁止手动播放(开启省流量路径等);
为什么 IOS 下微信和钉钉可以手动播放带声音的视频?
确实看到在微信经常能看到自动播放的H5,但是作者自己写的设定了 autoplay、playsInline 的视频播放样例,在微信上仍然能够自动播放,而在钉钉上仍可以自动播放

通过查询资料手机浏览器 video标签,IOS WebAPP 开发都是基于 IOS 提供的浏览器内核进行研发的,所以在 WebAPP 的 webview 中可以设置手动播放的体现,钉钉明显是支持手动播放,微信则是禁止手动播放,但是提供了内置事件来支持手动播放:
微信下通过 WeixinJSBridgeReady 事件进行自动播放:
document.addEventListener( 'WeixinJSBridgeReady', function() { video.play(); }, false);
场景二:全屏处理

在移动端浏览器, video 在用户点击播放以及借助API video.play() 触发播放时,会强行以全屏置顶的方式进行播放,设计的想法或许是因为全屏能提供更好的客户体验,但有时候开发者希望可自己控制是否全屏从而推动其它需求。
playsinline 取消全屏
如果想实现不全屏播放,只需在video标签加个 playsinline 属性即可,这个属性在基于webkit内核的移动端浏览器基本没问题,实在不行就再加个 webkit-playsinline :
<video src={videoUrl} webkit-playsinline="true" playsinline="true" />
那么针对其它内核的浏览器要如何处理呢?这个之后要知道下至今市场上存在的浏览器有什么。
playsinline 兼容性
首先要知道全球目前四个浏览器内核:
微软IE的Trident
网景最初研发后卖给Mozilla基金会并演变成火狐的Gecko
KDE的开源内核Webkit
Opera的Presto
其中:

Trident在移动端主要为WP7系统内置浏览器
Presto 在所有联网设施上都使用,移动终端上主要为 Opera Mobile、OperaMini、欧朋浏览器以及欧朋HD Beta版
Webkit内核的适用范围则较为广泛,Android原生浏览器、苹果的Safari、谷歌的Chrome(Android4.0使用)都是基于Webkit开源内核开发的。
而中国常用的PC浏览器如UC浏览器、QQ浏览器、百度手机浏览器、360安全浏览器、谷歌浏览器、搜狗手机浏览器、猎豹浏览器以及移动端的UC、QQ、百度等电脑浏览器都是根据Webkit修改过来的内核,本质上我们可以觉得市场上移动端用户使用的基本上都是webkit内核以及基于 webkit 内核做更改的浏览器,所以 playsinline 的兼容性非常好!
场景三:播放控制
video 元素有提供多个行为事件供开发者控制视频播放,兼容性比较好的有 onended 、 ontimeupdate、onplay、onplaying 等,有些事件在不同浏览器不同设备上的的体现情况并不一致,
例如:ios 下’canplay‘(是否未缓冲了足够的数据可以顺畅播放),当加载时是不会触发的,即使__preload=”auto” __也没用,但在 pc 的 Chrome 调试器下,是会在加载阶段就触发。ios 需要播放后才能触发。
场景四:隐藏播放控件
controls 加上这个属性,Gecko 会提供用户控制,允许用户控制视频的播放,包括音量,跨帧,暂停/恢复播放。
controls 属性规定浏览器应该为视频提供播放控件,反之则隐藏播放控件,那么开发者可以自定义自己的播放控件。隐藏播放控件在 PC 端和 IOS 移动端兼容性良好,而在安卓移动端并不支持隐藏控件手机浏览器 video标签,不过还是可以借助一些方式来推动。
黑科技法
比较黑科技的方式是放大视频,把控件条移到视野之外,从而超过隐藏的效果!其实就是让视频元素比父容器还大,这样上面的控制条就会在父容器外面,然后父容器设置为:overflow:hidden, 实现隐藏播放控件的方式! 缺点是视频会被放大,需要提前留好空白供放大用。微信浏览器
腾讯的android团队的x5内核团队放开了视频播放的限制,视频不必定调用它们那种备受质疑的视频播放器了,利用x5-video-player-type=”h5″ **属性隐藏控件元素,同时视频不再置顶,允许其它元素浮动在顶层**。
总结
了解了视频播放的通用场景及常用的坑后,我们即使对于不同的场景提供对应的兜底方案能够提高客户体验效果。例如移动端自动播放的H5 页面,可以借助引导用户进行点击或者滑动来间接触发视频播放是很保守的做法,no bug!更好的方案是默认自动播放并捕捉禁止播放的状况,再引导客户进行交互实现视频播放。
使用 video 进行视频播放初期由于涉及至性能消耗大、流量消耗多或者进入客户体验等的考量,在移动端被限制得更严重,但是随着手机性能的提高、流量时代的到来、更强地场景需求,逐步放宽了限制,而PC端则渐渐从“宽松世代”走向“紧缩世代”,两者都有出于使客户有更好地感受的目的而不断更新自己的思路,未来可能会迈向一统,开发者就可以从底层兼容适配中传递出来,从而有更多地精力来做最上层的工作。
本文来自电脑杂谈,转载请注明本文网址:
https://www.pc-fly.com/a/bofangqi/article-143153-1.html
给他打个孔再放他走
想出名也不能介样吧
sorry