直播平台技术方案说明

直播平台技术方案说明一、概述我们对整个项目做出如下假设：1万摄像头，每个摄像头平均100个人访问，一个人一年按166天*6小时*0.024=24小时即一天来计算，即2400万天的流量来计算。一路视频按1Mbps来计算则是1Mbps/8bit*60秒*60分*24小时=10GByte，即2400万*10Gyte=24000万GByte。按0.3元/G来计算，则是7200万元的流量费，即使按此流量假设能与云服务提供商谈到0.1元，还是2400万元的流量费。但实时上目前主流的摄像机就是D1(704*576)子码流都不一定能做到1Mbps,如果是1080P正常的娱乐直播或是视频会议的直播都会是8Mbps，那么成本就将会是2400万*8差不多是2个亿/年。从使用的概率上来说，一个学校有2-6个家长，平均每个摄像头所有家长一年只看24小时的概率也只会高不会低，有些摄像头可能会上千人看。而价格上，目前阿里云，腾讯云，及电信机房云的企业正常采购价格普遍在0.68元/GB左右,也是远超这个数字。0.1元/GB只是最大可能的假设条件，目前还没有听说有这么低的合作价格。综上所述，2400万的年流量使用费是这个项目的基数，而且这个流量仅仅只是计算第三段从服务器转发到公网的数量，不计算第一段从摄像机上传到公网，第二段从公网下载到服务器，及第四段从公网下载到手机的部分，从某个角度来说这个数字足以让整个项目的可行性大打折扣。我们所有的技术支持都是围绕着这个最低的2400万的基数来考虑的，通过前端的超低码流，录像与实时分流，实时根据不同的并发量来做多种不同价格流量体系的负载平衡。即能保证瞬时的超高并发量，也能最大程度的降低流量使用费用。只有流量成本大幅度的下降了，才有可能考虑增加各种媒体的视频导入，才能更大可能的发挥系统的使用价值。同时提供公众号，APP等各种媒体的方便访问。解决了转发流量成本的问题，前端采集及终端的显示部分就可以广开方便之门。二、前端采集部分前端采集部分主要涉及到以下几个方面：（1）现有设备的兼容问题，我们通过一个RTMP推流的设备，可以将现有已经安装的海康、大华、宙视达等摄像机视频通过RTSP取回来，然后填入1-2个不同的RTMP服务器地址，然后主动推流到RTMP服务器。这个设备采用海思的摄像机硬件定制的，不是属于市场流通的产品，不同的渠道单台设备的价格差别可能超过600元。我们能提供的材料成本价小于280元，而市场价为880元，而且880元的价格也算是非常低的了。总量为10000台就算按10%即1000台来算，也是省下60万。这种设备可能占了50%以上，则近300万的成本，而且此项成本严重影响项目的可行性。（2）专业摄像机HDMI信号接入采用直播编码器。用于一些需要人为录制的项目现场，比如晚会或是班上，学校的重要活动。将电脑接入HDMI编码器也可以用于远程教学等场合。此编码器我们提供材料价格小于650元，而市场价是1500元，最好的渠道价也在1200元以上，价格差别是550元，按500台计算就是27.5万的价格差。直播编码器是此项目往专业化增值应用，是用安防设备成本实现视频会议功能的差异化最大最为显著的应用，也是向业主方及主管单位呈现整个技术的关键支撑点。（3）前端安卓、IOS手机采集端，用于春游，田径等户外活动的直播。如果没有一定的技术积累，此项技术单独开发的成本可能超过10万，而且每个客户端可能还需支付一定的版本成本。（4）关于前端更高音质的处理问题，所有的摄像机硬件目前音频只支持PCM8K或是16K，达不到乐音的CD音质效果（44KZ)，及更高的128或是256KZ的采集，而电脑标配的声卡早在20年前就已经达到这个效果了。我们可以协助实现在部分专业的场合，前端在一台电脑上运行我们的推流程序，通过RTSP从IPC上取到普通安防摄像机的视频，可以是800万/1200万或是更高的摄像头，通过DIRECTSOUND技术从本机的声卡上取到CD以上音频效果，然后通过第三方开源的算法压缩为G.711格式，最后将G.711的音频数据与RTSP取回来的视频数据进行唇音同步处理。这项技术也是视频会议中的关键技术，此项音频技术与800万的安防摄像头组合，从音视频的画质效果上来说远超目前主流视频会议。（5）第二阶段如果手机端的APP研发完成，支持H.265的解码了，前端我们有专业的摄像机极大的降低了码流。在活动量不是很大的情况，极致的是可以实现800*480的子码流实现小于128Kbps，而目前704*576的D1画质都会在1024Kbps左右。单此一项技术就可降到8分之一，即2400万降到300万，对于一个省级的项目，这是能接受的上限水平了。另外前端的定时推流功能，对于第二段传输成本即从公网上下载到服务器的会有很大的改观，只有上课的时间，或是部分课程的时间才会推流。这个数字就可以从365天降到166天，从24小时降到4小时左右，但并不影响第三段及第四段的流量成本。三、中间转发部分上面已经初步说明了，中间转发部分的流量成本很大程序决定了整个项目的可行性。我们的重头戏也就在这个环节了，我们根据目前与这个项目有关的各个渠道的资源与信息，可以让这个2400万的流量成本降到240万以内，即百分之一的成本。我们分两个方向来优化，一是公有云方向，二是自建服务器的方向。首先肯定是不能用第一种云端独立操作系统云主机模式，这便是高于0.3元/GB区间，而且网络的并发性是很难实现的。从0.1到0.3是第二种专业直播云的区间，一是要实现RTMP标准推流才能使用这个服务，如果是非RTMP的私有协议，则只能用自建服务器的方式即0.68元/GB的云主机的方式。而从0.1到0.3之间则是不同的云服务器，及单项目流量规模的渠道价格差别了。小于0.1的则是属于第三种即云存储的流量成本了，小到什么程度也是不同服务端的价格差及量的阶梯价之间了。对于公有云来说，在高并发性的时候是必须用到的，这个240万也很大程度来自于这个方向的成本。同时在低并发的时候，及录像回放的时候，我们通过与第一段摄像机端的宽带做一些绑定，可以与各地的运营商做一些商务沟通，将这个流量成本转嫁到接近于零成本。当然服务器的硬件及录像用的硬件成本还是需要的。当然这个硬件成本也并不包含在240万之内，因为这些硬件可能需要分摊到5年或是更长时间中去，基本可以忽略不计。这么节省的方案，我们至少是需要一套技术方案来做分流，这便是我们能提供的负载平衡的方案。根据不同的并发数，动态决定每个摄像机往哪个服务器推流，哪个终端通过哪个视频地址来取得视频。四、终端显示部分终端显示一是关于HTML5的实时视频访问，二是关于HTML5录像文件列表及录像点播，三是关于非HTML5流览器情况下的264的视频解码，四是基于超低码流的H.265在APP端的解码。我们会提供这引起技术的指导及相关的基本库文件、DEMO等。另外关于上级主管单位的联动上墙，统一运营管控是我们的主营业务即8K地图联网平台的范围，那是设备级合作的范围，我们有正常的产品体系予以支持，自然也是成体系的服务。五、总结受人之托，终人之事是我们的服务宗旨。但此项目也是我们想进一步完善直播技术体系的同行目标，所以我们会主动进行各种技术的预研，也乐于分享成果。这个技术方向于我们公司所于的战略位置，经过双方的当面沟通应该有些了解。有项目机会的时候，我们也乐于去推进它，抢占企业级的专业直播市场，只是用互联网领域的直播技术与安防设备成本解决企业的视频会议及培训等问题，我们提供设备加技术服务的模式，融于我们的主体技术方向8K地图联网平台，而非互联网级的纯粉丝运营路线。换句话说我们只想融入互联网的技术，而并不想介入互联网的运营，因为公司的运营底子及客户基础都局限于视频的研发与技术服务这个领域。本方案也是我们的诚心体现，知无不言，不完全基于纯粹的商务，也是想通过这个技术服务建立双方的强关系合作，以便将来在基于整个教育体系的大联网平台方面有更为深度的合作。