结尾的的htt
p-flv播放协议，推荐使用后者，因为这种播放地址各个云厂商都优化的比较好。step5：为你的小程序增加一个 <live-player> 标签，并将 src 参数指定为你在 step4 中生成的播放 url。同时， <live-player> 的 mode 参数请指定为 live， orienta
tion和 object-fit 属性可以用于调整画面布局， min-cache 和 max-cache 则可以用于控制观众跟主播之间的延时大小，推荐的设置是 min-cache= 2， max-cache =5。关于在线直播，你会有这样的疑问1、时延太高是怎么回事？在线直播的延时跟播放协议和播
放器参数有很大的关系， <live-player> 的 min-cache 和 max-cache 用于控制播放器端的zui小时延和zui大时延。其中，这里所说的“zui小”和“zui大”是根据观众端当时的网络情况而定的，如果网络情况比较好，那么播放器的时延就会趋向于 min-cache，而如果网络情况比较差，那么
播放器的时延就会趋向于 max-cache。另外，rtmp 协议和 http-flv 协议的播放地址延时一般比较低，而 hls(m3u8)协议的延时则相对较高。2、***络不好怎么办？在一场直播过程中，如果观众端的网络不好，那么观看体验仅仅影响到当前观众；如果主播的网络不好，那么所有观众的观看体验
都会很糟糕。因此主播的上行网络质量很重要，如果主播的上行网络质量不理想，比如时好时坏，或者上行小水管，不足以支持基本的直播需求，有两种办法可以解决问题:一种办法是设置 <live-pusher> 的 min-bitrate 参数，比如 400kbps, 这样一来，当***络不给力的时候， <live
-pusher> 就会给主播的编码器发送降低画质的命令，通过降低编码器吐出的数据量来给主播的网络减负。但这种办法产生的副作用也非常明显，就是主播的画质会变差。另一种方法则是借助 <live-pusher> 的 NET_BUSY 通知进行 UI 上的告警提示， <live-pusher> 在主播上行网
