首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >新知 | 广电级媒体数字化转型直播技术及应用

新知 | 广电级媒体数字化转型直播技术及应用

作者头像
腾讯云音视频
发布2022-09-13 14:11:01
6640
发布2022-09-13 14:11:01
举报
文章被收录于专栏:音视频咖音视频咖

新知系列课程第二季来啦!我们将为大家带来全真互联时代下新的行业趋势、新的技术方向以及新的应用场景分享。本期我们邀请到了腾讯云音视频技术导师——吴昊,为大家分享广电级媒体数字化转型中的一些直播技术及应用。

我们将结合赛事活动线上化的背景,分享如何提高赛事直播稳定性,并介绍播放端用户协议以及我们遇到的一些问题。最后还将简单介绍一些场景化的创新应用。

2020年以来,疫情改变了人们的生活和工作方式,越来越多的线下活动被搬到了线上。与此同时,人们对娱乐体育赛事的关注度也逐年增长。线上制作和直播成为了很多企业的核心需求。

通常,一个完整的赛事流程,赛事现场可能遍布全球,那么它就需要把原始采集好的音视频信号,通过远程传输的方式推送到制作中心,经二次制作后,由云端服务进行媒体处理、封装以及分发,最终触达观众端的播放器。因此整个链路的稳定性和质量十分关键。

那么如何提升赛事直播的稳定性呢?我们从现场网络传输和云端媒体源站稳定性两方面来入手。

在赛事直播中,我们会遇到很多现场网络问题。比如网络切换,它容易发生在一些公共场所或运动场景,4G/5G/WiFi中有链路出现抖动,就可能发生切换的问题。还有就是现场单一网络出现带宽不足的情况。另外,在远程传输阶段,骨干网传输可能会因为传输误码、高峰期网络拥塞等原因,导致传输过程中出现丢包等问题。

下面我们再来看一下和网络传输息息相关的媒体传输协议。这里介绍一些媒体行业中常用的流媒体传输协议。首先是大家比较熟悉的RTMP。它比较成熟,生态也做的比较好,是目前主流的流媒体传输协议,但是它也存在一些局限,比如说它依赖于TCP传输,抗抖动比较差,而且RTMP支持的编码格式比较有限。这些原因限制了它的进一步扩展。

RTP也是广电媒体行业中使用较久的协议。MPEG-TS封装支持的编码格式比较丰富,而且RTP借助于UDP传输,延迟相对更低。但因为没有较完整的重传控制,RTP协议抗抖动性同样比较差,往往需要采取冗余发送的方式,比如说通过FEC前向纠错,或者通过SMPTE-2022-07,也就是多路冗余聚合的方式进行发送。

SRT是近些年逐渐推广使用的一个流媒体传输协议。因为其具备低延迟、高抗抖动性,正逐步成为主流的媒体协议。而且SRT自带多路复用,多路径等特性,也使其成为了当前大型赛事首选的传输协议。SRT不足的地方主要是在于其拥塞控制比较弱。因此,它更适用在传输带宽比较充足但是网络可能存在抖动的情形。

QUIC严格来讲其实是属于互联网应用场景的传输协议,在广电媒体行业中应用不多。但因为它的开源以及外部的生态做的比较好,目前也成为了HTTP3的一个标准。

RIST也是近些年逐渐兴起的一个基于RTP和RTCP的流媒体协议。因为其具备低延时、高抗抖动的特性,目前发展也很好。但因为成熟度的原因,目前相对于前面的其他的协议,使用量比较小。

广电媒体行业除了这些公网传输协议,其实还有一些局域网传输的流媒体协议,比如像NDI、SMPTE-ST-2110等等。这些协议的特点主要是低延迟,可以传输未压缩或浅压缩的音视频信号,比如ST-2110所传输的JPEG-XS,只采用了帧内预测,因此它的压缩率很小。不过这些特点更多用于局域网内传输,因为他们的传输带宽成本较高,限制了他们在公网传输领域的使用。

那么针对直播流媒体的特性,我们需要对网络传输进行优化来提升赛事直播稳定性呢?

首先是连接机制,比如支持0-rtt连接,加快连接效率。其次是重传机制,通过精确的rtt测量,可以动态调整重传间隔。另外,乱序可能引起重传,当网络波动时,乱序度可能会发生变化,所以我们需要建立机制,自适应的去调整乱序容忍度,从而减少不必要的重传。另外,我们需要更好的识别是拥塞丢包,还是误码传输导致丢包。我们通常的做法是通过基于rtt延迟梯度的带宽估计,去判断是否真正出现了拥塞,从而进一步决策是否调整码率。在一些低延迟优先的场景,我们还可以设置允许丢包。因为链路中的延迟,是由链路中各个模块的buffer引起的。在尽可能不影响观看体验的同时,我们可以可选择的丢包,去维持稳定的延迟。

除了上面提到的基础优化,这里再介绍一个流媒体传输中常用的质量提升方法——多路径传输。一些场景,现场可能有多种网络接入类型比如说4G/5G/WiFi等,那么通过多路径发送或聚合的方式,就能很好地避免单一网络波动带来的影响。并且在一些需要高码率传输的场景,这种方法也可以极大地扩展所需要的带宽上限。在切换时,当单一网络出现断网或波动时,多路径传输可以通过其他数据通道,快速将数据补足,达到平滑切换的效果。或者通过多通道聚合发送的模式,可以扩展带宽上限。

另外,在边缘地区或户外等云端节点往往不能做到本地覆盖的场景,我们还可以采用多接入点方案。常规的做法是在推流传输前进行探速,然后选择最优的链路接入点。如果活动的持续时间比较长,过程中网络不断变化,还可以使用多接入点动态路由策略,也就是在传输过程中,根据不同链路的质量情况,动态调整发送比例,自适应决策路由。

当然,我们在选择媒体远程传输方案时,也可以考虑使用腾讯云音视频提供的远程传输平台。它提供低延时、高抗抖动性的能力,并支持前面所提到的这些协议之间的互相转换。除了云端的方案,腾讯云音视频还提供了SDK的方式,增强弱网下推流的质量,同时兼具高抗丢包和低延迟的特性。在推流端应用腾讯云解决方案后,卡顿和延迟都可以得到很大的改善。

除了媒体传输,我们还需要提高媒体源站的稳定性。通常我们会采用冗余多路径合流的方式,去针对帧级别做纠错。但这里面有个问题,就是标准是基于发送端为同一个编码器的情况制定的。因此,我们需要处理不同编码器的融合问题。通常的做法是基于时间戳和GOP粒度做平滑切换,来处理不同编码源之间切换的平滑问题。另外,在断流期间,我们可以插入一段静态的图片,甚至是一个提前上传好的广告。来去优化观众端的播放体验。

在媒体分发阶段,通常我们需要结合链路的可量化质量指标,动态地调整链路。并且,我们可以根据历史统计信息去调整静态的覆盖策略。在一些重要的活动中,通常还需要采取多路回源与分发的模式。因为切换是有过程的,当感知到质量变化后再切换,实际上存在时间损耗。采取多路回源与分发的模式,可以减少切换的时间。

接下来,我们再简单介绍一下流媒体常用的一些播放协议。

用户播放端的协议有很多,但总体来说可以分为三类:连续流、切片式、低延迟切片。

最常见的是RTMP/FLV这种连续流式。它们可以做到较低的延迟,但也有一些问题,比如说,编码格式支持的比较少,扩展性比较差。而且这两个协议无法支持多码率甚至多音轨场景,或者说需要一些私有化的改造才能支持。

HLS和DASH这样的切片式协议很好地解决了可扩展性的问题,但延迟比较高。因为切片式的HLS和DASH需要每一个切片编码封装完之后,才能通过CDN分发出去。这也使得整个播放延迟是切片粒度的,而一个切片至少是GOP粒度的,往往在两秒、四秒甚至更高的水平。在这个背景下,低延迟切片流媒体应运而生。像CMAF、LL-HLS通过分块编码和分块传输,可以将延迟控制在两秒的级别。目前iOS等系统,也已经支持了CMAF/HLS fmp4的一些播放。

对于赛事直播场景,观众的网络条件是多种多样的。而且有些用户网络经常波动。所以我们需要能够支持多码率自适应,而且在多语言环境下,会有一些多音轨、多语言的需求。但是多码率常常会产生一个问题,就是不同码率之间的切片如果边缘不一致,会造成快进或者回退,有些播放器甚至会卡住。这里我们需要一个机制使不同切片进行对齐。我们可以用一次性切片的方法,就是在接流端在数据里进行标记,使不同码率在编码和封装阶段,它们的GOP以及切片的边缘协调一致。这样的话,在码率切换时,就不会出现画面的快进或回退现象。

再讲一下低延迟的问题。传统的HLS和DASH,无法做到低延时的根本原因是一个分片长度在编码和封装好后才能分发,这样就带来了极大的延迟。那么我们实现低延迟的大致原理,就是把这个粒度降到更小的Chunk的级别。也就是在一个切片还没有编码和封装完之前,先把已经编码封装好的分块,尽早的通过Chunk的方式分发出去。这样整个延迟就由一个切片的粒度降到了一个Chunk的级别。

另一种目前逐渐得到广泛应用的更低延迟的方案是基于WebRTC的快直播方案。除了优化了一些传输机制,快直播方案还结合了一些流媒体的特性,比如有选择的根据优先级进行分级重传或者丢帧,从而能够在弱网下也达到低延迟的目的。

最后再简单介绍一些我们在赛事直播场景中比较有意思的应用。

首先是在直播的基础上实现时移。统一直播和时移的请求协议和格式,这样就可以极大地简化播放器的逻辑。而且我们可以通过AI视频内容识别技术,把赛事中的一些精彩画面,通过打点的方式呈现给用户。具体的技术流程就是在媒体处理时,对视频帧进行理解,利用深度学习和视频分类,把识别到的事件信息通过回调的方式推送给客户。其次,在直播过程中生成的切片会直接归档存储,并生成时间点对应的时移索引文件。这样可以使直播和时移的切片保持一致,简化播放器的请求格式,在用户界面上的效果就是可以实现拖拽即时移的效果。

最后再简单说一下流媒体中常用的一个场景——广告插入。

根据插入的位置,一般广告可以分为三类,视频前广告、视频中广告以及视频后广告,其中视频后广告主要是针对于点播的场景。在技术实现上,我们可以通过垫片的方式,直接把广告通过编码嵌入到视频流中。但是这样的话,它是千人一面,也就是大家看到的广告内容都一样。或者利用广电级的标准——SCTE-35,生成相应的标签,支持这个标准的播放器识别标签后,可以执行所规定的一系列行为操作,比如开始播放一段指定的广告或者停止等等。这个标签通常在manifest文件描述信息里面,类似HLS的M3u8或者DASH的MPD描述符。

还有一种个性化的方式,也就是千人千面的效果。大致的做法是通过在直播流中打上一些标记,那么播放器识别这个标记后,会去请求标记中所带的广告投放方的平台接口。对应接口拿到请求后,会根据不同的用户类型,下发不同的广告,最终实现千人千面的广告效果。

关于新知

随着行业数字化转型加速,线上线下一体化、数字技术与真实世界融合的全真互联时代正加速到来。腾讯云音视频技术导师将在新知栏目中分享在全真互联时代下新的行业趋势、新的技术方向以及新的应用场景与大家共同探索视界,创见未来!

腾讯云音视频在音视频领域已有超过21年的技术积累,持续支持国内90%的音视频客户实现云上创新,独家具备 RT-ONE™ 全球网络,在此基础上,构建了业界最完整的 PaaS 产品家族,并通过腾讯云视立方 RT-Cube™ 提供All in One 的终端SDK,助力客户一键获取众多腾讯云音视频能力。腾讯云音视频为全真互联时代,提供坚实的数字化助力。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2022-09-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯云音视频 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云直播
云直播(Cloud Streaming Services,CSS)为您提供极速、稳定、专业的云端直播处理服务,根据业务的不同直播场景需求,云直播提供了标准直播、快直播、云导播台三种服务,分别针对大规模实时观看、超低延时直播、便捷云端导播的场景,配合腾讯云视立方·直播 SDK,为您提供一站式的音视频直播解决方案。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档