迄今为止远程参与了三年的华附直播,却从来没有写过实现直播背后的网络技术。其中主要原因可能是我本来就不怎么样的语文水平,在长期的国外生活中一步步地退化了。

什么是华附直播

我的高中母校,华南师大附中,每年年末都会举办一场晚会,名为 “青春旋律艺术节晚会”,最近几年也被喻为 “华附春晚”。这场晚会主要由学生表演的节目构成,与美国校园里常见的 talent show 性质差不多。但与一般的 talent show 有所不同的在于几个方面:首先是节目的质量和演员水平非同一般。特别是一些团体节目,都是在全国甚至国际比赛中获过奖的;其次是华附春晚也是毕业生情系母校的桥梁。每年这个时候都会有上百校友不远万里回到母校参与这个盛会。他们站在舞台上,唱着歌跳着舞,勾起学弟学妹对未来的憧憬;但我认为最特别的地方在于这场晚会的全球直播。由学生电视台、学生会信息部、广播站等各大学生社团组成的直播团队,每年以最专注的技术操控着最专业的设备,通过网络,向全球校友们提供晚会的全程现场直播。

直播网络技术始末

华附直播已经有 7 年历史,这里主要列出网络方面的技术历史。现场视频音频技术也有逐年突飞猛进的历史,但由于本人不太懂,就不班门弄斧了。

  • 2008 年,首次 Skype 民间现场直播,许先宇同学首创。
  • 2009 年,Windows Media Server + UCWEB 合作直播。
  • 2010 年,PPLIVE 合作直播。
  • 2011 年,PPLIVE 合作直播。
  • 2012 年,HSFZ.tv 首次亮相,Flash Media Server + AWS 直播。
  • 2013 年,HSFZ.tv,Livestream 合作直播。
  • 2014 年,HSFZ.tv,Simple RTMP Server + Docker + AWS 直播。

2012 年

2012 年是我首次主动向学校提出的直播方案。本来一开始是想沿用 PPLIVE,不敢自己搞视频音频直播,只是建议再加上一个现场互动的功能。但后来觉得与 PPLIVE 合作,总是别人的技术,不如自己搞有趣。况且看直播还得装 PPTV 这种垃圾软件实在无法接受,就自己搞吧。

早在 2006 年的时候就在学校内用 Windows Media Server 做过 24 小时的视频直播。自己搞,技术方面不是问题,最大的难题在于带宽。国内的带宽总是最贵的。国外是按流量计算费用的,即 pay-as-you-go,而国内是按带宽容量算的,而且绝大部分运营商都特别小气。再加上网站备案、视听备案等等一大堆手续,基本上国内有充裕带宽的服务商都不愿意与小客户合作。特别是像华附直播这样的活动,一年就一次,一次就上千人,没什么流量,收不到多少钱,就没有合作的意义了。一种方案是像往年一样,用学校的服务器来分发视屏流。学校的带宽虽然相对比较充裕,有 100 Mbps,但由于逐年观众越来越多,100 Mbps 很快就会被瓜分完了。

因此,我们最终选择的方案是利用亚马逊的 AWS 服务。亚马逊最靠近中国的数据中心是日本和新加坡。我们在日本和新加坡分别建立两台 EC2 服务器,在上面跑 Flash Media Server。从学校把视频流作好三种不同质量的转码后,再同时推到这两台服务器上。再由亚马逊的内容分发服务 CloudFront 来进行全球分发。这个解决方案具体实现起来很简单,只要按照这个指南一步一步做就可以了。

CloudFront 的优点在于它的带宽基本无限,支持成千上万的观众同时观看,我们只要支付实际使用的流量即可。而且价廉物美,每个观众算下来一元人民币都用不到。其缺点在于国内没有出口,这完全是个中国特色,国内用户观看的源全部来自国外。所以为了保证国内用户也能相对顺畅,我们在日本和新加坡又建立了两台 FMS 服务器,使用 P2P 协议进行直播。直播页面上,用户可以选择三个不同的源,一个是 CloudFront 的内容分发网络,一个是南方 P2P 即新加坡,最后一个是北方 P2P 即日本服务器。最后整个直播花了不到 150 美刀。

2013 年

本来计划 2013 年会使用与 2012 年差不多的直播技术。后来在某校友的建议下,我们测试了一下 Livestream 的直播服务。Livestream 的直播服务租一个月就要 300 刀,一下子就超出了上一年费用。而且 Livestream 也是国外服务,没有根本解决国内访问问题。但我们还是决定用 Livestream 作为备份源。

结果不巧的是直播当晚现场上传视频流的电脑坏了,无法上传到我们在亚马逊云服务上的 FMS 服务器。本来作为备份的 Livestream 就成了直播唯一的源了。

2014 年

今年的直播开始得比较晚,12 月份才收到学校学生的联系,距离第一次直播不到两周时间。但今年与往年不同的地方在于同学们已经在阿里云上建好 FMS 服务器并且测试过了,让我感到现在的学生真的是越来越厉害了。可惜阿里云服务只有可怜的 5 Mbps 带宽且没有备案,再加上他们用的 FMS Starter 版本有直播 10 分钟的时长限制,这个方案最终还是不能被采用的。

与此同时我碰巧发现了一个新的开源项目,叫 Simple RTMP Server 简称 SRS。开发不到一年时间,甚至当时还没有 1.0 的发布版,但它的发布候选版本就已经做得非常出色了。其作者也是中国人,估计是厌倦了 FMS 和 Wowza 这些商业服务器,自己写了一个替代品。Simple 是它最大的特色之一。SRS 与 FMS 的对比就相当于 Linux 和 Windows 的对比。Windows 下很多软件都是集成了成千上万的功能,而 Linux 下则是有成千上万功能单一的小工具。FMS 就是一个集成的解决方案,而 SRS 则类似于这些小工具,每样工具虽然功能单一,但正确的使用组合则会使其无比强大。

由于 SRS 编译起来比较复杂,我把它在 Docker 里封装了一下,使用的时候直接获取 ziyan/srs 即可。SRS + Docker 就成了这次华附直播网络方面的主要新技术。

今年,有了吴展斌老师在学校机房内设置的服务器,现场的视频流先通过学校内部网络上传至学校的服务器上。学校的服务器上运行了 SRS,把源视频和音频进行第一次转换,输出 H.264 720p @ 24 fps + AAC 格式的一个流,占用大概 4 Mbps 的带宽。我们再把这个流推到日本的亚马逊服务器上。在亚马逊上有多台服务器,首先是 SRS 转码服务器把 720p 转成 432p、360p 和 216p 多种质量,然后生成 HLS 格式的播放文件,再由 CloudFront 进行分发。SRS 其实并不支持多质量的直播,因为每种质量之间并没有同步。直播时间越长,它们之间的偏差就越严重,所以导致质量切换时出现卡的现象。但这也没有办法,国内观众网络质量参差不齐,大家都想看 720p,众口难调。

直播前我们做了一些实验,发现虽然 CloudFront 在国内不稳定并且速度慢,但日本的 EC2 本身国内访问起来并不慢。为了攻克这一问题,我们在日本 EC2 上自己建了 6 台分发服务器,每台一个独立公网 IP,支持 1 Gbps 的带宽。为了防止某些防火墙的干扰,网站和视频流还全部通过 HTTPS 加密。

总体来说,今年这样的设计为的是分摊计算需求,尽量减少学校出口带宽需求以保证直播顺畅。但事实证明,晚会现场网络严重问题,导致把流通过学校内网上传至学校内部服务器这个步骤出现了问题,输在了第一段网络上。后来我们进行了两次重播,都是由日本的服务器直接播出的,省去了学校这一段网络。重播时绝大多数观众反应视频是顺畅的。

HSFZ.tv

从 2012 年开始,华附直播就再也不只是视频直播了。观众除了能够在电脑上、手机上、平板上观看现场直播,还能发表评论,与其他网上观众以及现场观众进行实时互动交流。互动方式有 4 种:

  1. 通过登录 HSFZ.tv 网站,然后在视频旁边留言。
  2. 在新浪微博上发带有话题 #华附春晚# 的状态。
  3. 在 Twitter 上发表带有话题 #华附春晚 的推文。
  4. 在微信里关注 MyHSFZ 公共号,通过机器人发表留言。

这些留言全部都被自动实时汇集在 HSFZ.tv 上。通过现场同学的筛选后,精彩的留言会被实时展示在晚会舞台旁的互动墙上。互动墙上同时能实时展示当前网上观众数量、观众地理位置、动态更新节目表等各种有趣的信息,增强现场气氛。为了 “上墙”,有些观众一个人就刷了 400 多条留言。互动墙上还有一个很炫酷的动画地图,每当有新的校友上线,地图会自动转移至该校友的所在城市,但很可惜每次晚会由于投影地方有限,地图总是会被隐藏起来。

这些实时互动功能的实现技术归功于 socket.io。2012 年直播的时候曾经出现过 socket.io 超负荷的情况,当时通过 live coding 来修复这个问题,后才来得知是个已知的 bug

下一步

有些问题一定是需要靠学校解决的。例如学校内网的网络质量,特别是直播上传视频的网络,希望能有独享专线,保证上传流畅。也希望学校能开设北京 AWS 帐号,提高网络直播国内观众观看的质量,同时也能让学生接触到计算机云服务。

技术上的改进方向包括:

  • 国内网站镜像。其实这个今年也有,但不是全面镜像,只是把静态文件作了镜像。
  • 改进现场墙,使用现场的 LED 屏幕。
  • 可以考虑实现弹幕。
  • 校友连线只有北京、上海两地,可以考虑通过 WebRTC 百人同时视频连线,每人在屏幕上占一个小方块(校友陈晓奇的想法)。

每一次直播对大家以及我都是一次技术上的锻炼,从中学习到了各种新技术,吸取了不少教训。每一次与学弟学妹们的合作都比较晚,虽然共享了代码,但由于时间不足,同学们都未能充分参与网站和其他直播技术的开发。学业繁重,这也是可以理解的,毕竟这只是业余活动。