随着中国企业级SaaS行业发展进入成长期，企业直播市场进入稳中求进的深耕发展期。同时也随着企业客户对于直播产品的质感要求不断提升，也驱动着业务提供更好体验的播放体验。

　　本篇将一步步做拆解，讲述企业直播在播放业务中都做了哪些探索与最佳实践。

　　

　　企业直播在一个完整的直播周期内，主要分为直播场景和以预告及回放为主的点播场景，其中：

　　直播：

标准直播模式：支持flv、hls的的标准拉流直播；

低延时直播模式：支持rtm的低延时直播能力，延时小于1000ms；

时移 直播：通过进度条及卡片时移的方式回溯之前的直播内容；

AI实时字幕：根据直播流内容实时生成AI字幕，支持多语种翻译；

直播体验策略：自动播放、智能选路等策略优化播放体验；

　　点播：

智能抠图弹幕：支持了直点播的弹幕配置，支持人像抠图能力；

点播打点：对回放中的高亮瞬间进行打点标注提示；

　　数据指标搭建：

QoS 质量指标：监测拉流质量数据，数据来自播放器打点上报；

QoE 体验指标：监测直播活动使用数据，数据来自业务打点上报；

指标优化策略：监控线上数据变化，制定优化策略提升观播体验；

　　暂时无法在{app_display_name}文档外展示此内容

　　接下来我们详细介绍一下一些主要功能的具体实现：

　　直播时移是指在直播的同时，观众可以回看从直播开始时间到当前时间之间的直播内容。通常在带货直播、游戏直播、教育直播中有应用体现。例如带货直播中，观众期望回看主播之前讲解过的商品。

　　为了应对这些需求场景，企业直播推出了时移直播+卡片讲解的功能：

　　主播

主播在直播推流前开启时移直播

主播提起录入本次讲解要上架的卡片

在直播过程中主播对上架的卡片进行讲解

　　观众

进入页面观看实时直播

点击对应卡片跳转至对于时刻观看讲解

返回实时直播

　　

　　了解了直播时移的应用，那么时移直播是如何实现实时直播与时移的切换的呢？时移的切换分为四步：

确认可以回看的范围（duration）

通过观众点击时移轴的长度，计算回看的范围(shiftTime)

带上(shiftTime)，请求拉流地址，进行回看。

切换回实时直播，将shiftTime置为0，重新请求拉流地址。

　　

　　首先回看的范围（duration）由创建播放器前已经直播的时间（liveGap）和创建播放器之后直播的时间相加所得。liveGap我们可以通过请求服务端得知。创建播放之后的时间我们可以获取当前的本地时间（Data.now()）减去创建播放器时记录的本地时间（initTime）来计算。

　　当用户进行时移切换时，我们需要计算出回看的时移时间（shfitTime）,这个值的含义表示是相对于最新的直播时间，回看多少时长。 那么回看的时移时间即为用户点击进度条所占的百分比乘以可时移的范围（duration）。

　　实时AI字幕功能是在直播的同时使用AI技术（语音识别），将视频内的语音转为文字，并以字幕的形式呈现在屏幕上。目前我们实现了两种模式的AI字幕：

　　外挂字幕：

可以自由切换字幕的语言

可以自由调整字幕的大小、颜色、字体与展示区域

可以自由决定是否字幕的开启与关闭

　　流内字幕：

无需考虑在不同端展示效果不一致的问题

将直播流进行转推转码时，不会丢失字幕

不需要客户端单独进行对齐

　　外挂字幕是在直播的同时通过长连接从服务端进行拉取字幕，在播放器内部通过读取流的SEI数据进行Dts对齐，在播放到对应时刻的时候，将对齐的字幕进行展示出来。这种模式主要的优势可以将控制权交给观众，让观众根据自己的喜好来选择字幕语言，调整字幕的样式与大小。外挂字幕的整体流程如下：

　　

主播开启直播，进行推流至CDN

CDN后处理流中的音频进行解析，送至AILab语音识别与翻译服务

CDN后处理获取到翻译后的字幕后通过长连接推送至前端。

前端创建播放器进行拉流播放，同时与服务端建立长连接读取字幕

播放器通过解析流中的SEI读取原始时间戳与字幕所带的时间戳进行对齐

展示字幕给观众

　　由上述流程可知，在外挂字幕中最重要的一点就是字幕的播放对齐，那么这是如何实现的呢？

　　

　　通过对直播流进行，从中可以解析出当前播放分片对应的原始时间戳与当前播放的真实时间戳。从长连接中读取的字幕，我们可以获取该条字幕的开始时间与存在时长。字幕的对齐本质上就是对和的对齐。但是因为的解析是在正式播放之前的，而我们要做的是在该分片被播放时，展示出与其对应的字幕。

　　这时我们就需要在解析SEI的时候记录真实时间戳与原始时间戳的一个时间差，当播放到该时间点时，我们在通过对之前计算出的进行相加，还原出原始时间戳与字幕进行匹配。当一条字幕的开始时间小于当前的播放时间，开始时间加上字幕的展示时长大于当前的播放时间，我们就是认为需要展示该条字幕了。

　　

　　当功能上线后，我们发现在评论区经常有观众提出主播还没讲到这里呢，字幕已经展示出来，这是不是一场伪直播呢？经排查发现，原来是因为我们是对整行字幕进行匹配的，匹配成功之后就直接将整行字幕展示出来了，才导致了误解的产生。于是我们想到是否可以逐字去展示字幕呢，后来经过和服务端进行沟通，但是当时字幕识别的精度还不够，不能进行字幕逐字或者逐词的拆分。经过讨论，我们决定在前端做了一个字幕伪逐字展示的优化方案：将该句字幕的展示时长平均分配给每一个文字（英文分配给每一个单词）。

　　由上边可知，字幕的对齐需要通过对直播流进行解析，并在播放的时候进行对齐。但是在移动端，因为的支持性问题，我们是直接将播放地址给了video进行播放，并没有对流进行解析，所以在移动端实现外挂字幕成了一个难题。

　　为了解决移动端浏览器不支持的这个问题，我们从web多媒体同学那里找到了替代方案：在移动端使用软解播放器（用wasm进行解码、canvas进行绘制画面）进行拉流播放与解析与，从而进行字幕与播放的对齐。

　　流内字幕是在cdn侧将AI识别的字幕进行对齐，使用滤镜将字幕绘画进直播流内，随着直播画面一起放出。流内字幕的整体流程如下：

　　

主播开启直播，进行推流至CDN

CDN后处理流中的音频进行解析，送至AILab语音识别与翻译服务

CDN后处理获取到翻译后的字幕后通过将字幕合成到流内推出合成流

前端创建播放器拉取合成流进行播放

　　在实现流内字幕后，我们发现因为AI识别生成的字幕不是那么准确，在直播过程中容易让观众产生一些误解。因此我们基于流内字幕实现了人工字幕校正的功能。

　　

　　与上述流程不同的是的：

主播推流时会设置直播放出延迟。

在直播推迟的这段时间内，校验人员可以从控制台上读取到AI识别生成的字幕，再通过时移功能直播画面进行反复观看，对不准确的地方进行校正。

CDN将校正后的字幕合入流内，等到达到直播放出延迟时，推出合成流

　　在直播刚刚兴起时，直播中的互动环节较少，主播单方面控场，因此延迟十几秒对用户体验影响较小。常见的直播大部分采用RTMP、HLS、FLV协议，技术成熟、兼容性较好、支持大规模并发等优点，但端到端延时最低只能控制在4-6秒，降低了直播的互动体验，也阻碍了直播在一些场景的落地推广，不利于直播应用生态系统的繁荣。

　　随着“直播+”模式在各行各业的加速发展，电商直播、在线课堂、体育赛事、互动娱乐等多样化互动直播的形式出现，让用户对实时互动性有了更高的要求，端到端延时跨入毫秒级直播时代。市面上常见的直播方案延迟时间对比：

直播模式延迟备注HLS10-20s苹果提出的基于HTTP的流媒体传输协议，将视频切割时TS分片，通过HTTP请求m3u8索引文件，按照索引文件对TS分片进行请求下载1. 采用苹果官方新推出的低延迟方案，将视频分片进行更小的分割，可以将延迟缩短至 1-3sHTTP- FLV8-10sAdobe发布的一个视频传输的协议，底层基于TCP，将音视频数据封装成FIV格式，通过HTTP协议传输给客户端，流式传输通过调整Gop与 cdn的GopCache，可以将延迟缩短至 3-5sRTM低延迟1s以内基于RTC实时音视频引擎和传统RTMP直播系统

　　RTM低延迟直播是基于webrtc，底层使用UDP/RTP进行传输，相对于TCP速度更快。

　　

　　由流程图可知，RTM直播可以概括：

创建RTC节点，获取自己的SDP(offer)。

通过http请求cdn节点，获取cdnRTC节点的SDP(answer)。互相交换设置本地与远端的SDP，建立RTC连接

监听事件获取远端传递的MediaStream。

创建video并将MediaStream传递给video进行播放。

　　在开发过程中，我们发现由于不同浏览器对webrtc支持性不一致和rtc推拉流的不稳定性，对一些观看直播观众不太友好。因此我们制定了一些降级方案：

　　

针对一些浏览器不支持webrtc的API的问题，我们在创建播放器前对其进行检测，如果不支持，则直接进行创建flv或者hls的标准直播。

针对一些浏览器探测相关api可用，但是真正直播的时候却暴露出有声无画等类似问题，我们建联了黑名单机制，通过摸底测试，我们记录下这些会出问题的环境ua，在创建播放器前判断是否命中这些环境，如果命中，则直接进行创建flv或者hls的标准直播。

　　

针对直播过程中出现rtc因为网络问题或者cdn节点出现问题导致无法继续观播的场景，我们在监听到对应的报错之后，会将低延迟直播降级为flv或者hls的标准直播。

　　为了提高用户在回看视频时的观看体验，使用户在观看视频的同时看到别人的评论，增强观看者之间的互动性和交流性，提高用户观看乐趣，支持用户在观看回放时以发送弹幕的形式发表评论，因此我们实现了弹幕功能。弹幕功能分为实时弹幕与点播弹幕两种模式。

模式定义实现实时弹幕更侧重于实时，在用户发送后需要立刻展示在播放区域（一般应用于直播）通过http轮训请求用户最新发送的弹幕，批量拉取20条字幕，因为没有时间点，为了防止20条一次性的同时排列输出，我们会对字幕进行打散，通过一个定时器，将20条字幕逐条发出点播弹幕需要与时间点进行绑定，只有在播放到对应时间点时才会展示该弹幕通过监听播放进度事件、每隔30s进行一次弹幕拉取，拉取接下来30s的弹幕。当用户进行seek的时候也需要重新拉取接下来30s的弹幕。

　　当弹幕堆积，视频内容尤其是人物容易被弹幕遮挡。因此需要一种用户在保留弹幕的同时能看到人物形象的解决方案，而蒙版弹幕就是这样一种解决方案。

　　

　　当点播文件上传时候，点播服务先进行视频中的人像进行识别判断，判断该视频是否适合使用蒙版功能。当判断生效后，服务会对视频进行抽帧，进行帧级别的人体分割，获得人体分割的二值图像，并将该二值图转换为SVG矢量图。前端通过监听播放进度事件，去拉取对应的svg，再通过css调整 属性将蒙层遮罩在视频上，即可将人物头像上的弹幕遮挡掉。

　　由于企业直播是Tob的，常常会遇到像「CEO 面对面」之类的公司内大型活动直播，直播活动的特点有这么几条：跨不同国家地域、多个语言、复杂内外网环境。想象一下：当国外的同学首次进入直播页，播放的是【外网 - 中文】线路，那他就不得不在眼花缭乱的多线路列表里，手动选择自己看的舒服的线路【内网 - 英文】。

　　我们针对此问题设置了策略，通过判断浏览器的语言环境与直播线路进行匹配，帮观众免除人工判断，自动选择最佳的播放线路，快速参与到直播活动中来。

　　随着公司的成长，对内的类似于CEO面对面这样的直播活动越来越多。观看的人员也从之前的几千人，增长到几万人。对内网的压力很大。但是由于内网网络情况在不同工区各不相同，因此往往会出现，某个工区用户特别卡顿，某个工区用户无法拉到流，无法正常播放。

　　那么代入问题，我们如何权衡内网下的播放流畅度和清晰度呢？还是得回到工区网络带宽的问题上，最直接方式便是，增加工区带宽，但是这样的成本比较高，且性价比不明显。因为已有的网络带宽是可以满足同学们日常工作需求的，且「CEO 面对面」这种公司级别的直播活动其实次数还是较少。

　　在升级网络不太可行时，我们迫切需要一个策略，支持以工区、IP维度动态调控网络和拉流配置，这样就能让人少的工区看高清、人多的工区看低清。工区可以部署NSS 节点， 观众可以从NSS节点而不是通过公网到CDN上拉取直播视频播放，这无疑会大幅度减少公网带宽的消耗，也能满足不同工区有自己独立的拉流节点。

　　企业直播制定了内网优化的直播方案，通过在直播前提前优先获取当前工区内最佳直播配置，为观众下发最适合他们自己清晰度与拉流地址，来解决该问题。

　　

StreamRouter是什么？

　　企业内网直播NSS节点配置管理/路由中心，负责对内网直播拉流请求按照工区分配对应的NSS节点，并返回默认清晰度、拉流协议等建议配置。

StreamRouter的配置应用

　　

　　在“内网优化 v2.0”版本，我们支持了分工区调控可用的清晰度范围、正在播放的清晰度大佬们都在玩{精选官网网址: www.vip333.Co }值得信任的品牌平台!。所以有了聚合降级策略。

　　观众端通过定期上报直播打点日志，数据平台对日志进行清洗，如果卡顿率超过预先设置的阈值，企业直播服务端则下发WebSocket消息，调整用户正在观看的清晰度和可选范围。企业直播根据卡顿所在工区、BSSID等维度，主动下调用户可选的清晰度列表，自动切换当前网络下最顺畅播放的清晰度。

决策路径

　　

处理措施

　　

　　在一些重要的直播活动中，为了防止因为推流设备故障、CDN 转码链路出现故障、CDN某个拉流节点出现故障导致直播过程突然中断，一般都会使用多个设备进行推流，推至多家CDN节点来预防事件发生。采取这种模式的同时也就会产生多路拉流地址，一般我们会默认设置相对稳定的一路流作为主流，其他的流作为备流。当用户拉取主流播放出现问题时，播放器会主动切换为备流保证直播可以继续顺利播放。

　　企业直播采取的主备流降级为：当播放器检测到拉流失败或者拉流断流时，会依次尝试备流list，直到所有备流都尝试失败，展示对应的提示文案。具体如下：

　　

　　由于播放侧判断错误能力有限，无法明确的判断出是主路出现了问题还是用户因为自身网络断网而导致的无法播放问题。因此无论这两种情况哪种导致播放器降级，我们都会进行主备降级，主流出现问题后就会重试备流，如果两条线路都出现问题，我们就会展示出错误提示，提示用户检查自身的网络是否出现问题。

　　为了带给用户更好的播放体验，主播在直播时通常会提供多个清晰度选项供用户选择。作为观众，我们往往都喜欢去看最高清晰度的流，追求最极致的体验。但是有时候，自家的网络状况却不那么配合，刚看一小段播放器就开始转圈，有时候甚至频繁卡顿。因此我们制定了清晰度降级方案，帮助大家选取最适合自己的清晰度，具体流程如下：

　　

事件含义实现waiting视频卡顿video原生事件playing视频播放video原生事件long_waiting长时间卡顿在事件触发一次后，5秒内没有再触发事件，我们认为是触发了一次长时间卡顿（）often_waiting频繁卡顿在短时间内（5s）连续触发3次事件，认为是用户在频繁卡顿（）

　　由于原生的触发比较敏感，不适合直接用来进行降级所以我们在其基础上封装了，事件，但是事件上线后发现效果并不是很好，触发仍然比较敏感，导致用户降级很频繁，后来便将该事件下架了。

　　这里为了防止突然降级切流导致用户体验变差，我们只会在智能档位下进行自动降级处理，当用户切换至其他档位时，出现卡顿后则会弹出提示，提示用户去手动切换至适合的档位。

　　在上述的讲解中，我们提到了在企业直播的某些业务场景中我们在移动端使用了软解播放器。但是因为软解播放器底层实现依赖与原因，他会有一些兼容性问题与性能问题，比如导致手机发烫等。对此我们制定了软解播放器的降级策略。

　　

创建播放器前进行API是否支持判断，如果不支持则使用原生进行播放

播放过程中，检测解码效率，如果解码效率过低，则进行降级至进行播放

　　当我们在观看直播的过程中经常会发现，打开页面后播放器有时候会自动开始播放但是没有声音，需要点击取消静音的按钮，有时候甚至不能自动开始播放，反而需要去手动点击播放器中间的按钮才能开始播放。这主要是因为浏览器为了改善用户体验，最大限度地减少广告骚扰，并减少数据消耗，制定了一些策略，限制了音频的自动播放。（但是这些策略反而影响了一些想要自动播放的用户体验）

　　例如Chrome对自动播放的限制，如下：

　　始终允许静音自动播放。

　　在以下情况下，允许自动播放声音：

用户已与域进行了交互（单击，点击等）。

在台式机上，已经超过了用户的“媒体参与度索引”阈值，这意味着该用户以前曾播放有声视频。

用户已将该网站添加到移动设备上的主屏幕，或在桌面上安装了PWA。

　　顶部框架可以将自动播放权限委派给其iframe，以允许自动播放声音。

　　

　　为了优化这部分用户的观看体验，我们根据不同浏览器对自动播放的限制，我们制定了一个优化策略：默认尝试非静音自动播放，如果启播失败，再将播放器静音重新尝试播放，如果仍然无法启播，最后再展示出封面与播放按钮，由用户手动触发播放。详细流程如下图：

　　

　　策略上线之后，经过多次测试与客户反馈的沟通，我们发现在移动端下也存在一些自动播放的体验问题：

　　IOS低电量模式下不再支持自动播放

　　安卓微信下不支持自动播放微信声明

　　安卓与IOS的webview下需要在开启允许背景播放的配置，才可以支持自动播放

安卓：参考文档

ios: 参考文档

　　在一些移动端的浏览器或webview中，开发商为了统一视频的播放体验，或者在视频的片头植入广告。会使用用原生Native播放器替换掉，将系统播放器作为单独的一层直接盖在webview上，这样会导致播放器的层级比所有的DOM节点都高，让业务中一些可能本身层级需要比播放器高的元素（例如弹窗）被播放器挡住。除此之外，第三方浏览器在Native播放器的能力实现上也存在着一些实现上的欠缺（例如倍速播放，封面图、弹幕等），影响播放相关业务的开展。大佬们都在玩{精选官网网址: www.vip333.Co }值得信任的品牌平台!

　　移动端Native劫持播放器的实现逻辑主要是浏览器会检测元素中是否存在标签，检测到标签后将其替换为Native播放器。对此，我们想到了一个解决方案，用软解播放器来替换原生的播放。因此软解播放器是用进行画面绘制，从而可以逃脱Native对的检测，达到瞒天过海的目的。

　　但是由于软解播放器存在性能问题，所以我们并不能在移动端进行完全的替换，除此之外，我们还要针对其性能问题制定一些降级策略来保证观看体验（参考上述播放中的降级策略）。

　　因此我们对移动端常见的浏览器与webview做了一个摸底测试，统计出了一个会被Native劫持的白名单，如果命中这些白名单，我们便会使用软解播放器来替换原生的播放。

　　当我们在360浏览器中打开直播页面后，我们发现360浏览器会默认携带一个录制直播画面的插件，让观众可很容易的对直播进行一个录制。这个功能对一个保密性比较高直播来说很不友好，容易导致直播画面被泄露。

　　经过调研，我们发现360浏览器是通过调整的样式，将其全屏放大，然后调用的与方法进行拉流，同时下载录制视频资源。

　　了解了该实现逻辑后，我们见招拆招：在播放器创建完成后，通过创建，观察上属性的变化，如果上有样式注入，我们就暂停播放，同时将当前可以播放替换为无效，再展示“检测到浏览器正在对直播画面进行录屏，请关闭录屏后，刷新直播页面进行观看”的提示文案，来防止浏览器进行拉流下载。当上的样式被移除掉，我们便恢复播放器的展示，替换回可播放的，重新进行拉流播放，同时隐藏调提示文案。

　　在企业直播对外售卖的过程中，常常会有客户提出：为什么IOS的全屏和安卓的全屏样式不一样啊？这其实是因为安卓与ios对video的全屏逻辑的实现不一致。

　　安卓点击全屏后会自动旋转为横屏，并保留video的全部样式与功能。但是ios的全屏则是使用系统播放器来替换video实现全屏大佬们都在玩{精选官网网址: www.vip333.Co }值得信任的品牌平台!。具体差异如下：

模式效果备注安卓-系统全屏全屏后会自动变为横屏展示不受手机是否方向锁定影响，不受是否支持旋转影响保留了原始的UI与交互IOS-系统全屏全屏后不会自动变成横屏展示，横屏需要用户手动进行旋转用户旋转播放器受手机是否方向锁定与是否支持旋转影响播放器会被播放器替代，UI与交互存在差异，部分功能不支持样式全屏样式全屏，是我们在前端实现的伪全屏（即全屏时不再依赖系统能力，而是通过调整让充满容器）只能充满，无法充满手机，因此无法遮盖全屏时无法自动横屏，是否可以横屏取决于手机是否有方向锁定、容器是否支持旋转为横屏会保留原始的UI与交互

　　为了尽可能的统一各端观众的全屏观看体验，并且最大的保证我们的业务功能完整，我们制定了移动端的全屏策略，在安卓端默认使用原有的系统全屏，在 端默认使用样式全屏。考虑不同客户的需求场景不同，因此我们也提供配置项来让客户自助决定使用哪种全屏模式。

　　因为移动端的播放器在页面中的位置与大小较小，考虑到用户一般都会点击全屏进行观看。因此我们也做了另一个策略：当用户把手机旋转成横屏的时，播放器自动全屏。

　　为了量化直播质量，统计功能上线是否带来正向收益，我们建梳理出了QoS、QoE指标。Qos用于衡量直播系统中，客观发生的质量相关事件比如卡顿、失败、中断等指标，便于我们定位问题，制定技术优化策略。QoE是用户体验或者用户感知，收集的是用户的行为数据，主要是用来衡量用户的主观体验，便于我们制定一些体验优化策略。

指标定义意义拉流成功率在用户退出前拉到流的播放过程占比反馈直播的整体拉流质量拉流成功率去重在用户退出前出首帧的播放过程占比，根据uid去重反馈直播拉流质量影响用户百分比端到端延迟一帧视频从推送到播放的延迟时间反馈直播延迟百秒卡顿次数单次播放的百秒卡顿时长，取平均反馈直播的卡顿率百秒卡顿时长单次播放的百秒卡顿次数，取平均反馈直播的卡顿率秒开率首帧时间在1s内的占比反馈直播的首帧延迟首帧耗时从开始拉流到播放器出首帧的时长反馈直播的首帧延迟

　　我们根据上面梳理的播放指标建立了质量大盘与体验大盘。

　　我们通过对大盘指标设置监控，将不符合预期的指标数据通过飞书机器人在指定飞书群内进行报警，再由负责的同学进行跟进处理。目前设置的报警有：

拉流成功率报警：当该直播间的拉流量大于(n)，并且拉流成功率低于(m)%进行报警

端到端延迟报警：当该直播间的拉流量大于(n)，并且端到端平均延迟大于(x)s进行报警

　　下面是一些根据之前的报警，进行排查的Case：

Case排查原因改进方案某场对外直播拉流成功率较通过查询该场直播的开播与关闭播时间间隔，发现该场直播在短时间是内多次推断流，怀疑用户当时在进行直播前测试由技术支持同学向用户进行反馈某场直播大会拉流成功率较低通过排查用过的拉流日志，发现有一些ip下拉流成功率很低，查询这些ip发现都来自同一云服务因此怀疑是这个dns的网络存在解析问题，或者这些ip是爬虫抓取页面，导致页面拉流成功率比较低通过ua移除这些ip的日志，拉流质量回归正常指标统计添加爬虫筛选海外的直播的某场直播拉流成功率较低通过比对一些观众的拉流地址，发现一些地区的拉流成功率比较低，影响了整体怀疑cdn的海外节点存在一些问题向对应的CDN进行反馈某客户的直播拉流成功率较低通过查找的拉流日志，发现是一些个别用户拉流存在问题，影响了整体的拉流数据对这些有问题的观众进行抽样查询其具体的行为日志，发现该用户使用平板进行观看，在平板因为我们对UA的错误判断，导致其使用了flv格式的进行直播，进而导致拉流失败将该问题转换为技术需求进行跟进某场直播的端到端延迟较长，直播实时性不高通过排查，发现该直播间在使用直播时移功能，通过找服务端与cdn的同学进行排查，发现时移直播使用cdn域名配置了首个m3u8等待时长：40s配置，这个对应控制台的HLS延迟高延迟，推流GOP 1s、2s、4s时，预计延迟时间分别为 10-15s, 20-25s, 30+s向cdn厂商进行反馈，同时提交工单做对应的配置更改