1. 首先非常不建议企业自己研发和部署直播平台，原因大概有以下几点：
a. 流程特别复杂，不光是简单的推流和拉流这么简单；
b. 研发成本异常高（流媒体开发人员、开发周期、现在直播第三方服务都白菜价了）;
c. 服务器、带宽、CDN、质量监测、鉴黄、存储、运维 等等成本非常高；
d. 稳定性是你们终生要不断优化和调试的工作，这块成本很高；
e. 建议使用第三方直播服务，整个平台非常可控；
......
2. 看了第一条如果还是要持续坚持研发属于自己的直播平台，希望接下来的内容能帮助到你；
3. 客户端要具备的能力：
a. WIN & MAC 要有主播/观众 端的客户端，当然也可以用 OBS（开源）；
b. Web & H5 & 小程序 & IOS & Android 都要具备可集成的SDK和推流和拉流的能力；
c. Flash 显然已经被淘汰了，现在的推流和拉流协议必须要支持：HLS、FLV、RTMP、WebRTC，简介如下；
HLS：就是 m3u8，苹果公司开发的，（时间延迟较高），他会把一个时间间断的视频流切成N片，保存为ts格式，浏览器拉取的是一个视频文件list，解析文件list去拿到视频，造成了时间的延迟，目前依然为主流格式，
FLV：flash vedio,基于HTTP协议，能够较好的穿透防火墙，网络延迟降低，目前为主流视频流格式；
RTMP：实时消息传输,低延迟基于TCP协议，也可以封装在HTTP上，RTMP协议有几个变种：RTMPE 增加了加密，RTMPT基于HTTP请求之上，防火墙穿透； RTMPS 协议类似于RTMP，增加了SSL/TLS的功能；
WebRTC：基于网页的视频协议，基于UDP协议，谷歌开源，目前支持Chrome内核浏览器，低网络延迟，流量少、性能高，RTMP和HLS主要基于TCP传输，为了保证传输质量会造成很多ACK，在网络不好的情况下会产生很多重传包，而WebRTC传输是基于RTP和RTCP，重传策略是基于NACK完成，有三种方案MCU/SFU/MESH，目前为主流视频直播方案（多人连麦互动）；
4. 直播平台---流媒体服务器推荐框架选型：
a. SRS 是国人写的一款非常优秀的开源流媒体服务器软件，可用于直播/录播/视频客服等多种场景，其定位是运营级的互联网直播服务器集群，一直在维护迭代；
b. FFMPEG 用于视频流的格式转换和视频画面处理，比如 加水印、字母、视频流转码，RTMP转HLS / FLV、视频清晰度转换 RTMP原画 转 360P/720P/1080P 等等，视频录制等等；
c. OBS推流拉流工具；
d. MSE 基于chrome浏览器的播放器加密拓展，之前都是把整个视频连接放到页面里，非常不安全，现在是基于MSE协议进行各个视频码流的播放，这个过程做了 防盗链和token校验；
e. WebRTC: 基于谷歌开源，也有几个不错的开源框架:licode/jitsi；
f. 第三方服务，鉴黄/鉴暴，通过旁路进行视频画面切片传到第三方服务鉴别；
5. 直播平台---存储方案选型：
a. 分布式存储即可，Ceph，第三方（阿里OSS、华为OBS）
b. Mysql 多主多从
c. Redis & ignite
d. 时序性数据库influxdb
e. 消息队列 rabbitmq / kafuka
6. 直播平台---平台开发语言选型：
a. 后端PHP、python、java;；
b. 前端Js、JQuery、Vue；
7. 直播平台---视频流分发选型：
a. CDN，融合多家CDN做主备；
b. IP地址库，通过IP地址优先就近原则分配拉流/推流节点；
8. 直播平台---业务架构：
a. 基础设施层：流媒体系统、埋点监测系统、大数据分析系统（平台数据、用户行为数据 等）、运维监控系统、消息系统、安全系统、分布式存储系统、DevOps平台、调度系统 、算法模块 等等；
PaaS：这块存在的价值逐渐被缩小；
b. 能力层：
i. 直播LSS：多端推/拉流、直播转码、实时录制、实时字幕、美颜/滤镜、直播合法性监控；
ii. 点播VOD：上传/录制/下载、转码、存储、多端播放 等；
iii. 互动系统：多人连麦、PK、实时在线混流、多路合成一路；
iv. 物料平台：支持各种格式文档上传、Canvas白板等等；
v. IM： 广播消息、礼物播报、NLP、IM权限管理（禁言等）；
vi. 互动组件：礼物、公告、签到、投票/积分、红包、问卷考试、邀请卡、白名单控制、物品推荐等等；
vii. ......
c. 中台：
i. 业务中台：API中心（SDK、API、Wiki、Demo）、权限控制 等；
ii. 用户营销中心：行为仓库、用户画像、标签系统、营销策略库、会员营销策略 等等；
iii. 数据营销中心：智能推荐、广告系统（RTB/DSP/DMP=）、平台搜索引擎、SEO优化策略；
iv. 数据监控中心
v. 共享中心：
d. 前台：SaaS、定制化、解决方案（政企、医疗、教育、电商、金融、保险、场景 等等）
9. 直播平台---通讯流程：
a. 直播端（client/mob/h5/web）：发起直播请求到流媒体服务器，流媒体服务器进行发起端权限校验，服务端通过权限校验后给直播发起端一个信令，允许把直播流推到流媒体服务器；正常来说推流一般是RTMP协议，如果是WebRTC协议 流媒体会进行转码为 RTMP格式； 如果为旁路（多人互动），对WebRTC进行多路采集由流媒体服务器进行混合最终输出一路旁路； 这个时候会有一个小判断，直播发起后，服务器的调度模块会优先通过IP等信息就近分配推流节点；
直播前会进行环境检查：摄像头、麦克风、网络等；
b. 流媒体服务器群：接收前端推流、进行视频流处理（转码HLS/FLV/RTMP等，清晰度转换：360/720/1080P 等、视频画面处理（字幕、打点等）、视频录制（保存为m3u8格式、进行视频切片、存储、鉴黄等））、然后将最终处理好后的视频源流和各个清晰度的流 推向融合CDN（融合CDN就是把流推送到多家CDN厂商，比如阿里云腾讯云之类，做CDN热备）；
c. 融合CDN系统：存在调度、质量监控、视频格式输出 等模块，调度（CDN多家厂商，按照权重配比，优先/次先 分配给拉流端）、质量监控（对CDN上所有的视频流进行巡检，发现网络延迟高的立马对这家CDN进行地区降权，因为很有可能这家CDN 在上海很卡，在北京流畅，优先分配网络延迟低的），现在好多CDN厂商都具备直播CDN，不需要服务器对拉流端各个视频格式的转换，CDN就替你做了处理，CDN会自动输出拉流格式（HLS/FLV等等），正常一路CDN至少有4路流（原画、360、720、1080P），而且CDN的出现大大降低了直播整个平台的拉流复杂度；
d. eCDN，基于P2P的协议传输，为了解决内网分发的性能瓶颈问题，如果1000人都在一个公司观看一场直播，那么之前的方案就是1000人都从公司的路由器作为出口进行CDN拉流，这样无疑是浪费网络资源，为了解决这个问题 底层流媒体新增了P2P协议，内网观看的群体，通过设备性能选举出1个或多个listener，向其他设备传输视频流，这样大大减少了公网流量的支出，而且为了防止内网阻塞，一旦P2P出现问题，我们会进行降级，使用CDN进行拉流；
e. 拉流调度系统，根据拉流端的IP和网络状况等信息，结合CDN调度系统，获取到节点最近和根据拉流端的网络情况动态切换 视频清晰度；
f. 运维系统：就主流那几套，k8s、docker、grafana、zabbix、直播/房间监控（自己开发） 等等；
g. SaaS平台：就平台的集群化部署，SSO联登、组件服务（礼物、IM ....）等等，这个每家的逻辑不一样；
h. 安全措施：防火墙、WAF、等保三级、重保、接口参数全加密 等等
i. 以上平台看起来简单，如果真要自己团队开发是个非常大的成本；
j. 信令服务器，通过websocket协议进行信令的接收和信令的广播；
l. ... ...
10. 怎么监测直播/画面质量：
a. 直播方的帧率、码率和直播方画面的的清晰度 来计算分值；
b. 视频的雪花点监测；
c. 直播方的上传网络速度；
d. 画面是否扭曲、拉伸等非正常情况；
e. ... ...
11. 专业名词释义：
a. GOP：（Group of Pictures）画面组，关键帧间隔，一个GOP就是一组连续的画面，每个画面都是一帧，一个GOP就是大量帧的集合。直播的视频数据流，其实是一系列的视频帧率组件，包括I帧、P帧等。一个GOP就是以一个I帧，多个P帧开始。当用户第一次观看的时候，播放器需要找到I帧才能开始播放，而播放器会到服务器寻找到最近的I帧反馈给用户。因此，减少GOP帧的数量，能减少播放器加载GOP帧所用的时间。在直播推流端GOP一般建议设置为1~2s。
b. 码率： 又叫比特率，计算公式：码率(kbps)=文件大小(KB) * 8 / 时间(秒)，取决为网络传输速度；
c. 帧：以帧称为单位的图像连续出现在显示器上的频率（速率），帧分为N制和Pa制，帧取决于视频播放的连贯性、
12. 为何基于H264而非H265
不想写了，后续在补充吧
