音视频技术知识集锦
注意：部分内容的收集来源于博客，文章的摘抄，尊重原创；
1 关于音视频同步常用的方式
视频向音频同步，音频向视频同步，音视频向系统时钟同步
常用的是音视频向系统时钟，或视频向音频同步；
原因：
2 关于播放器卡顿问题
2.1弱网环境数据没有及时（由服务端）发给客户端；播放持续的卡顿，当带宽高一些，或者同步占用链路少一些时候就会改善；播放时候经常loading，读不到数据，加载中；
2.2 大码率，大分辨率，视频解码性能不够，导致无法及时渲染，甚至如果音视频是串行在一个队列里发送给解码器的时候，可能会阻塞音频，一顿一顿的；（打印下关键帧解码耗时）
2.3 持续的掉帧，画面粘滞（没有及时把后边的帧渲染出来，看着跟卡顿很像）；暂停后依然卡顿；但是有些三方播放器是正常的；送数据间隔也正常；解码耗时0毫秒~1毫秒；要看看显卡，CPU占用率了；换个显卡试试；
2.4 逻辑原因导致的音视频不同步，相同的时间音频帧走的数量和视频帧走的数量不一样，音画不同步；画面走的很慢；解码后缓冲（渲染用缓冲）存够了，很多视频都开始被逻辑代码丢弃了
2.5 在视频开始的时候加载缓慢，跳转时候也很慢才能出新位置的视频；可能是发流的服务器的问题，wireshark抓包看一下；也可能是播放器本身的逻辑需要缓冲N帧才能送解析、解码
注意：帧率、CPU/GPU 占用率、音画不同步、缓冲区、起播时长、卡顿率、卡顿时长等
3 关于点播协议HLS和RTSP
最常见的点播都是HLS协议，即M3U8搭配TS分片；http-live-stream，由苹果公司提出的协议；
3.1 HLS优点：
封装简单，PES包加一层TS封装（十几个~几十个字节）；服务端接收点播请求解析TS文件迅速，录像生成TS文件打包迅速；客户端显示（加载）快；
3.2 HLS缺点：
（3.1.1）一般会限制当M3U8中有3个及以上分片，时候才能开始播放，这就造成了一定的播放延迟；（直播时候）HLS 直播流最大的延时就来自于切片生成本身的延时；
（3.1.2）HLS是TS封装的PES包，一包188字节【帧里的一部分数据】，一般网络发送时候是188字节整数倍；每一个完整的TS文件都有若干个GOP（当然也可以有一个GOP，但是文件个数就会很多），由于TS封装没有关键帧索引，所以没办法做特别精准的点播；必须传输完整TS文件（包含多个GOP）；
3.2 RTSP点播MP4（解析MP4打包成RTP-ES使用RTSP发送）
MP4有MOOV和I帧位置记录，可以较快的进行精准定位；但是由于前、后置索引，导致生成文件，或者点播解析的时候会慢于TS封装解析；
4 关于HLS起播策略优化
可以不必缓冲3个TS切片在播放，只要缓冲足够，当本切片播放完，恰好下一个切片的续上来就行；
关于TS点播（尤其是一个切片多个GOP）无法精准定位的问题，可以采取缩小片段长度的方式，当然相应的文件个数就会很多；（如果 seek 到某个 ts 切片的中间位置，会需要从这个 ts 切片的开始位置下载数据并解码，再计算 seek 到的位置来展示画面，这样的 seek 过程会比较慢，就会导致起播较慢）；另外就是服务端在seek到文件中间时候，把这个帧位置前边的数据快速发送给播放端，让他快速解码然后扔掉（可以根据时间戳判断是否到了要定位的那一帧【大概率是P帧】），直到解码到定位的那个帧，再正常送显示队列（音视频同步），送数据的服务端，要控制自己的时钟进度，比如将时钟跳到定位帧的时间点，这样按时间进度读数据的话，定位帧前边的数据就会被快速地刷给服务端（目的是为了解码/不花屏）
5 关于RTSP倍速传输
RTSP回放流，倍速传输，下载过程中；常见的方法
（1）修改帧间隔时间戳；已达到全量音视频，倍速输出；（2） 高倍速只传输I帧，修改待发送关键帧时间戳or 修改播放器时钟滴答的进度
（3）服务端按照原本的数据（不修改帧时间戳）的N倍速发送给服务端，服务端同步调整时钟倍速（物理时间每1毫秒，实际代码逻辑时钟进度1*N毫秒）；
（4）数据下载；以经验值的最大速度（16倍、32倍，64倍的解析时钟，来解析录像文件），可以配合传输中的socket非阻塞式的可写状态，来决定数据是否发送给客户端（以及是否暂停服务端数据的解析发送）；
6 关于推拉流中的带宽消耗的优化
服务端转码；不是必须要转码的（转码浪费服务器CPU和内存）
服务端或者流媒体服务器做转码的好处在于压缩转码能够节省码率，比如原本1080P 2M的原始流，做其他格式的压缩编码（ROI区域压缩，动态码率），输出可以达到100KB左右；大大的节省了传输带宽
7 如何解决上传下载过程中的过度资源消耗（与第六点的观点正好相反）
一般的上传下载业务；只是双方看到的内容相同，但实际用户上传的和观众下载的可能不是同样的编码格式、封装格式；（用到转码，转封装，转协议）；节省流量；适应不同的客户端协议交互；
一人上传，N人观看（不是同时的观看），如果都做转码，是不是服务器的压力会比较大；
方案：
用户上传上去，先转码成不同编码格式、码率的文件【高清，标清等】；以供不同客户端拉流点播。并且节省了每一个用户实时转码（编解码）的CPU和GPU的压力；不同用户过来拉流的时候，只需要满足负载均衡的socket链接和转协议即可；由于用户不可能同一时间观看，所以每个客户端都是一个单独的socket转封装；
如果每个用户上传的文件（尤其是音视频）都转码成不同等级的视频，可能存储消耗就是几倍的，随着时间的推移，存储量堆积如山；有些人更愿意仅仅原视频存储，用户观看过程中转码；
但是同一时间一个平台几亿人次在不同起点看不同视频，都转码，服务器也吃不消，所以对于一些业务上没什么人喜欢看的视频，用户观看时候就直接转封装即可，按原始编码输出（此时浪费点带宽就没关系了，互联网社区的流量和带宽是巨大的）
另外就是分布式部署媒体服务器，将转码压力分摊到每一个服务器上；对于热度比较高的视频，事先转码，用户看的时候转封装即可，热度退下来或者过时的时候，可以仅保存原视频，随看随转码（转封装）；
如果就想每个视频观看时候随看随转码：可采用分级转码（配合硬件加速转码）。服务端的转码分为多个档次，我们可以根据视频的播放量热度来渐进开启不同档次的转码，热度低的转码一路基础档位即可，热度上来了再增加转码一档高清的；
8 关于实时流秒开和点播秒开
实时流秒开，以ZLM为例，每种转出协议，都设置一个缓冲，这个缓冲缓存最近的一个GOP，有新的I帧来了删除旧的GOP，这样不管客户端用什么协议来连接，都先刷出用于秒开的GOP（一个链接上来刷一次就好），然后每一帧实时过来的数据在继续送给客户端。
对于点播，本身每一个点播就都要从文件头开始，所以肯定是秒开的，当用户点播观看要跳转的时候，是用最好使用RTSP+MP4点播，精准定位（一般是seek到P帧）到P帧所在GOP，快速送【前向】GOP或者从该GOP的I帧直接播放；
在点播场景中，虽然文件的第一个帧肯定是I帧，但是点播链路，服务器文件解析可能会花一定的时间，秒开不仅考量I帧发送，还有第一个可播放的画面的发送速度；如果解析录像文件比较耗时，那即便送过关键帧，也要等解析完成之后，所以一般的方案是用户上传媒体文件，我们提取一下首帧画面为JPEG（与文件一起保存），当观众从客户端操作点播时候，服务端优先将JPEG发送给客户端，实现快速的秒开，同时服务器异步解析点播文件，解封装；（有可能解封装异步也要一会，导致客户端第一个画面会卡在那一会，但是首屏已经显示了所以卡一下就卡一下吧）
9 消息队列作用，假如消息队列满了，又有新的消息来了，你怎么保证这个新消息能被正常处理？
（来源于关键帧Keyframe）
队列满重试； 扩充任务队列 ； 新消息进行队列头插入（要考虑是否与之前的任务有关系，如果有上下文关系就不能头插入）
浙公网安备 33010602011771号
