从直播答题看背后的移动音视频开发

摘要:直播答题经历了火山喷发式的火爆,展晓凯和他的团队也经历了在短短数周内完成产品开发、测试、上线、运营、迭代的过程,他从产品逻辑、技术实现、难点突破等方面给出了自己的方案与经验。本文来自全民快乐研发高级总监展晓凯在2018年1月《LiveVideoStack Meet:移动音视频开发进阶暨新书分享会》上的分享,活动邀请了展晓凯新书《音视频开发进阶指南》的粉丝参与。

文 / 展晓凯

整理 / LiveVideoStack

大家好,今天非常感谢大家前来聆听我的分享,也非常感谢LiveVideoStack社区为我们搭建这样一个探讨前沿技术的平台。我认为在音视频或者其他任何一个技术领域,能有这样为我们广大开发者服务的社区弥足珍贵。

在此之前我在线上分享过一种类似于抖音或者Musical.ly还有国外【0:34】这样为短视频添加特效的平台。今天前来我想分享另外一些我最近正在做的具有一定技术门槛的技术,与大家一起探讨交流。

今天我向大家分享的是《从直播答题来看背后的移动音视频开发》。直播答题应该是最近非常流行的一种网络直播新玩法,最开始提出这一概念的应该是王思聪。

首先我们需要大致了解一下直播答题的场景。

一、场景

直播答题每场次一般有12个题目,用户全部答对的话可以平分本场的奖金。直播开始主持人会向用户介绍答题规则,鼓励大家将自己的邀请码分享出去以换取复活卡,这是一种获取新用户的手段。在这之后根据主持人的介绍,系统以答题卡的形式下发题目,观众便可以进行答题。每道题会有ABC三个选项,用户进行作答提交答案,但只能提交一次且不能更改,最后公布本题目的正确答案。如果用户答对了就有机会答下一题,如果答错了可以使用一次复活卡获得答下一题的机会,如果用户12题全部答对了便能分得奖金。

二、国内厂商

国内举办这项活动的第一个品牌应该是王思聪的冲顶大会,紧接着映客上线了芝士超人。芝士超人是我的一个同事用三天时间开发的一款独立APP,仅用了一天测试便匆匆上线,导致第一版有很多Bug,当然这样做是为了争取行业第一的位置,出现bug也情有可原。在此之后是今日头条旗下西瓜视频推出的的百万英雄,花椒在映客上线芝士超人后也开发了百万赢家……各个厂家都有不同的入局直播答题的方案。因为我所在的公司也是做直播业务的,主要面向印度的消费者,我们公司的业务重心是印度市场。既然中国的直播答题市场不容小觑,印度也会有同样的市场需求(当年的电影贫民窟的百万富翁是多么火爆),并且印度消费者对直播也非常感兴趣,所以说我们打算在印度推广直播答题。

三、盈利模式

虽然我们主要探讨的是技术,但需要确保我们做的事情是有意义的。因此接下来我简单分析一下直播答题的盈利模式:

盈利模式1:直播答题本身就是直播平台一种获取新用户的手段。对于国内市场,每一家公司在安卓平台需要通过购买渠道等方式获取新用户,采用上线积分墙或者在各种市场进行推广的方法吸引新用户进入平台;如果是国外市场,公司可能需要在Facebook、Instagram 等社交平台采购一些广告的流量来拉拢消费者。与其把公司这些用来买流量的钱付给各种渠道或者传媒公司,不如直接分给用户,同时可达到精准定位消费群体从而进行差异化精准营销的效果。如果我们使用传统的获取新用户的手段也就是通过渠道运作,假设获取一个用户的成本是5元,那么通过直播答题的形式获取一个用户可能只需要2~3元,直播答题获取新用户相对于传统方式大幅减少成本。

盈利模式2:线下可以和电视台等传统传媒业合作制作网红和IP。例如花椒曾与《一站到底》进行合作,花椒也设计过一个美团的专场,美团通过付费来获取这一场用户的流量。

盈利模式3:直播答题中可以通过设计背景幕布、主持人T恤、视频广告等形式穿插硬广。前提是这些广告不能对用户体验造成严重的破坏。

盈利模式4:一些运营的手段,例如由某个厂商对直播答题进行冠名从而获取赞助等。因为直播答题能带来非常可观流量,例如半小时平台同时在线可达到10万甚至20万人,如果此时任何一家厂商在平台上投放广告,都能为其带来非常明显的经济效益。

四、技术实现

接下来让我们简单了解一下实现直播答题需要什么样的技术手段。当然像刚才列举的几个厂家,他们实现直播答题的技术手段肯定是不一而然了,例如花椒使用的是即构科技提供的技术。直播答题背后的技术手段具体是什么呢?

1、技术组成

图片中间的是Server部分,首先是Web Server。我们可以简单理解为Web Server提供API接口的同时也提供一个运营后台,运营后台可以给我们运营人员使用,而API接口自然是直接给我们的终端用户进行调用;接下来的Socket Server部分负责长连接,进入任何一个直播间都需要经过长连接的服务器;第三个必不可少的就是Live Server流媒体服务器。图片右侧Audience表示我们最终的用户,左侧OP表示我们的运营人员,Host表示我们的主持人。

2、技术原理

当用户通过外界的Push、Banner、分享Link等跳转进入答题房间后,第1步需要获得比赛的信息,例如目前有几张复活卡、单场比赛的奖学金额是多少、本场比赛的时间等等,总而言之就是用户通过短连接服务器(Web server)获得本场比赛的信息。

直播开始,首先主持人介绍比赛规则。此时设备会把主持人的实时语音和画面传送到流媒体服务器,这一步称为直播内容推流。直播内容推流的技术现在已经非常成熟了,可以通过PC上的OBS软件实现。使用OBS将主持人的音画推到流媒体服务器,但主持直播离不开台本,故需要通过类似于提词器的设备将实时响应讯息呈现给主持人,这就存在一位负责给主持人翻台本的运营人员提供直播互动讯息,例如第一题答完之后A选项、B选项、C选项各有多少人或者是本轮淘汰了多少人、本轮有多少人用了复活卡……主持人收到实时反馈后再面对镜头把这些讯息传递给用户。OBS便负责把以上整个内容上传到流媒体服务器,这样我们的观众就可以通过流媒体服务器获取视频的内容。

接下来主持人会为参赛者阅读第一题,此时需要我们的运营人员利用Web Server提供的运营后台下发题目。下发题目的过程实际上Web Server会实时调用Socket Server,Socket Server下发题目给所有的观众,观众们就会看到下发的答题卡。看到答题卡后所有观众就可以选择一个题目,如果他不选择系统会判定该用户超时。用户选择题目并作答,提交答案会直接请求连接服务器。在这里的Socket Server只用来当作一个通道或一个广播,并不负责业务逻辑。我们使用Web Server控制业务逻辑以及数据存储,而Socket Server只被当作一个通道(这样一来可以提高并发)。

提交了答案之后主持人会用10s到30s对题目进行解释,紧接着会公布正确答案。公布答案的过程实际上是运营人员在后台控制答案的公布,此时Web Server又会实时调用Socket Server,最终使正确的答案公示在客户端上。用户便知道自己的答案是否正确,并且根据是否答对来控制接下来的状态(比如是否使用复活卡,是否可以继续答题)。之后进行下一题的作答,也就是循环图中的3-1 下发题目、3-2 提交答案、3-3公布答案直到十二道题作答完毕。在答题中主持人会控制节奏,穿插一些介绍玩法引导用户分享出去获得复活卡,或者播放增加紧张感的视频(例如倒计时)烘托整体气氛。

到了最后主持人会在12道题作答完毕后公布比赛结果。此时运营人员会在后台控制公布比赛结果,最后广播给所有的观众。例如所有观看本场直播的一万人,每个人获得2元或5元,最终点击直播结束,整个流程终止。

上周我们做了5天的直播答题活动,总体来看效果还可以,没有出现什么大纰漏。当然这里会有一些技术难点,这些之后会讲到。在公布答案这一环节,我们也可以将题目答案打到视频流里面去呈现给观众,现在即构科技和花椒合作的项目便在尝试这种方案。但是我相信这种方案在我们团队中实现起来成本会比较高。这样也会有另外一个问题就是你必须要保证视频的流畅性以及多客户端视频同步性,当然无论如何我们要保证多个客户端的视频同步性。

三、技术难点

1、解决录音棚内的场景搭建与推流的难点

1)采集与推流的过程:这些对于从事摄像工作的专业人员来说并不难,但是对于之前完全没有从事过专业摄像工作的我们来讲具有一定难度。因为摄像机需要通过视频采集卡对画面进行采集;如果是多机位则需要经过导播台再到录机,再通过视频采集卡供给电脑,之后通过电脑OBS进行推流。

2)专业打光效果与场景布置:简单的话可以给主持人后放置一块带有LOGO的幕布,要想做得好也可以通过使用绿幕抠图技术实现动态背景的效果。

2、解决保持视频和题目同步的难点

例如主持人说:“下面我们来看第一题。” 他说完“第一题”这三个字时答题卡刚好出现,可以给观众更好的视听体验;如果主持人说:“下面让我们来看第一题,第一题的内容是‘LiveVideoStack社区是不是给大家提供了很大的帮助?A是、B不是、C当然是。” 如果此时答题卡才出现便会破坏观众的视听体验。因此我们必须保证主持人主持的视频和答题卡的同步性。

3、保证多个客户端观看视频同步性的难点:控制多个客户端观看视频的时间差在2s甚至1s以内。

4、保证多个客户端下发题目同步性的难点:控制时间差在1s以内,否则实时性得不到保障就会失去比赛的公平性。

只有保证多个客户端观看视频的同步性以及多个客户端下发题目的同步性才能带来完善的用户体验。

那么基于我们现有的技术,怎样才能克服这些技术难点从而完善我们的产品体验呢?

四、解决技术难点

1、解决录音棚内场景搭建与推流的难点

首先我们需要摄像机、灯光、三脚架、幕布等设备搭建起一个小型摄影棚。

其次选择合适的视频采集方法,如果使用视频采集卡比较常用的有BMD(BlackMagicDesign),但是会存在一些兼容性问题。还有一些其他的视频采集方法例如通过SDI/HDMI将1080p的视频信号直接输入后通过USB3.0/Thunderbolt输出到PC,使得PC获取视频流。

接下来进行电脑推流。为视频设置合适的分辨率、码率、帧率、GOP、x264 opts等参数,而后使用OBS软件进行推流与切换视频源,如果有专业老师控制的导播台则可以达到更好的切换效果。OBS里可以实现基本的切换功能,例如先放一段娱乐视频中间再放一段引导视频最后放一段倒计时,三段视频切换完成后再切回主持人的画面,可以达到硬切无缝的效果。而PC连接有线网络可以保证网络的稳定。

2、解决多个客户端观看视频同步性的难点

我们的解决方案是使用OBS推流到一个RTMP地址——一个我们自研的服务器,推流完成后流媒体服务器会把视频流转至CDN(我们的CDN对接的是Akamai);之后再从CDN拉流至客户端播放给观众。这样的过程从主播端到观众端的整体延迟大约是3~5s,并且如果拉流卡顿之后延迟会越来越大,所以在播放器端需要进行一些调整。

1)首先我们来看在推流端。例如现在设置一个分辨率是540×960、码率是900Kbps的视频,一秒一个关键帧并且不使用B帧,至于音频参数因为人声居多故设置为Mono 96Kbps,这些完全可以在OBS的选项里进行设置。

2)在服务器端我们需要做切片。1s一个切片也就是1s一个关键帧,之后转推CDN。因为Akamai是不支持RTMP所以需要切片后转给Akamai(实际上Akamai主动拉我们)。另外我们的服务器还会转码为低码率码流进行分发。因为我们公司开发的直播答题主要面向印度消费者,印度的网络环境比中国的网络环境还要复杂,所以我们要将900Kbps的原始码流额外转一路400Kbps这样的低码率码流。当然客户端会自适应这种码流变化,如果监测到网络环境不好可以切换为低码率码流进行播放。这样画面会稍显模糊但最起码用户可以听到主持人的说话。

3)接下来在播放器端。a、从CDN拉流时一定要做追赶的操作,如果检测到分片信息比较落后可以立马去追赶,这也就是为什么我们能保证视频在多个客户端上播放的时间差在1~2s。b、根据网络自适应拉取对应的码流,可能是原始码率的码流,也有可能是400Kbps这样低码率的码流,这同样是为了保证多个客户端观看视频的同步性。

3、解决保持视频和题目同步的难点。

刚才我提到的负责发题与公布答案的运营人员会在另外一个房间将自己当作一位观众,拿至少两台设备观看主持人说到哪里。有时运营人员会和主持人约定一个手势或者一处暗示,例如当主持人打一个响指时运营人员去控制下发题目。从点击按钮到观众从设备上看到题目,Web Server以及Socket Server可以将时间控制在1s以内,运营人员就是这样根据当前客户端播放的视频内容控制题目下发的;当观众提交答案时提交到Web Server端,服务器会设置一个超时时间例如20s,20s后用户再去提交答案即使正确也会因超时而作废;运营人员听到主持人即将读出题目或者看到约定的信号出现时可去点击下发题目、公布答案、公布结果或结束直播,这些是保证视频和题目内容同步的手段。

4、解决保证多个客户端题目下发同步性的难点

如果我们单纯靠一个运营人员在另外一个房间以用户的角度看到主持人说“下发题目”后点击发题按钮,那接下来就是保证多个客户端题目下发的同步性。在这里我只列举一个不太困难并且实现起来比较不错的一个思路,运营后台的任何一个按钮都要通知到长连接服务器。大家可以直接在自己的服务器内部去完成,例如发送消息等。长连接服务器将这个消息立即透传给房间内的所有人员,包括下发题目、下发答案、公布结果、比赛结束等。

5、解决视频抠图与添加背景的难点

例如我们刚才说到为LiveVideoStack设计直播答题系统,最简单是我们将一个印有LiveVideoStack标志的幕布作为背景,主持人会在幕布前说话以及与观众互动,这样达到了静态背景的效果;但如果我们要实现动态背景,比如说国内各大答题厂商都有在主持人背后设计动态背景,那如何来实现这一点呢?

首先主持人需要站在一个绿色的幕布前,当然蓝色的幕布也可以实现,但是因为在CMOS或者摄像机传感器的拜耳阵列中感知绿色的单元是最多的,故而绿幕的效果最好。关于这一点我们可以在很多影视作品的拍摄过程中看到绿幕的运用,一般用于拍摄需要添加电脑特效的镜头时,演员背后的布景会呈现绿色。使用绿幕拍摄时主持人不能穿绿色衣服佩戴绿色首饰以及其他任何与背景颜色相似的东西,否则抠图过程容易出现问题。

其次我们在OBS里增加一个效果滤镜——色值,并将关键颜色类型选择为绿色。根据不同场景调整参数,例如这里我将相似度设置为-800、平滑度设置为-13、不透明度设置为-100,这样就可以把主持人从背景中分离出来。而后在OBS的场景中主持人Layer后边添加一个动态的视频背景,而这个动态背景内容可以是市场部拉来的广告,也可以是自己产品的品牌展示,这样不用打印幕布也不需要任何LED显示屏,直接把视频放在后面就可以实现动态背景效果。将要添加的视频背景同时展示出来,这样动态视频的扩展性会更强。

6、实现生动的多媒体类型题目

如果在直播答题中呈现给观众的都是普通的文字类型题目,对观众而言花费时间读题未免会太过枯燥,这也是我们期待为直播答题添加多媒体类型题目的原因。例如我们可以给观众听一段音乐,之后出题考查观众是否知道这首歌曲的原唱;或者给观众看一段电影片段,之后出题考查观众是否知道此电影的导演。这种直播内容与图片音频视频的切换不需要在客户端中进行,而是完全通过 OBS切换:当答题卡下发时我们会把视频缩小成30%大小并放在画面右下角,这样既不会影响答题卡的下发也不会因为视频画面太小而不能让用户看到整个视频内容;或者我们可以把视频内容换成一张图片或者换成另外一个视频,甚至添加一条音轨,这些在OBS中都可以轻松实现。OBS的扩展性非常优秀,完全不用改动任何的客户端代码或者服务端代码。

以上是我结合遇到的技术难点和关注的问题总结分享的全部内容,希望能为你提供有价值的帮助,谢谢。