现在直播应用非常火爆，它以生动直观的方式向用户传达最真实的现场信息，受到广大用户的普遍欢迎。小编作为一名技术人员，经常开发各种直播平台，（娱乐直播、游戏直播、教育直播、财经直播等）下面我把自己积累的一些经验分享给大家，希望和大家一起交流学习，共同进步。
第一步，移动端视音频采集
首先，对于手机端的视音频采集编码技术，我们有过类似的经验。考虑到手机的处理能力，我们的技术路线是利用手机自身核心处理器的视频编码能力来完成。在Android端调用Mediacodec开发接口来实现，iOS端调用苹果提供的Core Video框架来实现，编码格式上我们采用H.264视频编码和AAC音频编码，通过硬件编码方式极大地降低了移动终端的CPU负荷与功耗，。在协议的选择上，我们采用当前主流的RTMP协议由客户端向服务器端推送数据。RTMP是Adobe公司制定的一款流传输一些，结构比较简单，自己研究就能搞定，而且这款协议在行业内应用非常广泛，便于不同产品的集成。
第二步，内容的发布和转码
前端设备将直播的视音频内容采集处理后，首先推送给平台的源站服务器，我们将源服务器部署在了北京本地的运营商骨干节点机房（近距离便于维护）。源服务器采用多机集群热备份机制，防止一台源站服务器宕机后影响整个平台的稳定运行。
源站服务器连接有专业的磁盘阵列存储设备，当源站服务器接收到数据后，首先复制N份转发给下面的N个二级CDN节点，同时复制一份给转码服务器。转码服务器将接收到的每一个流进行实时的转码，主要是将高清码流转换一份标清码流给小屏移动终端，移动终端接收标清小码流不仅符合自身的小屏分辨率需要，同时可以降低对移动端的解码能力要求，还能有效节省带宽成本。
第三步，流媒体发布
流媒体发布这个环节对于整个平台来说也是至关重要，因为最终面向终端用户提供服务的是分布在全网的流媒体服务器，流媒体服务器的稳定性以及性能优劣决定着终端用户的体验效果和平台的运营成本。根据之前做IPTV的经验，我们在这个项目中选择的技术路线还是自行开发，当然还是基于之前做IPTV流媒体服务器的基础来做，核心技术点又有如下的改进：
1. 流媒体服务器还是采用C语言实现，保障运行效率最高；
2. 将之前的多进程模型改成异步IO模型，提高服务器的并发处理性能；
3. 在协议层上增加对RTMP、HLS协议的支持；
4.引入hadoop这一分布式架构，便于大规模分布式部署、调度和容错；
通过这些改进，流媒体服务器的整体性能又会有一个质的飞跃。
第四步，CDN内容分发
这方面是我的业务特长所在，与我之前做IPTV平台的技术路线相同，主要是对流媒体数据在全网范围内的多个节点之间进行快速的分发，从而提高终端用户的体验效果。
在协议的选择上，我们根据直播和点播应用的特点，支持RTMP协议、HTTP协议、UDP协议这三个类型。
节点服务器的建设方面，我们根据国内互联网的整体布局，采用中心节点->各省级节点->地市级节点 三级架构模式，把主要的用户流量首先引导到第三级节点，然后是第二级节点，之所以这样设计，主要因为越到中小城市，带宽价格越低，这样可以极大地节省后期的运营成本。
第五步，终端播放器开发
在终端的解码回放部分，我们考虑自行开发PC、Android和iOS三个终端的播放器，由于三种终端采用不同的操作系统平台，因此我们成立了三个开发小组来分别完成，下面讲一下技术路线：
PC端：
采用行业内主流的技术路线，基于Adobe的Flash Player做应用层开发，这也是当前最成熟时的技术路线。为了缩短开发周期，我们基于Adobe的OSMF播放器框架来做，开发周期控制在2个月以内比较可行。
Android端：
Android端的播放器开发我们首先考虑到的是终端的解码性能，因为解码框架有多个可选，比如FFMPEG、VLC、MediaPlayer API、Exoplayer等，从我们自身的熟悉程度和项目的可控性上考虑，最终决定采用google的Exoplayer做二次开发，开发周期可以控制在2个月以内。
iOS端：
iOS端的播放器也是基于同样的考虑，我们选择了苹果提供的VideoToolbox开发接口，通过它可以直接调用苹果处理器自带的硬件解码功能，这样可以大大降低设备的功耗，延长电池的续航时间。
以上就是小编怎么创建播平台的一段经历和收获的一点点经验，记录下来既是对自己的总结，同时也想与各位创业者和同行一起分享，希望对大家有所帮助。如果您有不同的见解，欢迎咨询交流!
第一步，移动端视音频采集
首先，对于手机端的视音频采集编码技术，我们有过类似的经验。考虑到手机的处理能力，我们的技术路线是利用手机自身核心处理器的视频编码能力来完成。在Android端调用Mediacodec开发接口来实现，iOS端调用苹果提供的Core Video框架来实现，编码格式上我们采用H.264视频编码和AAC音频编码，通过硬件编码方式极大地降低了移动终端的CPU负荷与功耗，。在协议的选择上，我们采用当前主流的RTMP协议由客户端向服务器端推送数据。RTMP是Adobe公司制定的一款流传输一些，结构比较简单，自己研究就能搞定，而且这款协议在行业内应用非常广泛，便于不同产品的集成。
第二步，内容的发布和转码
前端设备将直播的视音频内容采集处理后，首先推送给平台的源站服务器，我们将源服务器部署在了北京本地的运营商骨干节点机房（近距离便于维护）。源服务器采用多机集群热备份机制，防止一台源站服务器宕机后影响整个平台的稳定运行。
源站服务器连接有专业的磁盘阵列存储设备，当源站服务器接收到数据后，首先复制N份转发给下面的N个二级CDN节点，同时复制一份给转码服务器。转码服务器将接收到的每一个流进行实时的转码，主要是将高清码流转换一份标清码流给小屏移动终端，移动终端接收标清小码流不仅符合自身的小屏分辨率需要，同时可以降低对移动端的解码能力要求，还能有效节省带宽成本。
第三步，流媒体发布
流媒体发布这个环节对于整个平台来说也是至关重要，因为最终面向终端用户提供服务的是分布在全网的流媒体服务器，流媒体服务器的稳定性以及性能优劣决定着终端用户的体验效果和平台的运营成本。根据之前做IPTV的经验，我们在这个项目中选择的技术路线还是自行开发，当然还是基于之前做IPTV流媒体服务器的基础来做，核心技术点又有如下的改进：
1. 流媒体服务器还是采用C语言实现，保障运行效率最高；
2. 将之前的多进程模型改成异步IO模型，提高服务器的并发处理性能；
3. 在协议层上增加对RTMP、HLS协议的支持；
4.引入hadoop这一分布式架构，便于大规模分布式部署、调度和容错；
通过这些改进，流媒体服务器的整体性能又会有一个质的飞跃。
第四步，CDN内容分发
这方面是我的业务特长所在，与我之前做IPTV平台的技术路线相同，主要是对流媒体数据在全网范围内的多个节点之间进行快速的分发，从而提高终端用户的体验效果。
在协议的选择上，我们根据直播和点播应用的特点，支持RTMP协议、HTTP协议、UDP协议这三个类型。
节点服务器的建设方面，我们根据国内互联网的整体布局，采用中心节点->各省级节点->地市级节点 三级架构模式，把主要的用户流量首先引导到第三级节点，然后是第二级节点，之所以这样设计，主要因为越到中小城市，带宽价格越低，这样可以极大地节省后期的运营成本。
第五步，终端播放器开发
在终端的解码回放部分，我们考虑自行开发PC、Android和iOS三个终端的播放器，由于三种终端采用不同的操作系统平台，因此我们成立了三个开发小组来分别完成，下面讲一下技术路线：
PC端：
采用行业内主流的技术路线，基于Adobe的Flash Player做应用层开发，这也是当前最成熟时的技术路线。为了缩短开发周期，我们基于Adobe的OSMF播放器框架来做，开发周期控制在2个月以内比较可行。
Android端：
Android端的播放器开发我们首先考虑到的是终端的解码性能，因为解码框架有多个可选，比如FFMPEG、VLC、MediaPlayer API、Exoplayer等，从我们自身的熟悉程度和项目的可控性上考虑，最终决定采用google的Exoplayer做二次开发，开发周期可以控制在2个月以内。
iOS端：
iOS端的播放器也是基于同样的考虑，我们选择了苹果提供的VideoToolbox开发接口，通过它可以直接调用苹果处理器自带的硬件解码功能，这样可以大大降低设备的功耗，延长电池的续航时间。
以上就是小编怎么创建播平台的一段经历和收获的一点点经验，记录下来既是对自己的总结，同时也想与各位创业者和同行一起分享，希望对大家有所帮助。如果您有不同的见解，欢迎咨询交流!
