2016年9月10日,第52期【OSC源创会】在珠海圆满落幕,350余名OSCer齐聚报业大厦,聆听了一场诚意满满、干货多多的技术分享盛会。
本期源创会由5位讲师分别针对5个不同的主题进行分享,为给未能到现场以及参与活动后仍意犹未尽的OSCer更好的了解和学习,开源中国将每位讲师的演讲内容进行了整理,并将逐一发布。干货多多,不容错过!
首先是由腾讯高级音视频架构师郭亮带来的《互动直播技术解密》,主要是对目前主流直播方案的解析,以及依托于QQ音视频的腾讯云互动直播SDK在多个关键技术上的深度优化方案的分享。
郭亮的分享PPT下载地址:http://www.oschina.net/doc/44250
直击现场嘉宾访谈:https://www.oschina.net/question/2886655_2196558
完整演讲内容如下:
开源中国社区珠海的小伙伴们,下午好!感谢主持人把气氛调动的这么欢快,也很开心大家冒着大雨来参加我们的活动,包括现在也有许多不能来现场的小伙伴在线上观看我们的活动直播。
首先,做个自我介绍,我叫郭亮,来自腾讯云视频,07年毕业之后加入中兴通讯一直从事音视频相关工作,包括核心网、媒体网关等相关音视频架构。而后进入了腾讯,近一年来,一直在专注于开发腾讯的直播的一些引擎。
话不多说,我们进入主题。大家刚才应该有看到,我有和观看线上直播的小伙伴打招呼。近一年来,直播被拱上风口。据统计,在过年的一年里,有超过1000家厂商进入直播行业,现在已随处可见各种各样的直播。可以说,直播已经走进了我们的生活。
其实对于直播行业,我们有做一个自己的分析,大概将其分为以下几类:
第一种是传统的语音直播网站,像是YY、9158这些,现在发展依然强劲。
第二种是近两年兴起的游戏类直播网站,像是斗鱼、龙珠、战旗等,也已经探索出一条成熟的直播变现道路,有着不错的用户量和收益。
另外就是传统的视频网站,包括腾讯视频、爱奇艺、搜狐视频等,也推出了自己的直播业务。
还有最近兴起的秀场,像是映客、花椒等,在最近的各个热点话题背后都能看到它们的身影,也成功塑造出许多网红。
此外,像是聚美、蘑菇街、唱吧这些电商、歌唱、炒股类的网站,也纷纷加入了队伍,做跨界直播。
说完分类,接下来正式来聊本期的主题——互动直播。互动直播其实也是不断在演变,最初的主播只是简单回应观众文字类、弹幕类的提问和话题的方式,逐渐衍生出接送礼物、连麦等更具互动交流的形式。到现在,随着VR技术的逐渐成熟,已经有国内外的网站在推出VR的直播,可以说是互动直播未来的一种发展方向。
可能有人会想,既然直播这么火,那也去做一个直播的APP,或者在APP里面加入直播能力。那么问题来了,一个好的直播产品需要清晰、低延迟、秒开、连麦等等一系列的技术特性,我们到底该如何进行技术选型呢?
其实,目前市面上比较流行的是这几种直播方案:
第一种是基于TCP的RTMP,这可以说是相对成熟的一种方案,它的优势是只要浏览器支持FLASH,就可以内嵌播放;但不足的是,在互动直播中2-5S的延时会对体验有所影响。第二种FLV是基于HTTP下载协议的一个方案,在交互上比RTMP会稍微轻便点,但同样存在沟通延迟的问题。第三种HLS是目前直播中比较常见的一种方案,其最大的优势就是手机浏览器是原生支持的,这在移动互联网时代可以说是一大杀手锏;不过它最大的问题是延迟比前面两种会更为严重。还有一种RTP方案,是目前QQ和微信中做实时音视频使用的方案,它的优势就是延迟可以做到很低,控制性强,但它的一大缺点就是在PC和移动端的原生支持都是比较差的,需要做一些SDK的嵌入。
看完这四种方案,是不是发现好像并没有哪种方案是做的特别好的?在这种情况下,腾讯云做了一套自己的直播方案,对各方面有做一定的折中。首先,我们有做一套实时音频的框架,主播和观众可以实现很好的互动,保证沟通的顺畅。而为保证下行的抗损耗能力,我们又接入了OC系统的分发体系。同时,为更好的对浏览器支持,我们做了一套“旁路推流”系统,将音视频流转到RTMP、FLV或HLS等,通过传统的CDN方案推给客户端,实现浏览器原生支持。这样,我们既能实现好的延迟和抗损,也能有相对较强的兼容。
接下来,给大家介绍互动直播方案中比较核心的技术,主要针对几个关键点进行讲述。
1、秒开
举个例子,从下图可以看到,网站的开启速度对于用户留存以及网站自身收益有着很大影响。
在直播当中,秒开的重要性同样不言而喻。而影响秒开的因素非常多,包括自身的影响、和业务侧的影响、以及一些设备方面的影响等等。对于秒开,腾讯云将其分成了两个环节——进房和岀画。在进房这一部分,我们将一些可以提前做的东西提前在登陆的时候完成;另外就是针对设备上的一些启动啊进行并行操作;还有就是和业务侧的配合,像礼物状态的存取、人数的拉取等,做并行处理。而在岀画环节,则设立了后台音视频数据的双GOP缓存机制,后台根据网络上的情况和客户端向Server拉取的时机,智能的选择存取单个还是两个GOP数据,以及智能推送前一个GOP数据还是当前GOP数据,给后面的音画同步和缓存带来联动作用。
那是不是只要做完这些就可以达到很好的效果呢?
然而,并不!因为我们在做完发现后台在推送数据的时候会一下推送两个GOP庞大的数据,对带宽的压力极大。因此,我们又做了一些其他的策略来保证稳定性,包括推流速度的控制以及推流数据的QoS保障机制。我们不固定速度推送,而是根据用户当前的数据量和网络情况自动选择合适的推送速度,降低丢包,再加上保障机制,给用户稳定的交互。
下图是腾讯云和一些竞品的交互数据:
2、流畅无卡顿
这是比秒开在直播过程中接到用户反馈更多的核心要素,事实上,影响卡顿的环节很多,包括采集、播放等等,而这其中又分为功能方面和网络方面上的优化。在此,则主要讲的是网络上的优化。其实上行不稳和下行不稳都会造成卡顿,对此,腾讯云从以下几个方面进行解决:一是依托于多年的用户积累,及海外多点部署的服务器,能及时的进行针对性扩容,保证接入。二是采用“三级火箭调控”机制,根据用户卡顿时间进行自适应调整。三是同一事件往往有各个平台的人在进行直播,大家均在竞争网络下进行工作,需要有优异的抢带宽能力,腾讯云基于UDP的传输方案在此时则具有明显优势。
3、低延时连麦
低延时连麦是互动直播中的重点也是最基本的要求,腾讯云同样是基于多年的音视频积累经验,转换了一套解决方案。低延时连麦对音视频的基础能力要求较高,包括对语音的回声消除能力、视频的原音编解码等能力。
说到回声抵消技术,可能有做过IOS开发的同学会说,IOS上自带有回音抵消能力的,为什么不直接用呢?其实,大家真正去用的话,回声抵消真正要做细致的话,需要考虑很多东西。腾讯云在信号对齐、机型设配、音频防抖上都有很大的优势。
此外,我们在视频上针对编解码也做了许多优化,包括视频压缩质量的调节、低码率画面下编码方式的调节等,使得在视频编码的性能和效果上,都有一定的加强。目前已经放开了500多款移动设备的硬件编解码。
4、开放式框架
开放式的框架指的是无论是在采集层还是处理层,可以实现既可以使用我们设定的,也可以自定义,包括自定义实时水印、美颜、音效等,更符合个人需求。
5、运营与网络模拟
作为一个开放的SDK,对于运营能力是非常重要的。当你的SDK接入了几百家的用户,如果没有出色的运营能力的话,你很可能会转变为疲于奔命帮用户解决问题的客服。腾讯云目前的做法是除了提供给用户业界通用的包含每日访问数据、每日卡顿率变化的报表,还提供一个实时的监控系统,可以让用户及时看到访问情况。
另外,我们实行一套网络模拟系统,我们自己在腾讯大厦实验室里面模拟各种托管下、竞争网络下以及运营商网络下的网络环境。现在这一套系统也已经集成在SDK里,可以进行模拟。
讲完这么多,那究竟要接入腾讯云SDK的过程是怎么样的呢?
其实,经过我们的多轮优化,我们现在接入的过程已变得十分简单。下图的8个小框可能仅需要一行代码,如果大家想接入的话,可能从我现在讲完到待会活动结束,Demo就能跑起来了。可能还有人会觉得说自己音视频方面的技能比较差,不是很清楚一些房间之类的概念,我们还提供了一个“随心播”的APP,代码是完全开源的,需要的话直接把代码Copy过去基本上就能正常使用。
谢谢!
【现场互动环节】
【问】:腾讯云视频上对于挂件这一块有没有单独的SDK?
【答】:有的,我们有单独的渠道来接入、开放。
【问】:直播中的接送礼物、结算这一块的SDK有没有公开呢?
【答】:结算的SDK我们没有做的,因为涉及到用户的金融还有用户量等数据,不是很方便去做。一般的直播平台都会自己去做这一块,毕竟涉及到结算的问题。
郭亮的分享PPT下载地址:http://www.oschina.net/doc/44250
引用来自“紫鹿微码”的评论
nginx的地位不是那么好撼动的,且不说你这个是否真的性能快3倍,光是说你这个拓展性和稳定性就不如nginx。代码粗略看了看,基本上是各种开源整合,但是能够做到开源也已经很不错很不错了。在下给您提供3个建议:1、增加模块拓展兼容nginx模块插件格式,让nginx的模块只需要修改几行代码甚至不需要修改就可以编译到此平台上使用。2、增加灵活配置方式兼容nginx配置解析方案,使nginx用户能够轻松无缝切换到nginx上而无需复杂配置。3、建议更新代码文件命名和遵循统一编码规范。引用来自“calvinwilliams”的评论
也就是链表、红黑树用了linux源码,其它LOGC、fasterjson、fasterhttp都是我自己以前的开源项目。1.模块化设计我考虑过,我一直有个想法,对于使用者而言根本不关心nginx是否模块化,每次都是全编译,但模块化会增加设计复杂度降低性能,所以我先不做严格意义上的模块化,只是做到.c分离。2.nginx刚出来也没做兼容apache配置解析方案吧?而且hetao配置也蛮简单的,文档里说明很详细了。3.现公司的规范就是这样的,很难改变了,如果我改成下划线,发布到windows社区,他们又会喷我为啥不统一用驼峰。hetao自有代码已经是统一规范,只不过与自带的引用其它开源库风格不一致。不过还是感谢这位仁兄有建设意义的提议,谢谢关注 ;)引用来自“若水191”的评论
上边人家建议兼容nginx还不是为了你,不兼容的话,推广起来成本很高额,兼容了nginx,那一大批用nginx的用户就有理由或者说吃个螃蟹试试,引用来自“calvinwilliams”的评论
主要是我时间很少,每天也就晚上哄完娃睡后一两个小时可以用于开发,一个人开发压力比较大,而且关于配置迁移一时想不好怎么写。你和紫鹿兄说的是有道理,有时间我再想想。谢谢 ^_^还是要招人一起搞。。。嘿嘿。
我那天看看,如果有兴趣加入。
引用来自“twisted3”的评论
看不懂