标签是不支持 HLS（m3u8）协议的，因为 已经支持 HLS（m3u8）播放协议了。但直播观看不推荐使用 HLS（m3u8）协议，延迟要比 RTMP 和 FLV 协议高一个数量级。
live 模式主要用于直播类场景，例如赛事直播、在线教育、远程培训等等。该模式下，小程序内部的模块会优先保证观看体验的流畅，通过调整 min-cache 和 max-cache 属性，您可以调节观众（播放）端所感受到的时间延迟的大小，文档下面会详细介绍这两个参数。
RTC 则主要用于双向视频通话或多人视频通话场景，例如金融开会、在线客服、车险定损、培训会议等等。在此模式下，对 min-cache 和 max-cache 的设置不会起作用，因为小程序内部会自动将延迟控制在一个很低的水平（500ms左右）。
这两个参数分别用于指定观看端的最小缓冲时间和最大缓冲时间。所谓缓冲时间，是指播放器为了缓解网络波动对观看流畅度的影响而引入的一个“蓄水池”，当来自网络的数据包出现卡顿甚至停滞的时候，“蓄水池”里的紧急用水可以让播放器还能坚持一小段时间，只要在这个短暂的时间内网速恢复正常，播放器就可以源源不断地渲染出流畅而平滑的视频画面。
“蓄水池”里的水越多，抗网络波动的能力就越强，但代价就是观众端的延迟就越大，所以要在不同的场景下，使用不同的配置来达到体验上的平衡：
RTC 模式下这两个参数是无效的。
微信切到后台以后是否继续播放声音，用于避免锁屏对于当前小程序正在播放的视频内容的影响。
调试音视频相关功能，如果没有很好的工具会是一个噩梦，所以小程序为 live-pusher 标签支持了 debug 模式，开始 debug 模式之后，原本用于渲染视频画面的窗口上，会显示一个半透明的 log 窗口，用于展示各项音视频指标和事件，降低您调试相关功能的难度，具体使用方法我们在 中有详细说明。
开始播放，如果 的 autoplay 属性设置为 false（默认值），那么就可以使用 play 来手动启动播放。
暂停播放，停留在最后画面。
通过live-player标签的 bindstatechange 属性可以绑定一个事件处理函数，该函数可以监听推流模块的内部事件和异常通知。
|
|
|
服务器开始传输音视频数据
|
|
网络接收到首段音视频数据
|
|
视频播放开始，可以在收到此事件之前先用默认图片代表等待状态
|
|
|
进入缓冲中状态，此时播放器在等待或积攒来自服务器的数据
|
|
网络连接断开，且重新连接亦不能恢复，播放器已停止播放
|
播放 HTTP:// 打头的 FLV 协议地址时，如果观众遇到播放中直播流断开的情况，小程序是不会抛出 PLAY_EVT_PLAY_END 事件的，这是因为 FLV 协议中没有定义停止事件，所以只能通过监听 PLAY_ERR_NET_DISCONNECT 来替代之。
内部警告并非不可恢复的错误，小程序内部的音视频 SDK 会启动相应的恢复措施，警告的目的主要用于提示开发者或者最终用户，例如：
|
|
|
|
网络断连，已启动自动重连恢复（重连超过三次就直接抛送 PLAY_ERR_NET_DISCONNECT 了）
|
|
视频流不太稳定，可能是观看者当前网速不充裕
|
|
|
硬解启动失败，采用软解
|
|
当前视频帧不连续，视频源可能有丢帧，可能会导致画面花屏
|
|
DNS解析失败（仅播放 RTMP:// 地址时会抛送）
|
|
服务器连接失败（仅播放 RTMP:// 地址时会抛送）
|
|
服务器握手失败（仅播放 RTMP:// 地址时会抛送）
|
|
|
当前视频编/码器输出的比特率，单位 kbps
|
|
当前音频编/码器输出的比特率，单位 kbps
|
|
|
当前视频 GOP,也就是每两个关键帧(I帧)间隔时长，单位 s
|
|
|
网络抖动情况，为 0 时表示没有任何抖动，值越大表明网络抖动越大，网络越不稳定
|
|
|
- push 模式，即从当前页跳转至下一页时出现小窗（页面栈push）
- pop 模式，即离开当页面时触发（页面栈pop）
- 以上两种路由行为均触发小窗
此外，小窗还支持以下特性：
- 小窗容器尺寸会根据原组件尺寸自动判断
- 点击小窗，用户会被导航回小窗对应的播放器页面
-
组件是由客户端创建的原生组件，它的层级是最高的，不能通过z-index控制层级。可以使用 和 覆盖在上面。
-
请勿在 ，，， 中使用 组件。
-
默认宽度300px、高度225px，可通过wxss设置宽高。
-
开发者工具上暂不支持。
- 小程序基础库最低版本要求：1.7.0。
- 由于微信开发者工具不支持原生组件（即 和 标签），需要在真机上进行运行体验。
调试时为什么要开启调试模式？
开启调试可以跳过把这些域名加入小程序白名单的工作，否则可能会遇到登录失败，通话无法连接的问题。
|
|
用于音视频上行的推流 URL
|
|
|
|
|
|
|
|
0
|
美颜指数，取值 0 - 9，数值越大效果越明显
|
|
0
|
美白指数，取值 0 - 9，数值越大效果越明显
|
|
|
是否正常焦距，true 表示将摄像头放大
|
|
|
最小码率，该数值决定了画面最差的清晰度表现
|
|
最大码率，该数值决定了画面最好的清晰度表现
|
|
low 适合语音通话，high 代表高音质
|
|
当微信切到后台时的垫片图片
|
|
当微信切到后台时的垫片图片的校验值
|
|
当微信切到后台时是否禁用声音采集
|
|
用于指定一个 javascript 函数来接收音视频事件
|
|
-
用于音视频上行的推流 URL，以rtmp://协议前缀打头，腾讯云推流 URL 的获取方法见 文档。
小程序内部使用的 RTMP 协议是支持 UDP 加速的版本，在同样网络条件下，UDP 版本的 RTMP 会比开源版本的有更好的上行速度和抗抖动能力。
-
SD、HD 和 FHD 主要用于直播类场景，例如赛事直播、在线教育、远程培训等等。SD、HD 和 FHD 分别对应三种默认的清晰度。该模式下，小程序会更加注重清晰度和观看的流畅性，不会过分强调低延迟，也不会为了延迟牺牲画质和流畅性。
RTC 则主要用于双向视频通话或多人视频通话场景，例如金融开会、在线客服、车险定损、培训会议等。该模式下，小程序会更加注重降低点到点的时延，也会优先保证声音的质量，在必要的时候会对画面清晰度和画面的流畅性进行一定的缩水。
-
横屏（horizontal）模式还是竖屏（vertical）模式，默认是竖屏模式，即 home 键朝下。这时，小程序推出的画面的宽高比是3：4或者9：16这两种竖屏宽高比的画面，也就是宽 < 高。如果改成横屏模式，小程序推出的画面宽高比即变为4：3或者16：9这种横屏宽高比的画面，也就是宽 > 高。
-
这里首先要科普一个概念 —— 视频码率，指视频编码器每秒钟输出的视频数据的多少。在视频分辨率确定的情况下，视频码率越高，即每秒钟输出的数据越多，相应的画质也就越好。
所以 min-bitrate 和 max-bitrate 这两个属性，分别用于决定输出画面的最低清晰度和最高清晰度。这两个数值并非越大越好，因为用户的网络上行不是无限好的。但也不是越小越好，因为实际应用场景中，清晰与否是用户衡量产品体验的一个重要指标。具体的数值设定我们会在**“参数设置”**部分详细介绍。
小程序内部会自动处理好分辨率和码率的关系，例如2Mbps的码率，小程序会选择720p的分辨率进行匹配，而300kbps的码率下，小程序则会选择较低的分辨率来提高编码效率。所以您只需要关注 min-bitrate 和 max-bitrate 这一对参数就可以掌控画质了。
-
出于用户隐私的考虑，在微信切到后台以后，小程序希望停止摄像头的画面采集。但是对于另一端的用户而言，画面会变成黑屏或者冻屏（停留在最后一帧），这种体验是非常差的。为了解决这个问题，我们引入了 waiting-image 属性，您可以设置一张有 “稍候” 含义的图片（waiting-image 是该图片的 URL，waiting-image-hash 则是该图片对应的 md5
校验值）。当微信切到后台以后，小程序会使用该图片作为摄像头画面的替代，以极低的流量占用维持视频流3分钟时间。
-
调试音视频相关功能，如果没有很好的工具会是一个噩梦，所以小程序为 live-pusher 标签支持了 debug 模式，开始 debug 模式之后，原本用于渲染视频画面的窗口上，会显示一个半透明的 log 窗口，用于展示各项音视频指标和事件，降低您调试相关功能的难度，具体使用方法我们在 中有详细说明。
|
|
窄带场景，例如户外或者网络不稳定的情况下适用
|
|
目前主流的 App 所采用的参数设定，普通直播场景推荐使用这一档
|
|
对清晰度要求比较苛刻的场景，普通手机观看使用 HD 即可
|
|
这是一种声音为主，画面为辅的场景，所以画质不要设置的太高
|
|
由于可能要看车况详情，画质上限会设置的高一些
|
|
主讲人画质可以适当高一些，参与的质量可以设置的低一些
|
|
作为会议参与者，不需要太高的画质和音质
|
如果不是对带宽特别没有信心的应用场景，audio-quality 选项请不要选择 low，其音质和延迟感都要会比 high 模式差很多。
- 开始推流，如果 的 autopush 属性设置为 false（默认值），那么就可以使用 start 来手动开始推流。
- 恢复推流，请与 pause 操作配对使用。
- 推流截图，截图大小跟组件的大小一致。截图成功图片的临时路径为
ret.tempImagePath。
通过 标签的 bindstatechange 属性可以绑定一个事件处理函数，该函数可以监听推流模块的内部事件和异常通知。
|
|
已经成功连接到云端服务器
|
|
与服务器握手完毕，一切正常，准备开始上行推流
|
|
已成功启动摄像头，摄像头被占用或者被限制权限的情况下无法打开
|
内部警告并非不可恢复的错误，小程序内部的音视频 SDK 会启动相应的恢复措施，警告的目的主要用于提示开发者或者最终用户，例如：
- 上行网速不给力，建议提示用户改善当前的网络环境，例如让用户离家里的路由器近一点，或者切到 Wi-Fi 环境下再使用。
- 请求被后台拒绝了，出现这个问题一般是由于 URL 里的 txSecret 计算错了，或者是 URL 被其他人占用了（跟播放不同，一个推流 URL 同时只能有一个用户使用）。
- 当用户单击小程序右上角的圆圈或者返回按钮时，微信会将小程序挂起，此时 会抛出5000这个事件。
|
|
上行网速不够用，建议提示用户改善当前的网络环境
|
|
网络断连，已启动重连流程（重试失败超过三次会放弃）
|
|
硬编码启动失败，自动切换到软编码
|
|
由于机器性能问题，自动切换到硬件编码
|
|
DNS 解析失败，启动重试流程
|
|
服务器连接失败，启动重试流程
|
|
服务器握手失败，启动重试流程
|
|
服务器主动断开连接，启动重试流程
|
|
socket 链路异常断开 ，启动重试流程
|
|
微信小程序调用百度api识别语音，识别出来只是哦哦，嗯等语气词，咋回事呀！
