融合广电+网络直播的技术实现方案研究

侯艳君

（河南广播电视台，河南 郑州 450000）

互联网的兴起促进了我们国家的发展，在这样的大背景之下网络直播备受关注，从而很多的创业人员以及互联网巨头都将目标投放于网络直播行业当中，并且现在的网络直播在生活当中已经涉及了很多的领域，当前的直播平台种类繁多，这促进了直播的行业的发展，形成了比较大的规模，为我们国家的发展提供了巨大的动力。

一、网络直播的流程

现在直播的形式就是利用网络上的直播软件进行直播，而受众就是通过各种播放器进行收看。

首先直播的人员要准备好直播的设备：麦克风、摄像头等等，并将其进行连接，其次直播的人员找一个网络直播的软件，例如现在的虎牙直播软件、YY直播软件等等，然后要在直播的终端安装推流软件，对麦克风以及摄像头进行有效地识别，并且还要封装采集实时音频还有视频完成原始的编码，再然后就是网络直播软件与平台之间的连接，将实时的直播由直播软件向流媒体服务器进行推送，这时收看的人员就能够通过直播的软件或者是网页进行收看。

二、广电网络与网络直播结合的可行性以及需求

网络直播已经成为了当前最主要的传播形式，并且当今这种直播形式比较贴近人民群众的生活，这对广电网络的发展是十分有利的，相关单位可以从民生方面进行深入发展，例如教育、新闻、生活、旅游等等方面，这些内容更加地吸引观众，有效地满足了受众的各种需求。

但是广电网络和网络直播的这种结合的发展必须要考虑盒端的适配，根据广电网络的业务平台以及系统提出两种实现方案，充分比较分析两种方案的指标技术标准、投资、难易程度等等，而且这两种实现方案的投资成本相应较低，广电网络实施起来比较方便。

三、监控平台直播业务的实现方案

大容量以及高并发的监控平台广电网络的运营商已经建成，并且已经与NVR或者是主流摄像机形成对接，有效地对地级市的电视广播进行监控，监控平台分为主播端、用户端以及平台侧三个部分。

主播端：作为主播必须要有个人电脑或者是手机并且还要有拾音器以及网络摄像机等等设备，然后将其设备接入到广电网上，这样才能保证设备的有效连接，将麦克风与拾音器通过无线调频进行连接，拾音器与摄像机也通过音频线进行连接。

用户端：在用户端用户通过使用广电在网机顶盒对直播内容进行收看。

平台侧：监控软件通过RTSP协议将摄像机的音视频流拉取到广电内网服务器，再通过转码将原始摄像头音视频流转化为M3U8格式的TS流，并实时更新覆盖。当用户端有访问请求时，广电内网将实时的TS流通过HLS协议推送至用户端机顶盒。

但是直播的开启和关闭是由主播进行控制，流媒体服务器以及监控介入服务器均位于广电内网，机顶盒直播的Portal导航页面通过后台进行获取，最终的打开方式由机顶盒的浏览器打开。采集的视频和音频信号必须由网络摄像机完成原始编码也就是将其音频格式改为ACC以及视频格式改为H.264，同时也要生成原始的ES流，并将其进行拉流，其格式也更改为M3U8的TS切片。

此方案有效地避免了直播推流平台的再搭建，还具有较强的适应性，有效地减少了终端对接开发的工作量。假如建设了若干的后台管理子系统，这样有利于后期方案实行的管理，以及业务的拓展，还能有效支撑后期的业务开展。

直播的开启与关闭由直播的系统直接进行控制，用户能够正常进行观看，必须在直播的过程当中；主播认证鉴权系统主要用于主播的注册和认证；直播Portal系统提供直播入口导航页面，采用基于NGB标准的B/S架构，其必须对广电在网的机顶盒进行兼容；直播接入系统用来将需要转码的网络摄像机的相关参数（如IP地址、RTSP拉流串、端口号等）预先导入监控接入服务器；用户认证鉴权系统用来针对受众用户完成直播入口的鉴权，有效地对特殊群体的直播业务进行管控。

四、自建平台的实现方案

直播不仅仅能够通过广电的监控平台进行，还能够有效地参照互联网直播，从RTMP的协议上建设直播平台。RTMP是Adobe公司推出的实时传输协议，主要用于基于flv格式的音视频流的实时传输。使用RTMP协议进行传输，视频需采用H.264压缩标准，音频采用AAC标准，并将音视频流按照flv的格式进行封装。不同于RTSP拉流，RTMP属于推流协议，用于将主播客户端生成的实时流推送至直播平台流媒体服务器。当服务器接收到用户侧机顶盒的访问请求时，使用HTTP-flv或者是RTMP协议将缓存的实时流推送至目标客户端。

安装于主播PC端或手机端的直播推流软件会自动识别USB外接或内置的摄像头和麦克风设备，并完成其中的音视频采集与编码、复用和RTMP上行推流，将实时流推送至直播推流服务器。当前主流的开源推流软件，如OBS、FFmpeg等都可以实现上述功能。后台的流媒体服务器接收到RTMP实时流后，使用推流协议将实时流媒体推送至受众客户端。下行推流协议主要有RTMP和HTTP-flv两种方式。若使用RTMP完成下行推流，服务器无须改变接收到的上行RTMP媒体流即可直接推送；若使用HTTP-flv，服务器需要首先将RTMP媒体流转换为HTTP-flv流再完成推送。根据不同的下行推流方式，可分别基于nginx-rtmp-module（支持RTMP）或SRS2.0(支持HTTP-flv)软件模块完成直播流媒体服务器的搭建。

但是平台的自建存在一大难点，就是广电在网机顶盒终端的适配，广电运营商的发展对于新型的传输协议以及解编码标准的支持力还远远不够，仅仅能够支持一些NGOD业务以及数字电视。此外，自建直播平台方案同样需要后台管理系统的支撑，主要包括主播认证鉴权子系统、直播Portal子系统和用户认证鉴权子系统。不同于基于监控平台的实现方案，OBS、FFmpeg等直播推流软件可以自行控制主播摄像头和麦克风开关，且上行RTMP推流方式无须预先接入主播终端，因此自建直播平台方案不需要另外搭建直播控制子系统和直播接入子系统。

五、比较分析两种方案

本文结合实际提出两种方案，一种是在广电内网的基础之下，另一种就是通过广电在网的机顶盒实现其互联网的直播，在上文当中我们也提到了方案的技术标准、投资规模以及网络协议、落地时间等等，两种方案之间存在很大不同，通过总结出了以下表格。

方案对比表格

延时 5-7s高延时 1-2s低延时 1-2s低延时数据分段 切片文件 连续流 连续流上行流媒体协议 RTSP拉流 RTMP推流 RTMP推流主播测设备 网络摄像机 开源推流软件 开源推流软件直播平台 利用监控平台 新建 新建直播辅助系统 需要 需要 需要HTML5播放 支持 不支持 支持机顶盒适配 不需要 需要 需要投资规模 较小 较大 较大落地时间 较短 较长 较长

由此我们能够明显地看出，两种方案有各自的优缺点，因此在实际的使用过程当中，运营商可以根据受众的不同需求来选择实施的方案。

六、结束语

本篇文章研究了当前最受欢迎的直播行业与广电网络相互结合的可行性，并且对直播行业的实现进行了深入探析，并通过对方案的分析，积累相关的经验，为日后广电运营商网络直播的开展提供更有价值的经验。