连麦已经成为互动直播的基本功能，但连麦的成本较高，对业务形成比较大的压力。北京密境和风科技有限公司iOS技术负责人唐赓在LiveVideoStack Meet上分享了花椒直播在降低连麦成本方面的一些探索，此外对连麦费用构成、降低成本可采用方案，以及实际效果进行分析。
演讲 / 唐赓
整理 / LiveVideoStack
我将从以下五部分分享我们在连麦成本控制方面的尝试和经验：连麦接入方案、费用构成分析、尝试方案、实现过程中存在的问题以及实际效果分析。
连麦接入方案
![640?wx_fmt=png&wxfrom=5&wx_lazy=1]()
上图是最常见的单向直播架构，左侧主播端将直播流推到源站，源站再通过CDN分发到边缘节点，所有客户端则是从这些边缘节点拉取数据，这是最普通的方案。单向直播对技术的要求相对较低，它对延迟、实时性没有过高的需求，但是对CDN的要求会相对高一些，来保证直播的连通性和覆盖率。
但是对连麦的接入方案而言，连麦本身对实时性是有较高要求，当然这个要求主要是针对连麦的主播之间的，因此连麦服务商都会有连麦服务器来保证主播之间实时互动的连通性和实时性，连麦服务使用的肯定是核心服务器，那么相对而言成本也会高很多。而对于普通的观众端则依旧是从CDN边缘节点拉流观看直播。
![0?wx_fmt=png]()
但是这个架构我们在实际应用过程中遇到了很多问题：首先就是开播之前必须选择是否使用连麦，这决定了主播推送的流是否要接入连麦服务器，因为连麦成本(单价)是普通直播的20倍、甚至40倍，而有的主播虽然在开播前选择连麦，但在直播过程中却并没有用到，这无形之中就极大增加了直播成本。也正是因为如此，给所有主播都开启连麦是不可能的，而且也仅仅有小部分主播需要使用到连麦功能。而另一个问题则是在直播过程中突然有连麦需求怎么办？下播重新推流显然是不现实的，一方面会影响观看体验，一方面也很难再次聚集人气。此外伴随直播玩法的更新，象主播间的连麦PK、多个直播间合并这样的需求也在不断增加，如何支持这些需求，这就需要对直播架构进行重新设计。
连麦成本构成分析
连麦成本首先是连麦服务费，它的计算方式分为按照房间数*时长计算和按流量计算两种，无论用哪种方式计算，通常价格都是普通CDN的20倍、甚至40倍以上。费用构成的第二部分就是中间CDN费用，这部分又会有两种方案：一种是直接使用连麦服务厂商提供的SDK中的CDN解决方案，一种是自建或单独购置CDN，两种方案相较而言可能第二种方式在费用上会更合适些。此外还可能会产生的成本就是合流费用，这部分费用产生的原因是连麦会产生多个窗口，假如采用拉取多路流再在客户端拼合成需要的布局，一个因为手机和各客户端本身分辨率有差异，另外为保持所有客户端获取一致体验需要手机端代码来保证播放同步，这在实现过程中会遇到很多麻烦，因此我们采用将多个流合流为一路推送到客户端，目前几大连麦服务厂商都提供了合流服务，但同时在费用上它甚至比连麦服务还要再贵几倍。因此我们使用FFmpeg自己开发了一套实现方案。
降低成本的实现&遇到的问题
![0?wx_fmt=png]()
上图是我们改进后的架构，主播在正常开播时依旧是采用传统的单向直播方案，直播流会走绿色的线推给源站进行推流，而连麦服务初始状态是隐藏的，一旦有需求，主播只要同意连麦请求就会自动切换到连麦服务器上，再推给源站推流。
但在实现过程中我们也遇到了一些问题：首先是版本问题，如果要实现这样一个架构，我们就必须通过IM通道通知所有客户端流流名变更、流服务器地址变更，然后手机就会立刻从新的地址拉流，但老版本并不支持这个协议。此外还有H5和PC Web的问题。
![0?wx_fmt=png]()
这张图是我们针对老版本兼容改进的架构，当主播切换到连麦后原本推流的绿色虚线就会消失，改由连麦服务器按照原来的流名继续推流到源站，这样就可以保证老版本客户端能够源源不断看到直播内容，而新客户端也可以正常拉取到新的流。这里需要注意的一点，为了保证老版本客户端收到的内容也是新的画面，就需要连麦服务器在原来流名推的是合流之后的流。
但在我们实现过程中发现这条路走不通，因为CDN厂商有一套推流保护机制来防止流被别人恶意劫持， 它会记住上一次推流到这个流名的IP，并且在一定时间内不允许更换IP，或者需要特殊的API调用去通知它IP更换。因此这个问题只能通过和CDN厂商协商来解决了。
推流参数变更也是我们遇到的坑，原本的推流是由手机端直接推的，而手机的推流参数与连麦服务器和合流务器输出的参数是不一样的，这就可能会出现没有声音、直播画面出现异常等等各种问题。对于这个问题，我们也是和推流中所有环节的厂商——包括连麦服务商和各家CDN厂商规定了一套推流参数规则来解决这个问题。当然这些服务商也并非只有我们一家，因此他们在对我们参数适配的同时也还要兼顾其他客户的正常使用，所以测试、发布的过程也是非常谨慎小心的。
在规定推流参数的同时又衍生出了一个新的问题，就是新增CDN厂商的不兼容。我们的推流参数不是固定不变的，因为在手机端推流时，分辨率、码率、帧率都会根据当前网络带宽、手机CPU消耗等因素做动态调整，因此我也只能要求新增的CDN厂商按照我们的规范支持分辨率、码率的动态调整。
除此之外还会有一些其他的坑，比如我们自身用了很多私有协议，而厂商可能用的是公有协议，那么在对接时协议之间又会有很多不兼容，需要做适配转换。
实际效果分析
在经历一系列的问题改进，最终能达到的效果基本可以归纳为4点。首先对于主播而言，他可以随时进行连麦，不需要在开播前就必须做出选择。第二点我们实现了多个直播间合并直播，并且加入了一些设计：当多个主播连麦时，直播间观众看到的主播位置排序一定是当前主播在第一位，这个在实现过程中需要注意给到合流服务器的所有排列组合信息是正确的；在合并直播的基础上我们也做了主播才艺的PK。此外实现了老版本的平滑过渡。当然最大的好处就是成本降低，主播只有在有连麦需求的时候才会自动切换到连麦服务器，而我们也设定了一个时间域值，当主播一定时间不连麦后我们会自动切回普通直播，这样就比较明显的减少了连麦成本。
以上是我们尝试的新的直播架构，以及实现过程中遇到的问题和解决思路，谢谢大家。
LiveVideoStack招募全职技术编辑和社区编辑
LiveVideoStack是专注在音视频、多媒体开发的技术社区，通过传播最新技术探索与应用实践，帮助技术人员成长，解决企业应用场景中的技术难题。如果你有意为音视频、多媒体开发领域发展做出贡献，欢迎成为LiveVideoStack社区编辑的一员。你可以翻译、投稿、采访、提供内容线索等。
通过contribute@livevideostack.com联系，或在LiveVideoStack公众号回复『技术编辑』或『社区编辑』了解详情。
