视频全面数字化时代的到来，让越来越多的开发者逐渐关注音视频技术。随着音视频技术的应用越来越广泛，对于音视频技术的要求也越来越高，既要简单易接入，又要满足高并发、低延迟、高清明眸，少流量……除此之外，与时俱进不断优化技术能力，应对5G、出海等热点需求。腾讯视频云是如何满足多场景的应用，赋能行业，引领视频技术的发展呢?
6月29日，云+社区主办的技术沙龙-“音视频及融合通信技术”在北京成功举办，腾讯云经过多年的技术沉淀，并结合自身的最佳实践，引领了现场近300位开发者关于“音视频”技术的不一样的思考。
以下为本次沙龙的现场演讲摘要：
一、移动直播连麦技术实践
首先聚焦在直播场景下，在当前这个全民直播的时代，连麦逐渐成长为直播领域非常重要的业务场景之一，但是网络往往是不稳定的，那么如何在网络不可控及弱网的情况下来保证高质量的连麦通讯服务呢?腾讯高级工程师蒋磊现场为大家阐述了腾讯在这方面的最佳实践。
连麦直播概述
连麦直播与普通直播的区别在于，后者类似单口相声，一个直播表演很多观众看;连麦直播是对口相声和群口相声，有大主播和小主播，普通观众看大主播和小主播的画面。
(连麦基本原理)
不过往往理想很美好，现实却很骨感。在技术实现上并非嘴上说说就可以了，连麦直播通常会遇到这三类问题：延时、回声和混流。
延时
普通直播的延时主要来自于转码处理过程中产生的百毫秒级别的延时，以及CDN延时。
因为CDN回源的工作机制，在H.264这种GOP编码方式下，回源必须拿到GOP的I帧(关键帧)才能分发。通常情况下CDN引入的延时就有1-3秒，因此要解决普通直播引入的延时，最好的解决办法就是不走CDN。
解决办法就是使用UDP协议，由主播端推流到upload，upload拉流至rtmp-acc节点，然后小主播再从rtmp-acc节点获取数据，同样的，小主动将将流推到upload上并让大主播从rtmp-acc上拉。内部都走高速专线，所以整体延时会很低。通过UDP加速这样的方式，可以实现大主播到小主播之间500毫秒以内的延时。
当然还有一部分延时来自网络。网络总是处于波动的状态，或多或少会有丢包的情况出现。这里的解决方案就是通过 jitterbuffer 这样的蓄水池平滑数据流来实现。因为网络传输过程中会有不均匀的抖动，数据会在 jitterbuffer 缓存一下再给到解码器，在实际直播里可以将 jitterbuffer 设置在200毫秒左右，但是这样又需要处理 jitterbuffer 累积延时问题。因为技术上通过jitterbuffer实现了缓冲，但客观上网络还是抖动的，而jitterbuffer这个“蓄水池”只有蓄满了才会往下一步送数据，所以一旦网络一直抖动，延时就会不断增加，为了解决这个问题我们就必须要修正累积的延时。在腾讯云的LiteAVSDK中，播放器已经做好的累积延时的修正。
回声
回声是另外一个最常遇到的问题，回声通常会分为两类，第一类是线路回声，一般由硬件厂商自己解决;另一类就是声学回声。
声学回声的原理是什么?当原声传到对方扬声器播放之后，被对方的麦克风再采集一次，通过通信线路传回来再次播放，大主播就会听到自己的声音。而且人的耳朵特别灵敏，超过10毫秒以上的回声就能被分辨出，而通信线路的延时往往在50毫秒以上，因此回声必须要做消除。
依上图所示，为了解决回声，将播放器播放的音频数据与麦克风采集的音频数据进行波形比对，反向把波形消掉，这个过程就叫AEC。腾讯云已经AEC功能在LiteAVSDK中内置，开发者无需再额外编程，可以直接使用。
画面混合
画面混合分为客户端与云端，客户端即大小主播相互之间要看到的画面，有两个部分，一个是自己本地的预览，另一个是拿到的对方数据画面。本地预览相对比较简单，只要播放器支持多实例就可以搞定了。
在云端，混流的模块从upload拿到数据之后按照设定的参数分层叠加，再通过CDN分发，就是云端混流。云端混流可以极大减轻客户端播放的压力。腾讯云可以同时最大支持16路混流，输入源可以是纯音频、视频、画布和图片。
腾讯云连麦直播实践--MLVBLiveRoom
在过去的几年里腾讯云使用了非常多的技术手段来解决连麦中遇到这些问题，并且将这些技术方案打磨好，实现了MLVBLiveRoom方案。
MLVBLiveRoom基于LiteAVsdk+IMSDK，结合腾讯云云直播和云通信IM服务，从普通的直播，到连麦直播、跨房PK都在一个组件里直接搞定;通过在腾讯云的云端提供的房间管理服务，普通开发者不需要再考虑过多房间状态和房间管理的细节;同时基于优图实验室的P图技术可以实现人脸AI特效及视频动态特效;并且它的接入做得足够简单，普通开发者半天时间就可以跑通整个流程。
除此之外，MLVBLiveRoom通过仪表盘数据把底层的音视频数据回调给开发者，开发者可以通过onNetStatus拿到直播过程最直接的数据，从而更方便地实现线上业务的监测与运维。
除了MLVBLiveRoom之外，为了解决连麦直播中普通观众的上下麦平滑切换问题，腾讯云还实现了TRTC低延时大房间的方案，让主播和观众们都统一加入到同一个低延时大房间里面，每一个用户都通过UDP的方式推流和播放，这种方式可以实现极低延时，主播之间最低可以到100毫秒，普通观众的延时可以控制在1000毫秒以内。
二、腾讯云直播PCDN加速方案
直播场景音视频的流畅度直接关系到用户的体验感受。腾讯云P2P是业内领先成熟的P2P产品，其中多个产品线已经成熟，现在已经推广到斗鱼、企鹅、电竞、英雄联盟等各个不同的平台。云+社区技术沙龙请到了腾讯XP2P负责人张鹏现场为开发者带来了《腾讯直播PCDN加速方案》的分享。
XP2P简介
P2P简单而言，就是你有我有大家都有的东西，我们可以通过网络相互连接来分享之。P2P架构体现了互联网架构的核心技术，因此这种概念被描述在RFC 1里面，可谓由来已久，是早期互联网建设者心中最梦寐以求的架构。从2014年到现在经历了5年的打磨完善，产品也非常的稳健成熟，覆盖Android、IOS、H5、PC等各种平台，它有更多的节点进行加速，延迟也是等同于CDN甚至优于CDN的起播速度，在S8赛事期间峰值达到8T，经历了大规模的直播活动的检验，同时也见证了flash由盛转衰的过程。
XP2P产品功能
腾讯云XP2P，是为了满足直播需求的带宽和延迟而开发出来的。技术上，首先P2P所有的节点都要有数据一致性。对于视频来说就涉及到视频流的切片。过去的技术是无法在原始直播流上进行切片的，现在切片操作对直播流无任何损害，完全不修改它里面的mux信息和codec信息。
这种方式跟FLV流合成一体，P2P的数据可以直接交给播放器，对视频内容的侵入性可以做到非常完美。用这样的方式还可以实现自适应码率，是比HLS、Dash还要领先的技术。
P2P的客户端首先要做穿透。当前的互联网有NAT(网络地址转换)，就是说公网地址不够，局域网上用内网地址在发送请求的时候，加一个断口标识这个请求。这带来的一个问题是A知道B的地址但是无法连接，会直接被NAT阻止。
STUN协议是P2P打洞建立起连接的核心协议。进入互联网之后之后STUN有一个连接图。首先向STUN公网连接，如果没有收到则说明对方有防火墙，如果收到了就可以看公网地址和内网地址是否一样，如果一样说明前面没有NAT，它是公网地址。接下来向服务器发一个包，让服务器换一个IP地址给我回包，如果收到的话就是一个真正的公网地址，如果没收到是因为前面有一个防火墙。
如果公网地址跟内网地址不一样，说明里面有一个NAT。首先请求原来的服务器换一个地址回消息。如果这个消息收到了就是公网地址，收不到的话说明是一个限制性的，或者对称型的。接下来就是由STUN再去请求，注意这个请求是用同一个内网请求，然后看返回的地址和第一次返回的官网地址是否一样，如果不一样的话就是对称型的;如果一样接下来需要再探测是ID限制型还是端口限制型，然后再朝这个服务器换一个端口回消息，如果能收到就是ID限制型，如果收不到消息就是端口限制型。
做P2P的时候不应该探测带宽，因为这会发很多包，对带宽来说是一种浪费，所以应该使用自然探测。还有一点，P2P要使用TCP剩下的带宽，要公平竞争，而不是肆意抢占TCP带宽。因为TCP存在着启动慢、拥塞控制差、抗抖动差、重传歧义等问题，相比之下XNTP就具有快速启动、基于合理建模的数学公式的速率控制、以及丢包率反馈传输速率、双序号包索引等优势。
XNTP的Pacing发送可以选择均匀发送，一个RTT是40毫秒，发40个包，每一毫秒发一个包，这样对路由器非常均匀，就可以更少丢包的同时把网络利用上去。
XP2P的应用场景
对于P2P的应用场景，无论是直播、点播、文件都是适用的，文件适合大文件的分发。对于4K视频加速，有P2P的助力，4K体验会更胜一筹。尤其对于大型直播活动比如说赛事、春节联欢晚会，是非常适合P2P来提高质量节省带宽的。对于短视频、常规视频，更是P2P加速的强项。对于大规模、大文件的分发也可以用P2P，其原理类似点播视频的P2P。
P2P接入也非常简单，先是注册腾讯云在云官网开通，通过腾讯云的官网下载SDK并接入，虽然不似某些云厂商吹嘘的一行就接入，但是花个10行，也是能够完美接入的，然后测试上线然后运维，非常简单，还会有专人对接。
XP2P的未来与展望
腾讯云X-P2P某种意义上实现了多播协议，即优化了网络质量，又降低了网络的负载;而456(4K、5G、IPv6)的到来，将会使X-P2P进一步发挥能力和得到更广泛的应用;区块链的底层所使用的P2P技术和腾讯云X-P2P有异曲同工之妙，然而libp2p除了搞了一堆不必要的概念，还没有看到怎么接触到穿透的核心技术;边缘计算也将依赖稳健、安全、高效的P2P技术底层;XNTP传输协议如果再优化一下，甚至将可以和quic相提并论;最终，X-P2P可能回归最初的梦想，在互联网上产生出彻底去中心化的服务模式。
三、腾讯视频云海外直播系统架构设计与最佳实践
近几年国内视频直播市场逐渐疲软，越来越多的厂商开始涉足海外直播。云+社区技术沙龙请到腾讯高级技术专家，海外直播技术负责人胡仁成老师分享《腾讯视频云海外直播系统架构设计与最佳实践》。
海外直播系统在应用软件层面跟国内没有太大的区别。直播系统架构包含三大块，一是公有云和网络基础设施的建设;第二是在此基础设施上架设软件系统，实现直播流媒体的分发;第三，在已完成的系统上更深入化优化。
海外网络与机房建设
当前腾讯云在全球的网络布局从地域分为三大区，北美、亚太(香港、新加坡)、欧洲(德国)。海外大概接近2千家运营商。要完成这2千家运营商的互联不可能每家都进行直接互联。
按运营商的级别可以划分为三类Tier1、Tier2、Tier3。Tier1是跨大区跨州互联的，Tier2是区域互联的，Tier3是国家内部覆盖，一般是面向终端用户提供网络服务的运营商。在海外还要布局很多加速点，如下图所示：
海外直播系统建设
直播需要低延时、低卡顿，根据这个原则所有的流系统不能部署在同一个地方。因此需要采取去中心化的方案，在已有DC的机房都会部署一个源站系统。
每一个源站都会包含流媒体接入的能力，同时部署转码、录制、截图、存储和CDN分发能力。去中心化的设计方案很适合本地化直播服务，主播的流推到最近的源站，质量更好。
下面的问题是状态同步，比如说巴西的主播推了流上来，中国的观众看的时候怎么样找到巴西主播的流在哪?挑战很大。
第一个要求是双活，我们自研了一套状态组件，去满足我们提出的一些能力的要求。其中，我们选择通过间隔心跳保持数据同步的最终一致性，它有一个容忍的尺度和阈值，这个根据业务特点去调优。
第二个要求就是同步方案，这里状态同步的思想遵循95%本地分发的原则，9个大源站的状态并不是互相同步。通过挑选集中点，把海外其它7个源站同步到香港，然后再从香港到国内;小的源站查一下香港就可以，这样减少了设计开发的复杂度。
去中心化设计又引入了另外一个问题就是如何实现跨区拉流，有5%的用户要看美国的流怎么办?这时候就要保证这一整条链路的服务质量，状态一定要准;状态同步过去之后还要保证回源链路的稳定性，在核心链路上铺设回源专线，走腾讯云的内网专线。
这是一个标准化的一体化方案，这种方案的特点是双端用户自己控制，只需推RTMP流过来由腾讯分发，支持RTMP、DASH、HLS通过不同的码分发。另外，我们也支持用户自建源站，腾讯云进行回源分发，这个在新闻资讯分发场景比较多。
海外直播另一个特点是对版权保护的需求。腾讯云也提供了一个基于iOS和安卓系统的DRM方案，支持Widevine和Fairplay。
精细化运营
系统做好了就相当于做到了90分，后期要通过精细化的优化和运营实现95、99分。精细化运营也涉及一些问题。
这些问题总体分三类，第一是腾讯海外直播系统自动化运维、监控的能力的构建;第二是如何解决海外调度复杂的问题;第三是如何解决网络设施落后的国家跨区传输以及最后一公里的视频流传输和优化问题。
首先是全方位监控系统。腾讯云能在一秒或者五秒以内感知到某个业务流量突长，并且能够在增长的过程中自动化扩展更多服务节点或服务带宽给它承载。我们的监控能精细到每个国家每个运营商的AS号，看它的丢包率，延时等技术指标，然后找团队去优化。在应用层面我们有自动化的监控系统能够实时发现哪些机器宕掉了，实时把异常节点剔除掉。
第一，如果巴西的丢包率很高，为了解决TCP由于丢包导致传输速率不稳或者下降的问题我们选择采用Quic方案。我们设计开发了一套TCP和QUIC互相转换的协议插件，这里接受用户的RTMP流，然后转化成Quic传输到美国的源站，再把它剥离成RTMP推到美东的源站。这中间用了Quic加速，优化了中间链路弱网的问题。上行优化之后，卡顿率从6.5%降到4.8%。
第二步优化了下行回源链路，下行回源也用了类似的Quic代理做了协议转换，卡顿率从4.8%降到3.6%。
做最后一公里边缘协议站的优化时，腾讯自营了一套类似于BBR，但克服了BBR的缺陷的方案，叫QTCP，在最后一公里优化了弱网传输的问题，整体卡顿率降低了20%。
另外，海外直播系统设计还需要考虑在综合成本的限制下取得一个边际收益的最大值，这是我们目前做海外直播的一个重要的思路。
四、实时音视频与PSTN结合的解决办法
如今，融合通信技术显得愈加重要。融合通信技术具体是指什么?云+技术沙龙请到腾讯云通信平台高级工程师颜学伟老师带来《实时音视频与PSTN结合的解决办法》的分享。
实时音视频与PSTN融合的背景
实时音视频通信(RTC)最主要的特点是“实时”，一般分为三个级别，延迟3秒以上是伪实时，1秒到3秒为“准实时”，真正的实时是1秒以内。腾讯云的实时音视频可以做到300毫秒以下。
常见的QQ语音通话和视频通话，两个QQ客户通过外网发起语音通话，一般处理会分为两个部分，一个是信令层的处理，一个是码流层的处理。
信令层主要用于通话的建立、连接、资源的准备，并协商码流编解码类型等相关信息，码流层专注于音视频数据处理。而实时音视频要做到比较低的延时，我们在传输协议上直接选择UDP，因为UDP虽然不可靠，但是它的性能比较高，相对于TCP少了三次握手和四次挥手。
因为外网的环境时好时坏，UDP又是不可靠的，在Internet传输音视频数据时容易产生抖动，所以我们需要一个抗抖动的能力。当网络质量不好产生丢包时，我们也需要一个抗丢包的能力。而且外网的质量波动比较大，也需要一种自适应的方式来动态调节发送的码流，称之为流控，就是随时检测主被叫双方接收的包量，来计算丢包率、延时和码率，用于来控制发送端的采样率和发送的码率，当时网络质量不好时，我们可以把发送端的采样率和码率降低，减少发送的整体包量，进而减小网络的拥堵。网络质量好时，我们可以提高发送端的采样率和码率，增加发送的整体包量，会让接收端有较好的语音质量。
RTC与PSTN差异
首先我们要看一下两者的差异。实时音视频我主要以QQ语音通话为例，刚才也说过一个完整的音视频处理是要分很多步的，音频采集、预处理、编码、网络传输、解码和播放。网络传输协议上，QQ语音通话是使用自己的私有协议，而PSTN使用的是标准的SIP+RTP协议，这是语音运营商采用的标准协议。
QQ支持的编码有很多，有SILK、AAC、OPUS等，但对于PSTN，使用SIP_TRUNK方式对接的语音编码，目前三大运营商，电信、联通和移动，仅支持G711A、G711U、G729等编码。
RTC采样率都是16K、48K，PSTN一般为8K。
组包间隔，语音数据包发送的时候需要以一定的时间间隔来周期进行发送，比如说像QQ支持20毫秒、40毫秒、60毫秒的间隔发送，PSTN基本上是20毫秒。
语音质量，对于VOIP会有很多相应的语音的优化手段，但是PSTN是专用网络，网络质量相对高，丢包较少，优化的手段也比较少。
RTC除了1对1绝大多数场景是支持多人，比如说纯视频、纯语音通话可以支持客户端混音和服务端混音，但是手机端基本上是1V1。多人会议是多个人，但是手机端是不支持同时接收多路码进行混音的，必须要混好成一路后，才能下发给手机。显然这是两者之间的差异。
融合方法
有这么多的差异，我们有没有方法把两者结合起来呢?我们就要找一个突破口——求同存异，适配融合。
刚才说的是差异的地方，有没有相同的地方呢?PSTN经过长时间的发展，可以把PSTN专用网络的信令流和数据流通过SIP_TRUNK的方式在Internet上面传输，这就是一个相同的地方。这个地方存在的突破口，存在可以融合的点。剩下对其它不同的部分进行融合适配，即对音频码流和信令协议进行适配。
我们融合的方式的实现有两种，第一种是让QQ客户端去适配PSTN的差异，第二种是让PSTN去适配VOIP的差异。首先PSTN是国际通用的标准，让它适应VOIP众多的编码和私有协议，那么现在的手机设备肯定要更新升级，这显然不大现实。另外一种就是让QQ去适应PSTN的差异。QQ同样有历史包袱，他发展了那么多年，如果支持RTP和SIP改动也很大，开发周期也是非常漫长的。即然这两种方法都不行，我们就想到新增一个中间模块去分别适配VOIP和PSTN的差异。这个模块我们称之为适配层，可以放到Internet上，让VOIP和PSTN协议互转和码流互转。适配层有两个主要功能，一个是对信令的适配，还有一个是对码流的适配。
最终系统架构图
最上面一部分是实时音视频对外提供的OpenSdk，它跟QQ的音视频内核是一样的，只是去掉了QQ那些特殊的业务逻辑，它目前支持安卓、IOS、windows、web SDK，基本上是全终端。客户端信令发向后台互动直播系统，首先经过信令处理模块App，进行机器调度分配要经过Info，由于我们整个过程都是要动态自适应调整，会有一个流控模块。然后这个信令会转到一个信令适配模块，我们叫会控。而码流的适配、编码的转换，有一个模块就是混音。因为手机端不具备多路混音的能力，所以我们必须在服务端进行混音，这样将多人的码流混成一路发给手机端，手机端就能听到多个人的声音了。
下面那部分进入PSTN网络，会控把QQ私有协议转换成内部私有协议，通过PSTN策略进行一系列的分配策略，再通过处理信令的sip_server将内部私有协议转换成标准的SIP协议和运营商的SIP_SERVER相通，同理将对应的码流通过混音和proxy转成标准rtp码和运营商媒体Svr相通。
重点说一下混音，从QQ的私有协议转到标准的RTP协议还算比较容易，但编码转换就要复杂很多。因为手机端不具备混音的能力，所以我们这部分不像VOIP客户端可以客户端混音，手机端必须要在服务端混好才能下发一路码流给手机端。我们是采用服务端混音，如有多个VOIP进行互相通话的时候会同时发多路音频流，由外网传输到混音后台，首先会选路操作。选路是指在多个说话的人里面最多选几路语音流来进行混音操作，比如说QQ语音通话最多选六路。主要原因，第一个是说话的人多了大家听不清楚，第二人就是选择的语音流路数越多越消耗服务器资源，这样一台服务器就支持不了多少人了。选路之后，就要进行解码，解码完再进行重采样，然后再进行混音，之后就要编码，然后再通过Proxy进行传输最后会传输到运营商的媒体SVR，最后到运营商网络，就可以下发到手机端，这样就实现了手机端也可听到多路语音的功能。
系统优化
因为是语音通话，所以系统上线之后，在语音上面增强必不可少。手机端的语音增强手段比较有限，因为它在运营商的公共网络相对外网质量好很多，少抖动和少丢包。在VOIP端由于直接是外网，所以要做的语音质量优化比较多。比如说语音采样之后，会进行回音消除和降噪。为了避免抖动会引入jitterbuffer，jitterbuffer有一定缓存包它有一定大小，如果在缓存范围外的丢包，则要通过PLC进行补包。还有为了节省带宽我们会做VAD，如果VOIP端长期不说话的时候，我们可以不发完整的静音包，可以会发特殊的EOS包，包大小会非常小，这样可以节省带宽。网络质量是随时动态变化的，所以我们要进行自适应调节，以2秒为一个单位来，实时统计一下当前网络的超时率、丢包、抖动情况，综合调节客户端的采样率和码率。
因为是实时音视频，所以低延时是重中之重。在外网传输，延时大部分引入很多是在媒体SVR的分配上面。如在不同运营商的延时会有10到25毫秒延时，而且不同的运营商某些城市可能会有丢包，不同的机房网络延迟差不多是20到35毫秒，如果直接外网，易抖动、质量不稳定。对于这些问题，我们可能通过调度分配来解决，我们尽量将媒体SVR分配到同一运营商，尽量分配到同机房。对于有条件的地方可以直接专线连接。
抗网络丢包有两种方法，第一种是ARQ自动重传。我们每一个媒体节点都是采用UDP来传输且每一个媒体节点都会缓存一定数量的音频包，每个音频包里面会有一个序号，接收客户端收包时会根据包中的序列号判断是否是连续的，如果不是则有丢包，此时会去它的前一个媒体节点问一下，缓存中有没有这个包，有的话就直接重发一次，没有的话，它就再向前一个节点问一下，如果所有中间节点都没有就会一直问到发送端，发送端再把这个包再传一次。ARQ明显缺点是增加延迟。
第二种是FEC，发送端在发音频包的时候，可以多发几个冗余包。接收到如果发现音频包丢了，而冗余包没有丢，则会尝试使用冗余包把音频包恢复。增加FEC也是动态的，当网络质量不好会多加一些冗余包，反之则会少加一些。
最后一个是提高系统可用性。只要是大规模的应用或系统，这是必不可少的要解决的问题，解决这个问题简单来说就两个方面，第一个是增加冗余资源，第二是实现自动切换。机器冗余可以多运营商部署、多机房部署，多地部署，自动切换则是死机时可以自动切换、IDC异常时可以自动屏蔽出问题的IDC、自动屏蔽出问题的资源等方式。
五、音视频AI技术落地实践
现在AI技术广泛应用在各领域，音视频领域就是典型。云+技术沙龙请到腾讯视频云高级工程师孙祥学老师带来《音视频AI技术落地实践》的分享。
视频+AI碰撞的结果
视频+AI的第一种应用是极速高清。极速高清是在不降低视频质量的前提下压缩视频码率，降带宽，降成本。它跟AI的结合点在于智能场景的识别。传统的编码是不区分视频类别的，而极速高清能借助AI识别出视频分类和场景针对性优化。
第二种应用是云剪辑，一边进行视频编辑、贴片、生成字幕等处理，另一边可实时预览，处理完之后可以导出分发到各个平台。
第三种应用是视频的智能识别和分析，主要包括智能识别、智能编辑和智能审核。
智能识别是把视频里的目标人物识别出来，把语音识别成文字，把视频里面所有出现的文字识别出来，还有识别出来LOGO、台标之类的物体，等等。
智能审核，包括涉黄、涉政、涉暴画面的检测和字幕审核、语音审核。
智眸：视频智能识别和分析平台
腾讯智眸智能媒体生产平台。它包括基础服务层、AI引擎层、媒体处理层、基础应用层、基础产品层。
智眸衍生出来三大产品线，包括智能识别、智能编辑、智能审核。我们在云官网上有相应的API接口，可以组合调用来满足自己的实际应用场景。
智能识别系统的架构分四层，有对外接入、逻辑处理、模型识别和数据层。这个系统大概的执行流程是：首先进行用户库管理，包括人脸入库、敏感词的管理;接下来可以验证入库目标人物是否支持检索;第三步是提交视频处理任务，分别进行截图处理、音频处理、识别上报，策略层是基于配置和上报的数据进行整合过滤，然后返回结果。
同时要做公有云、私有云的一体化部署，因为很多的客户希望敏感资源不要上公有云，所以有私有化的需求。
视频处理也是系统的核心，这套多媒体处理框架，从(PPT左边)是文件输入(包括点播、直播、本地文件)，一般的流程是解封装、读取压缩数据，然后解码分别生成视频截图和音频PCM数据。因为对端ASR引擎对输入是有要求的，所以要统一做重采样、转码、分片等。完了把所有的截图、音频分片放到各自的线程队列里去，然后每张图要同时进行所有的识别，然后把所有的识别结果进行统一上报。音频是独立的，按固定间隔发送给ASR引擎即可。
结合实用场景，还要做一些应用场景优化。
腾讯优图人脸识别有一个入库的过程，即把所关注的目标人物人脸图片通过特征提取入库。人脸检索处理衍生出来三种场景：建库检索是第一种;第二种是历史扫描，比如要去从前面处理过的视频中找出之前没有入库的目标人物;第三是无库检索，像监控场景中需要找到某人第一次出现到最后一次出现的时间点。
还有几点场景优化，因为视频是连续的，假如说现在某某出席某某会议，我如果知道这个名字在视频语音里面出现，那他在下面视频里出现的概率会比较高，我会进行一个ASR参考降低附近人脸相似度过滤阈值。OCR也是类似的，某个会议上有一个人截图前面出现印有该目标人物人名文字的台标，也可以类似处理，视频中只看到侧脸导致相似度分值比较低，我可以根据OCR人名把人脸相似度过滤值降低进行召回。再例如，一个人出席某个会议，从进入到结束不是一直看到正脸，可能是侧脸，正脸、侧脸，在库里扫描的相似度分值可能是67、98、78。如果我连续时间参考序列上出现一个分值比较高，两边比较低的场景，我会把两边分值较低的时间点召回。
还有一点是无缝升级处理，人脸检索引擎也会迭代，之前的库提取出来人脸向量可能就用不上了，因为在新的库里面向量维度都变了无法检索，没有参考意义，怎么样让用户无感知做到无缝升级呢?我们把数据层做了多版本化的处理，我升级的时候用新版本库，把之前旧版本库提交的图片去做一次提取，一旦两个库满足一致性之后，即可支持新版本人脸库的检索。我先做一套类似于伴随系统，两库同时跑，提取完之后做一个策略切换热重启即可完成升级。
语音识别也作了前置处理。对于点播视频先做一个离线的VAD处理，把语音活动部分检测出来，送到引擎端识别，减少静音包识别带来的网络的负载，并可进行多线程识别加速。
按照固定间隔截图，全部丢给后端引擎识别，后端引擎的压力会很大。所以我们做一些过滤，对比多种图片相似度检测算法，做一个简单的像素值的统计直方图即可以达到过滤效果，且速度上有一定的优势。还有指定区域处理，在引擎识别之前先裁剪我关心的那部分，缩小文字区域检测面积，最后会快很多。
对于视频集锦的处理，比如进球集锦，通过R-C3D模型处理后会输出很多可选时间段，加上非极大值抑制处理，再结合VAD处理让剪出来的片段平滑一些。
新闻拆条是把几十分钟视频所有的新闻片段都拆出来做分发，方便互联网用户点击。处理逻辑是把关键帧检测出来，检测视频是否切到导播台，再做一个人脸检测，看导播台现在有多少人?如果有0个的话我就认为是转场，1个的话就可能是引入新闻。基于两个模型的综合，最后根据人脸检测得到一个时间序列，这样就自然把片断拆出来，30分钟的新闻当中每个新闻事件做一个拆条，从而进行短视频的分发。
人物拆条，某个领导人出席某个会议，我只想把我自己出现的那个片段剪出来。片头片尾拆条，我们在视频软件上可以看到，自动跳过片头片尾，一般是vip特权，现在大部分是人工处理的，如果能自动识别片头片尾会降低很多的人工成本。
应用场景
视频+AI的应用场景有：
媒资管理，做识别之后知道哪些视频里面有哪些明星。
视频搜索推荐，识别之后知道这个视频属于哪一类，是娱乐类还是搞笑类等等。
直播流监控、电台监控，就是涉黄、涉暴、涉政的检测，如果直播流有一些敏感的东西可以直接断掉。
视频审核。
跳过片头片尾。
实时字幕。例如把主播的语音直接识别出来生成字幕加入到直播流中等。
尾声
此次现场开发者的热情超出了我们的想象，相信这样一个干货满满的技术沙龙，一定给现场的所有参会者都带来了新的思考。让我们更加有理由期待，未来，音视频及融合通信技术，一定会更加深入到我们的日常生活中来。
现场花絮
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
