李海琦:如果问他(直播嘉宾卢林),他肯定说我经常给技术挖坑,还好,主要的坑来自于需求的变更,比如客户需求变化,或者根据数据分析做出变更,不过现在的技术会在架构上做得更加灵活,相对以前来说,应对变更会好很多。
卢林:我们专门为产品填坑。给大家分享一个故事吧,我们部门团建的时候,小伙伴们会抱着一块石头扔向海里,然后大声喊:产品经理我恨你。
其实,从技术的角度来说,我认为只要做得足够灵活或者兼容,任何一个产品形态都是有可能实现的,大家比较抵触的是产品没有意义,而不是说在技术上不能实现它。李海琦:有你这句话我就放心了。
李海琦:我觉得产品经理要懂技术,大概有三个原因,一是只有懂技术才能跟后台或者开发者沟通得了;二是当需求来了,作为一个产品经理要判断这个需求能不能做,做起来大概多长时间,并不是所有的需求都要去接;三是只有懂一些技术原理,以及技术的演进方向,才能对整个后期产品的迭代做出更好的规划。
卢林:我觉得工程师肯定要具备产品思维,一方面,当你知道一款产品的发展套路后,你才可能针对后期发展在技术上做一些兼容、设计出更加灵活的接口。另外当你了解了产品,你才能更懂用户需求。作为一名开发懂用户需求非常重要,我们开发者跟人接触的机会很少,主要通过一些数据去了解用户的心理,然后在技术上做一些调整,比如,你发现用户对某些功能很感兴趣,然后在这些方面做出优化,并不是说所有的需求都是产品提的,不信你看看现在做得好的产品都是技术出身。
李海琦:作为云服务厂商,客户对我们最基本的要求就是稳定,满足稳定性要求之后,针对这种大型赛事,最根本的要求是低延时和高清;另外,我们对极速也做一些处理。基本上我们所有的工作都要围绕这几点去做,但是这几个点之间要做权衡,比如满足了第一点,第二点就要差一些,满足了第二点,第三点可能就要差一些,我们需要做出一个最优化的选择,满足客户需求。
卢林:其实对于任何一个直播 APP 来讲,大家关注的一般都有三点:延时、卡顿、清晰度,但是这个东西就很像大数据里边的 CAP 模型,往往你只能够达到其中的两项,很难在三项里头达到一个最优的解。这里又存在一个极限条件,极限条件就是用户的网络状况,很多时候我们需要做的就是根据用户的网络,给用户更低的延迟,更清晰的视频和更少的卡顿。
卢林:对于任何一家直播 APP 都有几个明确的关注点,第一是系统的可靠稳定性,央视这回提出的要求是 7×24 工作;第二,这个服务对它的系统是无侵入性的;第三,你的评分和质量标准在同类竞品中是最优的;最后也是最重要的一点,央视希望能够做私有化部署,现在越来越多的服务会选择云服务,但是有一些特殊的服务还是希望做私有化。举个例子,虽然银行可以提供保险柜服务,但是有些人还是希望保险柜放在自己的家里,腾讯云能够满足这一要求是因为设计这套系统之初,我们就遵从了所有模块不直接依赖的原则,即基于网络来调用整个接口。
李海琦:通俗点讲,高清直播服务就是根据画面的变化动态调整编码参数,让用户以更低的带宽成本,或者客户以更低的带宽成本获得更高清的画质服务。
卢林:高清直播原理就是把码率放在该放的地方。我们知道,一段视频的画面,有时候是静态的,有时候是动态的,当视频是静态的时候,它需要的码率往往比较低,如果视频在运动,它需要的码率比较多,因为这个时候,画面变更比较多,我们需要做的是静态的时候压缩画面的码率。
但是,这不是一个简简单单的压缩,比如对某些图片的位置是不能压缩的,如果把图标都压缩的不清楚了,用户是很有感知的,通过对用户视觉进行研究,我们还发现用户对低频的信号比较敏感,对高频的信号不太敏感,所以要做的是强化低频信号,弱化对高频信号的处理。
另外,对于动态视频,往往需要增加码率,但是不能一直增加,而是应该尽可能小的增加码率,因为码率太多了,对用户的网络就会有要求。在这个方面,我们会用到运动补偿,在运动补偿的方向上我们会做一些数据压缩,保证整个视频的码率足够小,而清晰度不会受到明显影响。
卢林:运动补偿更多的是算法层面的问题,我们都知道,一张图片跟另一张图片之间假设是运动的,运动的可能只是其中的某一个实体,我们可以把变化的区域框定出来。因为还有很多是不变化的,不变化的,我们只需要记录最原始的基础量,变化的部分我们记录变化量,我们需要压缩的就是变化量。
那变化量的整个运动是什么情况呢?哪一部分变化比较多?你可以在编码器里进行一个划块处理,对其中比较高频的部分进行一定的忽略,对低频的部分进行一定加深,通过这个 DCT 变化模型,忽略掉不影响清晰度质量的成分,保留其中最主要的成分。大概就是这样,如果你有兴趣,我建议你去看一下 SAT 算法和 STAT 算法。
李海琦:我们从年初就开始做高清技术服务了,为什么要做这件事呢?我们发现直播行业对带宽成本的支出非常看重,因为带宽成本在整个运营支出里占了相当大一部分,为此我们提前做了很多技术储备,在保证用户观看质量的情况下,把带宽的成本给降下来。
二三月份我们的服务开始接入一些泛娱乐直播,主要是游戏直播,比如今年比较火的吃鸡游戏,之前的 LOL、王者荣耀等,我们在跑这些模型的时候不断做优化。三四月左右,我们觉得这项技术可以在体育场景里落地,于是开始做大量准备工作。比如,我们从网上爬了一些足球类的视频,针对不同的场景,比如说远镜头、近镜头,足球的运动轨迹等做了一些特定的学习模型,但是这个东西拿出去用户不一定认可,虽然在游戏里面跑的还不错,于是 4 月份我们决定实践一下,接了第一家足球场景的落地客户——中超,后来又接了英超。
我们发现中超和英超的节奏是完全不一样的,英超的节奏比较快,中超的节奏相对来说会慢一些,我们觉得这一块是需要优化的,因为世界杯的队伍来自于世界各地,节奏会有不同,所以在这一方面我们做了大量工作。
卢林:我刚才提到,央视要求的是私有化,对我们来说,挑战就是要自己去装服务器,装机布网络。在世界杯期间,我们发现一个很有意思的现象,当我们接入央视的时候,来流的时间戳是连续递增的。
做直播的都会知道, DTS、PTS 出现反转或者 DTS 发生跳变是很难处理的,那么为什么 DTS 会发生跳变呢?因为上端出流的是一个硬件设备,这个硬件设备是双击热备份的。当其中一台机器宕机,它会立马切到另外一台机器,这时候两台机器保证时间的连续性在业界是一个不可解决的问题,你只能够减少两者之间的差距,不可能实现完全精准的同步,时间戳就会发生一个跳变。那时间戳发生跳变会有什么样问题呢?当把这个流下发去之后,用户侧根据这个时间来拉取分片的时候,如果时间跳的过多,就有可能导致在某一档节目当中穿插了另外一档节目,用户看到的就是一个串流。
我们部署完的第一天就发现了这个问题,但是当我们第一次提出这个问题的时候,很多人都不相信,为什么呢?因为整个链路运行的时间比较久了,也没有用户投诉。很巧的是,当天晚上就有用户上报了这个异常,而且这个异常还比较严重。
为什么我们可以第一时间发现这个问题?首先我想问大家一个问题“你对程序当中语法错误和语义错误是怎么样看待的?”语法错误,举个最简单的例子,如果大家用过 C 语言库你应该知道,Memory copy 和 Free 两者是有明显的差异。比如 Free 里面你可以传入空指针,它会做一个处理,但是像 Memory Copy 你传入了空指针,它真的会死给你看。为什么?在我看来这就是一个语法和语义的兼容性问题。语法上的错误可以兼容,但语义上的错误绝不可以兼容,不然你就在第一时间死给他看,让他明明白白知道自己错在了哪里,让他去改。
卢林:深度学习主要用在场景的识别。就是输入一个视频应该尽快确定它的场景,之后你才会根据场景通知编码器,编码器才会根据场景选择一个最优的编码参数。这里分了两节模型,第一节模型是一个大的分类,比如足球、篮球;第二节分类,比如在篮球里面,视频属于什么场景,运动剧不剧烈,要进球了还是在跑动的过程当中,这里我们用的是 CNN 加 RNN 的方式识别视频场景。
其实大家都能知道,CCN 已经很成熟了,我们要做的就是让它在普通的 CPU 上能够有更好的表现,即能够使用更低的 CPU,得到更快的识别结果。在这方面,我们会用到一些其他的技术,不仅仅是图片识别,我们都知道在视频里面,很多图片都是相似的,我们会把相似的图片过滤掉,那怎么过滤掉这个部分呢?有兴趣的同学,我建议你去看一下特征值识别,因为在这种场景下,特征值识别是非常快的。
李海琦:现在直播的技术比较成熟,无非会遇到一些跟终端适配,或者一些客户的特别需求,在保障用户稳定性方面,我们是基于整个腾讯云、CDN 侧的,包括我们的出口带宽现在已经到一百 T 了,还有我们的 CDN 节点,全球已经有一千三百多个节点左右,这些是保障直播的基础。
另外,我们现在开始做的一些技术,比如跟视频 AI 的结合,是在为行业趋势做准备,这个目前应用不是特别广,但我相信随着终端的发展以及网络的发展,这一块还是很有潜力的。
李海琦:视频直播在国内已经发展到一个瓶颈期,或者说稳定期了,我们觉得未来大家可以关注一下这几点:一是目前炒的比较热的 5G,我们目前也在为 5G 积极地做一些准备,更高清超清,4K 这些都是有可能的;二是视频互动,这也是一个趋势,前几年直播比较火,从去年开始短视频比较火,接下来可能是视频互动,特别是在网速进一步提升,终端能力进一步加强的情况下,互动视频这一块也是值得关注的;第三是视频的碎片化应用,也是未来值得关注的点。
腾讯云在视频行业,特别是在视频云这块,在国内大概有 70% 以上的客户,因为毕竟我们有多年做 QQ 音视频的技术积累,所以我们也会实时关注整个行业的进展,以及后面新的技术趋势,大家也可以实时关注腾讯视频云的一些产品方向和括技术方向。
腾讯云作为视频云行业的领军者,凭借腾讯丰富的视频,通讯技术经验,结合大数据和人工智能技术,服务于直播、短视频、点播等各领域的龙头企业,为视频行业发展助力。