这个方向应该是今年最火的了。7月份和8月份就接到直播公司的面试邀请，只不过当时没多少这方面的经验。之前的关于直播平台的开发，我的方向一直都是iOS多媒体开发工程师的，没想太多。但是，逐渐的了解到很多公司都是接的第三方的直播框架和CDN。譬如乐视云，腾讯云，七牛等平台的SDK。待续吧，东西太多了，之前藏了很多没开放，因为很多想表达的东西不知道表达了。
直播服务普遍采用了RTMP作为流媒体协议，FLV作为封装格式，H.264作为视频编码格式，AAC作为音频编码格式。采用RTMP作为直播协议的好处在于其被Flash播放器支持。而Flash播放器如今已经安装在全球99%的电脑上，并且与浏览器结合的很好。因此这种流媒体直播平台可以实现“无插件直播”，极大的简化了客户端的操作。封装格式，视频编码，音频编码方面，无一例外的使用了FLV + H.264 + AAC的组合。FLV是RTMP使用的封装格式，H.264是当今实际应用中编码效率最高的视频编码标准，AAC则是当今实际应用中编码效率最高的音频编码标准。视频播放器方面，都使用了Flash播放器。
视频直播，可以分为 采集，前处理，编码，传输，解码，渲染 这几个环节，下面分别说下：
采集，iOS是比较简单的，Android则要做些机型适配工作，PC最麻烦各种奇葩摄像头驱动，出了问题特别不好处理，建议放弃PC只支持手机主播，目前几个新进的直播平台都是这样的。
前处理，现在直播美颜已经是标配了，80%的主播没有美颜根本没法看。美颜算法需要用到GPU编程，需要懂图像处理算法的人，没有好的开源实现，要自己参考论文去研究。难点不在于美颜效果，而在于GPU占用和美颜效果之间找平衡。GPU虽然性能好，但是也是有功耗的，GPU占用太高会导致手机发烫，而手机发烫会导致摄像头采集掉帧，iPhone6尤其明显，因为iPhone6的CPU和前置摄像头很近。
前处理
在这个环节主要处理美颜、水印、模糊等效果。特别是美颜功能几乎是直播的标配功能，没有美颜的直播主播们根本提不起兴趣。我们见过太多case是因为没有美颜功能被抛弃使用的。另外国家明确提出了，所有直播都必须打有水印并回放留存15天以上。所以，在选择直播SDK时，没有美颜和水印功能基本就可以选择放弃了。
美颜实际上是通过算法去识别图像中的皮肤部分，再对皮肤区域进行色值调整。通常情况下人的肤色与周边环境色调存在较大差异，通过颜色对比，找到皮肤的基本轮廓，进一步进行肤色检查还可以确定人脸范围。找到了皮肤的区域，可以进行色值调整、添加白色图层或调整透明度等来等来达到美白效果。美颜除了美白效果还需要磨皮功能，磨皮实际上就是用模糊滤镜实现的。滤镜有很多种，如高斯滤波，双边滤波，导向滤波，到底选择什么样的模糊滤镜各家也有自己的喜好。
在美颜处理方面，最著名的GPUImage提供了丰富的效果，同时可以支持IOS和Android，还支持自己写算法实现自己最理性的效果。GPUImage本事内置了120多种常见滤镜效果，添加滤镜只需要简单调用几行代码就可以了，比如大家可以试试使用GPUImageBilateralFiter的双边滤波滤镜来处理基本的磨皮效果，想要实现更理想的效果还是要通过自定义算法去实现的，各家也都有自己一套算法。
编码，肯定要采用硬编码，软编码720p完全没希望，勉强能编码也会导致CPU过热烫到摄像头。硬编码兼容性又是一个大坑，android上要有人去填。编码要在分辨率，帧率，码率，GOP等参数设计上找到最佳平衡点。
传输，自己做不现实，交给CDN服务商吧，也就是贵了点，相信有志于做直播平台改变世界的你不差钱。假设2W PCU大约每月带宽费用100万左右，因为清晰流畅的720p要1.5mbps左右。CDN只提供了带宽和服务器间传输，发送和接收端的网络连接抖动缓冲还是要自己写的。不想要卡顿，必然要加大缓冲，会导致延迟高，延迟高影响互动性，要做权衡。
解码，也肯定要硬解码，目前手机普遍支持硬解了，只是android上还是有兼容性大坑要填。
渲染，这个难点不在于绘制，而在于音画同步，目前几个直播做得都不好。
此外音频还有几个坑要填，比如降噪，音频编码器的选择，各种蓝牙耳机，各种播放模式的适配等，如果你想做主播和观众连线聊天，还有个回声消除问题。
以上是媒体模块，还有信令控制，登录、鉴权、权限管理、状态管理等等，各种应用服务，消息推送，聊天，礼物系统，支付系统，运营支持系统，统计系统等。
后台还有数据库，缓存，分布式文件存储，消息队列，运维系统等。
现今移动直播技术上的挑战要远远难于传统设备或电脑直播，其完整的处理环节包括但不限于：音视频采集、美颜/滤镜/特效处理、编码、封包、推流、转码、分发、解码/渲染/播放等。
直播常见的问题包括
主播在不稳定的网络环境下如何稳定推流？
偏远地区的观众如何高清流畅观看直播？
直播卡顿时如何智能切换线路？
如何精确度量直播质量指标并实时调整？
移动设备上不同的芯片平台如何高性能编码和渲染视频？
美颜等滤镜特效处理怎么做？
如何实现播放秒开？
如何保障直播持续播放流畅不卡顿？
视频、直播等基础知识
什么是视频？
首先我们需要理解一个最基本的概念：视频。从感性的角度来看，视频就是一部充满趣味的影片，可以是电影，可以是短片，是一连贯的视觉冲击力表现丰富的画面和音频。但从理性的角度来看，视频是一种有结构的数据，用工程的语言解释，我们可以把视频剖析成如下结构：
内容元素 ( Content )
图像 ( Image )
音频 ( Audio )
元信息 ( Metadata )
编码格式 ( Codec )
Video : H.264，H.265, …
Audio : AAC， HE-AAC, …
容器封装 (Container)
MP4，MOV，FLV，RM，RMVB，AVI，…
任何一个视频 Video 文件，从结构上讲，都是这样一种组成方式：
由图像和音频构成最基本的内容元素；
图像经过视频编码压缩格式处理（通常是 H.264）；
音频经过音频编码压缩格式处理（例如 AAC）；
注明相应的元信息（Metadata）；
最后经过一遍容器（Container）封装打包（例如 MP4），构成一个完整的视频文件。
如果觉得难以理解，可以想象成一瓶番茄酱。最外层的瓶子好比这个容器封装（Container），瓶子上注明的原材料和加工厂地等信息好比元信息（Metadata），瓶盖打开（解封装）后，番茄酱本身好比经过压缩处理过后的编码内容，番茄和调料加工成番茄酱的过程就好比编码（Codec），而原材料番茄和调料则好比最原本的内容元素（Content）。
http://www.toutiao.com/i6278412629417394689/
直播入门级
- 推流、直播 和 点播分别是什么意思？
推流
主播将本地视频源和音频源推送到云服务器，在有些场景中也被称为“RTMP发布”。
直播
即直接观看主播实时推送过来的音视频数据，观众和视频源之间的时间延迟一般不会太长。
点播
视频源已经事先存储于服务器之上的音视频文件，观众随时可以观看，类似优酷土豆、爱奇艺和腾讯视频。
影响视觉体验的直播性能指标
直播第一个性能指标是延迟，延迟是数据从信息源发送到目的地所需的时间。
一个完整的直播过程，包括但不限于以下环节：采集、处理、编码、封包、推流、传输、转码、分发、拉流、解码、播放。从推流到播放，再经过中间转发环节，延迟越低，则用户体验越好。
第二个直播性能指标卡顿，是指视频播放过程中出现画面滞帧，让人们明显感觉到“卡”。单位时间内的播放卡顿次数统计称之为卡顿率。
造成卡顿的因素有可能是推流端发送数据中断，也有可能是公网传输拥塞或网络抖动异常，也有可能是终端设备的解码性能太差。卡顿频次越少或没有，则说明用户体验越好。
第三个直播性能指标首屏耗时，指第一次点击播放后，肉眼看到画面所等待的时间。技术上指播放器解码第一帧渲染显示画面所花的耗时。通常说的 “秒开”，指点击播放后，一秒内即可看到播放画面。首屏打开越快，说明用户体验越好。
如上三个直播性能指标，分别对应一个低延迟、高清流畅、极速秒开 的用户体验诉求。了解这三个性能指标，对优化移动直播 APP 的用户体验至关重要。
移动直播场景其他优化措施
一、怎么优化打开速度，达到传说中的 “秒开”？
大家可能会看到，市面上某些手机直播 APP 的打开速度非常快，一点就开。而某些手机直播 APP，点击播放后要等好几秒以后才能播放。是什么原因导致如此的天壤之别呢？
大部分播放器都是拿到一个完成的 GOP 后才能解码播放，基于 FFmpeg 移植的播放器甚至需要等待音画时间戳同步后才能播放（如果一个直播里边没有音频只有视频相当于要等待音频超时后才能播放画面）。
“秒开”可以从以下几个方面考虑：
- 改写播放器逻辑让播放器拿到第一个关键帧后就给予显示。
GOP 的第一帧通常都是关键帧，由于加载的数据较少，可以达到 “首帧秒开”。
如果直播服务器支持 GOP 缓存，意味着播放器在和服务器建立连接后可立即拿到数据，从而省却跨地域和跨运营商的回源传输时间。
GOP体现了关键帧的周期，也就是两个关键帧之间的距离，即一个帧组的最大帧数。假设一个视频的恒定帧率是 24fps（即1秒24帧图像），关键帧周期为 2s，那么一个 GOP 就是 48 张图像。一般而言，每一秒视频至少需要使用一个关键帧。
增加关键帧个数可改善画质（GOP 通常为 FPS 的倍数），但是同时增加了带宽和网络负载。这意味着，客户端播放器下载一个 GOP，毕竟该 GOP 存在一定的数据体积，如果播放端网络不佳，有可能不是能够快速在秒级以内下载完该 GOP，进而影响观感体验。
如果不能更改播放器行为逻辑为首帧秒开，直播服务器也可以做一些取巧处理，比如从缓存 GOP 改成缓存双关键帧（减少图像数量），这样可以极大程度地减少播放器加载 GOP 要传输的内容体积。
- 在 APP 业务逻辑层面方面优化。
比如提前做好 DNS 解析（省却几十毫秒），和提前做好测速选线（择取最优线路）。经过这样的预处理后，在点击播放按钮时，将极大提高下载性能。
一方面，可以围绕传输层面做性能优化；另一方面，可以围绕客户播放行为做业务逻辑优化。两者可以有效的互为补充，作为秒开的优化空间。
- 常见的直播协议有哪些？
目前常见的直播协议有三种：RTMP、 FLV 和 HLS。
RTMP
RTMP协议比较全能，既可以用来推送又可以用来直播，其核心理念是将大块的视频帧和音频帧“剁碎”，然后以小数据包的形式在互联网上进行传输，而且支持加密，因此隐私性相对比较理想，但拆包组包的过程比较复杂，所以在海量并发时也容易出现一些不可预期的稳定性问题。
FLV
FLV协议由Adobe公司主推，格式极其简单，只是在大块的视频帧和音视频头部加入一些标记头信息，由于这种极致的简洁，在延迟表现和大规模并发方面都很成熟。唯一的不足就是在手机浏览器上的支持非常有限，但是用作手机端APP直播协议却异常合适。
HLS
苹果推出的解决方案，将视频分成5-10秒的视频小分片，然后用m3u8索引表进行管理，由于客户端下载到的视频都是5-10秒的完整数据，故视频的流畅性很好，但也同样引入了很大的延迟（HLS的一般延迟在10-30s左右）。相比于FLV， HLS在iPhone和大部分android手机浏览器上的支持非常给力，所以常用于QQ和微信朋友圈的URL分享。
- 常见的点播协议有哪些？
目前常见的点播格式有三种：MP4、HLS和FLV。
MP4
非常经典的文件格式，在移动终端和PC浏览器上的支持度都很好（在IOS和大部分Android设备上，都可以使用系统浏览器进行播放，在PC上可以使用FLASH控件进行播放）。但是MP4的视频文件格式比较复杂，所以处理成本高，而且由于索引表复杂度高，导致时长稍大（比如半小时）的MP4文件在线播放时加载速度会很慢。
HLS
苹果公司力推的标准，在移动终端的浏览器上的支持度较好，但IE的支持情况依赖FLASH的二次开发工作（建议使用腾讯视频云的FLASH播放器控件）。其精简的m3u8的索引结构可以规避MP4的索引慢问题，如果是用于点播，是非常不错的选择。
FLV
Adobe公司所推的标准，目前直播平台最常用的封装格式，在PC端有FLASH的强力支持，但在移动终端只有APP实现播放器才有可能支持（或者使用本播放器），大部分手机端浏览器均不支持。目前腾讯视频云的直播录制，采用的就是FLV视频格式。
- 常见的推流协议有哪些？
虽然RTMP在直播领域不是特别流行，但是在推流服务，也就是主播->服务器这个方向上，RTMP则居于主导地位，目前国内的视频云服务都是以RTMP为主要推流协议。
5.如何实现画质和流量的平衡？
影响画质的主要因素是三个：分辨率、帧率和码率。
分辨率：目前RTMP SDK支持的三种分辨率均为9:16的常规分辨率：360480，540960，720*1280。
帧率：FPS <=10 会明显感觉到卡顿，但也并不是越高越好，一般推荐是20FPS即可达到很流畅的效果。
码率：编码器每秒编出的数据大小，单位是kbps，比如800kbps代表编码器每秒产生800kb（或100KB）的数据。
好的画质是分辨率、帧率和码率三者之间的平衡：
码率不是越大越好
如果不做码率大小上的限制，那么分辨率越高，画质越细腻；帧率越高，视频也越流畅，但相应的码率也会很大，因为每秒钟需要用更多的数据来承载较高的清晰度和流畅度。
帧率不要超过24
如果限定一个码率，比如800kbps，那么帧率越高，编码器就必须加大对单帧画面的压缩比，也就是通过降低画质来承载足够多的帧数。如果视频源来自摄像头，24FPS已经是肉眼极限，所以一般20帧的FPS就已经可以达到很好的用户体验了。
有些玩过3D游戏的朋友可能会说，游戏的帧率越高越流畅。这里要注意一定不要混淆场景：游戏追求高帧率的目的是为了尽可能让3D模型渲染出来的运动效果更加接近真实运动轨迹，所以帧率越高越好。 但对摄像头而言，它要采集的目标是真实世界的物体，真实世界本来就没有刷新率的说法，所以这个理论不适用。
分辨率不盲目攀高
如果限定一个码率，比如800kbps，那么分辨率越高就会让编码器越 “为难" ，可以想象，它必须拆东墙补西墙，通过减少色彩信息或者引入马赛克这种“鱼目混珠”的手段来承载足够多的像素点。所以，同样的是2G的一个电影文件，1080p画质的版本可能不如720p画质的版本看起来更清晰。
如果您之前没有太多音视频编码的实战经验，我们比较建议您使用demo里的设置参数，我们在DEMO中提供了720p、540p 以及 360p 三种画质选择以及相应的配置。
- 如何降低延迟并减少画面卡顿？
这里说的延迟是主播 -> 观众的时间延迟，而卡顿指的是出现500ms以上的播放停滞。
如果是在完美的网络环境下，可以做到超低延迟下没有卡顿，但现实是国内的网络环境并不完美，数据在经过互联网传输时必然会有抖动和丢包，从而对播放端的流畅播放产生影响。
直播间列表
创建房间（增）
当一个主播开始直播前需要先创建一个直播间，这就等于是在直播间列表中增加一条新的数据。
关闭房间（删）
当一个直播结束后，App要通知后台把当前直播间状态修改为“直播结束”，或者干脆将其从列表中删除。
修改状态（改）
当有新的观众加入时，意味着某个直播间的观众数要+1；
当有观众给主播点赞，意味着某个直播间的点赞数要+1；
当有一条视频流意外断流时，会收到来自腾讯云的通知，意味着某个直播间的状态要进行修正；
当监管人员发现某一直播间内容涉及违规行为时，需要对其禁播，意味着某个直播间的状态要改为已禁播。
列表查询（查）
每一个打开App的观众，都会到直播后台查询一下当前的直播间列表，所以直播后台要提供列表拉取的相关接口供 App 使用。并且，如果您的App装机量不俗，那么这个接口要能承受一定的并发访问压力才行。
创建房间
终端 App 在发起直播前首先会通过一条协议向服务器请求创建一个直播间：
请求(App->Server)
最关键的信息就是自己的账号ID了，同时，最好再附上直播的标题、地理位置、直播封面URL等等信息，直播后台会用这些信息创建一个直播间。
响应(Server->App)
服务器的回包信息包含两种情况：一情况是允许直播，则可以把推流URL等信息返回给App；另一种情况是给予拒绝并返回错误原因。
