直播软件开发编解码
硬编解码
通过硬件实现编解码，减轻CPU计算的负担，如GPU等
软编解码
如 H264、H265、MPEG-4等编解码算法，更消耗CPU
数据优化
数据优化和编解码算法息息相关，一般而言
视频帧大小
一般I 帧的压缩率是7，P 帧是20，B 帧可以达到50 (数据不精确)
P帧大概是3~4KB (480P, 1200k码率, baseline profile)
音频帧大小
(采样频率（Hz） 采样位数（bit） 声道数)/ 8
48000hz大概经过AAC压缩后，应该是12KB/s左右
流媒体传输协议
直播软件开发常用的流媒体协议主要有 HTTP 渐进下载和基于 RTSP/RTP 的实时流媒体协议，这二种基本是完全不同的东西
CDN直播中常用的流媒体协议包括RTMP，HLS，HTTP FLV
RTP，RTCP
实时传输协议（Real-time Transport Protocol），RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在UDP协议上的。
实时传输控制协议（Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP）是实时传输协议的一个姐妹协议。RTCP为RTP媒体流提供信道外控制。RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量提供反馈。
RTP.png
RTSP+RTP经常用于IPTV领域。因为其采用UDP传输视音频，支持组播，效率较高。但其缺点是网络不好的情况下可能会丢包，影响视频观看质量。
小结
TCP_UDP_RTCP.png
RTMP
RTMP(Real Time Messaging Protocol)实时消息传送协议是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输 开发的开放协议。
它有三种变种：
工作在TCP之上的明文协议，使用端口1935；
RTMPT封装在HTTP请求之中，可穿越防火墙；
RTMPS类似RTMPT，但使用的是HTTPS连接；
总结： RTMP协议基于TCP来实现，每个时刻的数据，收到后立刻转发，一般延迟在1-3s左右
HLS
HTTP Live Streaming（HLS）是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议，可实现流媒体的直播和点播。HLS点播，基本上就是常见的分段HTTP点播，不同在于，它的分段非常小。基本原理就是将视频或流切分成小片（TS）， 并建立索引（M3U8）.
相对于直播软件开发中常见的流媒体直播协议，例如RTMP协议、RTSP协议、MMS协议等，HLS直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。由此可见，基本上可以认为，HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。
总结： HLS协议基于HTTP短连接来实现，集合一段时间数据，生成ts切片文件，然后更新m3u8(HTTP Live Streaming直播的索引文件)，一般延迟会大于10s
HTTP-FLV
HTTP-FLV基于HTTP长连接，通RTMP一样，每个时刻的数据，收到后立刻转发，只不过使用的是HTTP协议，一般延迟在1-3s
CDN
CDN架构设计比较复杂。不同的CDN厂商，也在对其架构进行不断的优化，所以架构不能统一而论。这里只是对一些基本的架构进行简单的剖析。
CDN主要包含：源站、缓存服务器、智能DNS、客户端等几个主要组成部分。
源站：是指发布内容的原始站点。添加、删除和更改网站的文件，都是在源站上进行的；另外缓存服务器所抓取的对象也全部来自于源站。对于直播来说，源站为主播客户端。
缓存服务器：是直接提供给用户访问的站点资源，由一台或数台服务器组成；当用户发起访问时，他的访问请求被智能DNS定位到离他较近的缓存服务器。如果用户所请求的内容刚好在缓存里面，则直接把内容返还给用户；如果访问所需的内容没有被缓存，则缓存服务器向邻近的缓存服务器或直接向源站抓取内容，然后再返还给用户。
智能DNS：是整个CDN技术的核心，它主要根据用户的来源，以及当前缓存服务器的负载情况等，将其访问请求指向离用户比较近且负载较小的缓存服务器。通过智能DNS解析，让用户访问同服务商下、负载较小的服务器，可以消除网络访问慢的问题，达到加速作用。
客户端：即发起访问的普通用户。对于直播来说，就是观众客户端。
弱网优化
弱网优化的策略包括如下：
播放器Buffer
丢帧策略 (优先丢P帧，其次I帧，最后音频)
自适应码率算法
双向链路优化
音频FEC冗余算法(20%丢包率）
丢帧
在弱网情况下，为了达到更好的体验，可能会采取丢帧的策略，但是丢帧，怎么丢呢？丢音频帧还是视频帧呢 ？ 因为视频帧比较大，并且视频帧前后是有关联的；音频帧很小，关键是音频帧是连续采样的，丢了音频帧，那声音就会明显出现瑕疵。为此，一般的丢帧策略是丢视频帧
自适应码率
在弱网情况下，另外一种靠谱的策略是自适应码率算法，通过设置码率降级为多个档次，这样，当网络不好的情况下，通过降低码率进行预测，如果码率降低后，还不够buffer缓冲，那么继续降低一个档次，是一个循环探测的过程，如果再次降级一个档次后，发现buffer缓冲足够了，那么说明当前网络能够适应这个码率，因此就会采取当前码率。同理，升档也是一样的。但是这个属于厂商的核心算法，
实时聊天的挑战
简单估算一下大概的网络延时。众所周知，光在真空中的速度约为300,000km/s，而在其他介质中光 速会大大降低，所以在普通光纤中，工程上一般认为传输速度是200,000km/s。从现实上来说，可以参考如下：
距离光纤延迟.png
距离往返延迟.png
实时聊天的挑战主要在于以下几点:
实时性: 600ms以内
网络的不对称性
距离
常见问题和解决方案
出现花屏、绿屏问题
采集问题、编解码问题、声网传输丢帧问题
声画不同步
采集问题，或者公有云SDK问题
画面有时候有点糊
弱网，码率的自适应
有声音没有画面
弱网，触发了丢帧策略
画面播放有时候卡顿
CPU消耗过高导致卡顿，比如AR模块
弱网
网络连接不上
弱网
或者代码有Bug，或者公有云SDK有Bug
出现马赛克现象？
是否类似花屏 ？
