77直播系统开发（APP，小程序，有现成，可定制），AGH-GEIB-JDDF开发，77视频平台搭建，77APP开发，77直播APP开发
第一步，PC端视音频采集
目前Zui火并且流量Zui大的游戏还是端游，比如英雄联盟、剑灵、坦克世界、DOTA2、跑跑卡丁车、梦三国、怪物猎人、完美世界、穿越火线、魔兽世界、梦幻西游、炉石传说等大型游戏，需要完美采集PC端的游戏画面和音频，
PC端的图像目前主流的是1080P高清分辨率，并且主要是运动画面，数据量非常大，如何高效地采集到这些数据并且还要实时地进行编码压缩，要有更高的压缩效率从而节省平台端的数据带宽成本，都是需要详细考虑的问题。
为了完成这一步，我们详细比较了多种不同的实现方案，主要有如下几种：
1） 采用目前市面上现成的硬件视频编码设备；
我们测试了多个厂商的设备，这种设备通过内置的DSP专用芯片做视音频处理，实时性很好，测试后发现其对运动图像的处理效果不好，编码后的图像会有比较大的失真，并且压缩效率低，产生的数据量大。广播级的硬件编码设备单台价格都在2万元左右，不适合我们面向个人玩家推广。
2） 通过硬件+软件的方式来实现；
按照通常视频会议的应用模式来实现，配置专业的高清视频采集卡和PC端视频采集编码软件。市场调查后发现，采集卡倒是有很多品牌，单价在1000~3000元不等，并且测试后发现采集的图像效果很不错。难题出现在了PC端软件上。可以实现这种功能的专业PC端采集编码软件屈指可数，深入研究后知道了原因，主要因为这方面涉及的技术层面太专业，这种软件通常都需要使用C语言来编写（编程难度大），要求程序员精通当前Zui主流的视音频编码算法（H.264/H.265/AAC等），要精通socket网络编程和流媒体协议栈（UDP、RTMP、RTSP、HTTP、HLS），在国内要招聘到这样的高手真是太难，因为这方面的技术标准制定都是国外主导的，可以请到，这种人的月薪估计也在10W左右，并且这种程序的开发周期至少在1年到2年的时间，我们研究后决定放弃PC端软件的自主开发计划。放弃自主开发不等于说是放弃这种实现方式，因为从整体上来衡量，采用软件方式实现前期投入大，大规模运营时单位终端上的摊销成本就很低，因为软件可以无限复制。
软件的选型是一个费事费力的过程。PC端专业的视频采集软件主要有Adobe 的Flash Media LiveEncoder，FFMPEG，直播大师，VLC等少数几款。
A. Adobe的Flash MediaLive Encoder测试
测试的是Adobe 的Flash Media LiveEncoder，这是一款成熟的直播软件，配合Adobe 发布的Flash MediaServer使用的，软件稳定性不错，这款软件的弊端也很明显：1）它不支持AAC音频编码，因为AAC音频编码是要向第三方机构购买Licence授权费用的，Adobe出于节省成本的考虑没有加入这个特性（因为FlashMedia LiveEncoder是免费的）；2）它的H.264视频编码采用CPU来运算，由于H.264编码算法很复杂，做高清编码时占用的CPU资源太高，i5/i7系列CPU做编码时资源都占到了50%，这时运动大型游戏时主机很吃力，经常出现运行不畅和卡顿的现象。解决的方式也很简单，配置一台独立的主机做采集编码工作，这时增加了5000元的额外开支；3）在直播的不能实时存档录制MP4文件格式，只能存档成FLV格式再用转码工具做格式转换，费时费力二次转码会降低图像的清晰度；4）不能在直播的叠加字幕和台标；5）Adobe太，人家不愿意给我们做定制开发，并且不提供源码和开发接口，这点是Zui要命的。毕竟是做运营，我们希望将服务器信息和一些直播默认值写死到程序中去，自行开发它目前没有的功能，人家看不上我们，后来领导出面去沟通对方将就同意了提供定制化的二次开发，要价几百万美元，老板Zui终决定放弃这款方案。
B. FFMPEG测试
我们开始测试FFMPEG的直播客户端方案，由于FFMPEG这款软件是开源软件，如果该方案可用肯定是Zui优的方案，毕竟可以按自己的意愿随意改造。测试工作进行了半个多月时间，毋庸置疑，这款软件的功能非常全面，基本上在音视频处理方面你能想到的功能点它都想到了，国内外做视音频方面开发的有很大一部分都是基于FFMPEG做二次开发。测试后发现，这款软件的Zui大弊端是1）稳定性差，动不动就会崩溃或者死掉，无法长时间工作；2）命令行方式操作，没有直观的图形用户界面，非专业人士不会操作；3）硬件兼容性差，无法与第三方硬件设备的驱动程序进行良好的交互（比如各厂商采集卡驱动）；4）没有专业的二次开发技术支持，只能自行研究和改进。由于我们的运营项目对上线时间有要求，改造FFMPEG至少需要1年的时间，只能将ffmpeg作为一款备选方案。
C. 直播大师测试
直播大师是北京顺景科技有限公司开发的一款专业直播采集编码软件，该软件拿到手进行测试，给人的第一感觉就是操作简单，具有图形化的操作界面，采用所见即所得的设计风格，非常适合非专业人士使用。
我们进行了更详细的性能测试，测试结果表明，这款软件是我们在市面上见到的Zui高效的一款直播采集编码软件，它能够以H.264编码格式编码6路1080P的视频，此时的CPU占用率也只有5% 【CPU型号：i7-4770k】，可以将多个输出码流推送到多台服务器上做冗余备份。这款软件支持在本地多种格式的录制功能【MP4、TS、FLV、MOV、3GP这些常用格式】，支持当今Zui新的H.265编码技术【个人认为H.265在不久将会取代H.264成为主流标准】，还支持多种协议的输出【RTMP、RTSP、UDP、HTTP】。该软件还支持电视台中常用的实时字幕叠加、台标叠加、时间戳叠加等实用的功能，以上这些已经完全满足了我们做游戏直播这种应用场景的需要。如果产品的稳定性有保障的话，这应该是一款非常好的方案。
我们进行了产品的稳定性测试，按照对方给出的测试环境【i7 CPU/8GB内存/1TBSATA/千兆网络/4路高清采集卡】，我们使用该主机在办公室常温环境下采集编码4路高清视频进行测试，不关机运行了2周时间，机器运行一切正常，中间没有发生过死机和内存增长的情况，运行极其稳定。
再就是领导和对方在商务上和服务支持方面的沟通。我们本想要对方开放源代码或者提供接口给我们，我们自己增加一些应用功能进去，看到对方的产品源代码后才发现，对方的产品软件结构很复杂，没有详细的软件开发文档，让我们很难快速掌握其整体结构脉络。Zui终，经过上层领导的沟通协调，对方答应为我们开发个性化的应用功能，开发周期在1.5个月内完成，增加的主要功能包括：1）与我们自身流媒体发布平台的绑定，2）用户登录验证信息的绑定，3）通过软件方式实现游戏视音频信号的采集。第3）个功能对我们的运营平台意义重大，这样可以节省下每个终端高清采集卡的硬件成本，对于我们这种大规模运营平台来说节省的成本非常大。
D. VLC测试
VLC是一款开源的客户端软件，具有解码、编码和串流等应用功能。本质上，VLC是基于FFMPEG开发的更的应用，VLC开发团队自己设计了图形用户界面。这款软件已经持续开发了10多年时间，用户范围遍布全球。我们对其进行了如下几个方面的测试：
1、功能测试。
由于VLC本身就是基于FFMPEG做的开发，功能上还是很强大的，基本上满足我们的需要。
2、性能测试。
我们用它做H.264的编码测试，发现它用的是x264这个开源的编码算法，通过CPU进行计算，编码1路1080P的高清视频CPU资源占用率达到了50%。
3、易用性测试。
用VLC做播放器使用其用户体验效果还是很不错的，并且提供多种用户界面可以选择。作为采集编码软件来使用的时候，它的用户体验效果很差，操作很不方面，也不直观，如果自己做二次开发改造的话需要花费很大的人力和时间。
4、稳定性测试。
我们使用它进行采集和编码测试，发现其对服务端的协议适配性不是很好，经常有无法推送节目的现象发生。在网络抖动或者短时间中断的情况下，程序会自动退出，导致直播服务中断。这些问题我们无法找到原因，官方也没有专职人员可以提供技术支持，因为整个项目是由一群分布在世界各地的志愿者来维护的。这种花费了10多年时间做的软件项目，短时间内我们还无法掌握其核心架构和模块功能实现方式。源代码也非常晦涩难懂。
通过以上测试，我们发现A、B、D这三种方案可行性都很差，因为当前我们没有足够强的开发实力以及充足的开发时间。只有C 这款方案Zui适合我们现实的应用场景。Zui终领导决定下来采用“直播大师”这款软件，并在此基础上做二次开发。
第二步，移动端视音频采集
除了做PC端游戏的直播，我们还要做手机端游戏和户外场景的直播，开发手机端的直播工具软件势在必行。
众所周知，当前主流的两大手机操作系统就是google的android和Apple的iOS。两大操作系统的开发语言和开发框架差异很大，android系统采用java语言来做应用层开发，而Apple的iOS系统采用Objective-C语言做开发。两个平台具有各自不同的开发接口和特性，两个平台上的应用程序没有任何兼容性，我们必须组建两个APP开发小组来完成这件事情。
目标确定了，下面就是技术路线选型工作。
对于手机端的视音频采集编码技术，我们有过类似的经验。考虑到手机的处理能力，我们的技术路线是利用手机自身核心处理器的视频编码能力来完成。在Android端调用Mediacodec开发接口来实现，iOS端调用苹果提供的CoreVideo框架来实现，编码格式上我们采用H.264视频编码和AAC音频编码，通过硬件编码方式极大地降低了移动终端的CPU负荷与功耗，。在协议的选择上，我们采用当前主流的RTMP协议由客户端向服务器端推送数据。RTMP是Adobe公司制定的一款流传输一些，结构比较简单，自己研究就能搞定，这款协议在行业内应用非常广泛，便于不同产品的集成。
字幕和台标的叠加
在PC端，顺景科技的直播大师已经具备了专业级的字幕台标叠加功能，下面考虑的主要是移动端的实现。还好，顺景科技也给我们提供了技术支持，通过渲染技术实现了字幕和台标的叠加功能。在他们的帮助下我们的移动端软件还加入了图像美颜功能，支持120多种常见滤镜效果。
第三步，内容的发布和转码
前端设备将直播的视音频内容采集处理后，推送给平台的源站服务器，我们将源服务器部署在了北京本地的运营商骨干节点机房（近距离便于维护）。源服务器采用多机集群热备份机制，防止一台源站服务器宕机后影响整个平台的稳定运行。
源站服务器连接有专业的磁盘阵列存储设备，当源站服务器接收到数据后，复制N份转发给下面的N个二级CDN节点，复制一份给转码服务器。转码服务器将接收到的每一个流进行实时的转码，主要是将高清码流转换一份标清码流给小屏移动终端，移动终端接收标清小码流不仅符合自身的小屏分辨率需要，可以降低对移动端的解码能力要求，还能有效节省带宽成本。
转码服务器将实时的直播码流录制保存到磁盘阵列中，供以后点播回放使用。
在这个实时转码环节，我们突然发现之前考虑的欠周到，因为根据我之前在华为做IPTV的经验，内容的转码可以交给高性能的服务器来完成，之前我们用配置四颗IntelE5系统八核心的处理器来做视频转码，转码1080P视频可以达到8倍速以上。当我将之前的技术用于这个项目中测试时发现，我们之前的转码技术还是远远不能满足要求。因为我们当前的应用是大并发的直播运营，在同一时间平台可能要对数百个甚至上千个直播流进行实时转码，这样就需要很多台高配置的服务器，这样很难控制运营成本；直播流的转码必须是实时性的，要求转码延迟在1秒以内，这和我们之前的2~3秒延迟还是有很大差距的。如果对原有的技术进行改造，这部分的开发周期预计要1年以上，还没有的把我可以达到的效果。Zui后在多方面的尝试后，我们采用了直播大师厂商顺景科技提供的他们自行开发的先锋云转码方案，因为他们的方案在转码性能上不仅有更大的提升（单台服务器可以达到1080P30倍速的转码效率），他们的转码实时性也更强，转码延迟可以控制在500ms以内。
第四步，流媒体发布
流媒体发布这个环节对于整个平台来说也是至关重要，因为Zui终面向终端用户提供服务的是分布在全网的流媒体服务器，流媒体服务器的稳定性以及性能优劣决定着终端用户的体验效果和平台的运营成本。根据之前做IPTV的经验，我们在这个项目中选择的技术路线还是自行开发，当然还是基于之前做IPTV流媒体服务器的基础来做，核心技术点又有如下的改进：
1. 流媒体服务器还是采用C语言实现，保障运行效率Zui高；
2. 将之前的多进程模型改成异步IO模型，提高服务器的并发处理性能；
3. 在协议层上增加对RTMP、HLS协议的支持；
4. 引入hadoop这一分布式架构，便于大规模分布式部署、调度和容错；
通过这些改进，流媒体服务器的整体性能又会有一个质的飞跃。
这部分开发工作要持续半年多的时间。
第五步，CDN内容分发
这方面是我的业务特长所在，与我之前做IPTV平台的技术路线相同，主要是对流媒体数据在全网范围内的多个节点之间进行快速的分发，从而提高终端用户的体验效果。
在协议的选择上，我们根据直播和点播应用的特点，支持RTMP协议、HTTP协议、UDP协议这三个类型。
节点服务器的建设方面，我们根据国内互联网的整体布局，采用中心节点->各省级节点->地市级节点三级架构模式，把主要的用户流量引导到第三级节点，是第二级节点，之这样设计，主要因为越到中小城市，带宽价格越低，这样可以极大地节省后期的运营成本。
为了保障平台运行的稳定性，我们将CDN系统部署在64位Linux服务器上，与优酷这类大的视频门户技术架构相同。
按照公司业务规划，我们前期先部署一、二级节点，做到每个省会城市都有一个CDN分发节点，每个二级节点有3台以上的服务器组成分发集群。
第六步，终端播放器开发
在终端的解码回放部分，我们考虑自行开发PC、Android和iOS三个终端的播放器，由于三种终端采用不同的操作系统平台，我们成立了三个开发小组来分别完成，下面讲一下技术路线：
PC端：
采用行业内主流的技术路线，基于Adobe的FlashPlayer做应用层开发，这也是当前Zui成熟时的技术路线。为了缩短开发周期，我们基于Adobe的OSMF播放器框架来做，开发周期控制在2个月以内比较可行。
Android端：
Android端的播放器开发我们考虑到的是终端的解码性能，因为解码框架有多个可选，比如FFMPEG、VLC、MediaPlayerAPI、Exoplayer等，从我们自身的熟悉程度和项目的可控性上考虑，Zui终决定采用google的Exoplayer做二次开发，开发周期可以控制在2个月以内。
iOS端：
iOS端的播放器也是基于同样的考虑，我们选择了苹果提供的VideoToolbox开发接口，通过它可以直接调用苹果处理器自带的硬件解码功能，这样可以大大降低设备的功耗，延长电池的续航时间。
经过团队15个人的艰苦奋战和N多个的加班熬夜，四个月后平台原型已经基本宣告完成，在应用功能上还需要完善，从性能测试上看，我们的技术路线是正确的，因为整体性能比优酷、乐视这些同行业兄弟站点高出了20%左右，资金投入上并没有高于其他平台，反而比他们还要低。在整个平台的架构上，我们还考虑到了向后的兼容性和可升级性，比如在整个内容发布环节我们都支持了H.265视频编码标准，现在还未大规模应用起来，这个产业链在2~3年内应该会有很大的起色，也是未来的主流标准，因为H.265比H.264的压缩效率提高了一倍，这就意味着采用这项技术不仅能将存储成本降低一半，还能够将带宽消耗降低一半，这无疑会为将来的运营节省大笔开支。
能够如期完成这样一个工程，团队的兄弟姐妹们付出了很多辛劳与汗水，我要为他们点个赞！作为整个项目的技术负责人，取得这样的成绩自己也感到很欣慰，要为自己点个赞，哈哈~-~
以上就是我做这个直播平台的一段经历和收获的一点点经验，记录下来既是对自己的也想与各位创业者和同行一起分享，希望对大家有所帮助。如果您有不同的见解，欢迎交流和拍砖！