音视频实时是我们观赏视频的一个基本体验，特别是在对于视频画面中能看见声源动作（如：嘴型）的场景，音视频实时问题十分影响体验。在短视频与直播APP中，收集末端作为音视频的生产者，如果收集末端产生的音视频源本身就无法确保实时，那么后面不管经过什么处置，都很难再行让用户看见音视频实时的画面了，因此，在收集末端确保音视频实时上特别是在最重要。那么如何确保app在各种长时间/非正常状况下尽可能确保输入实时的音视频？本文就是描写我们是如何解决问题上述问题的。

音视频实时的原理音视频收集的数据分别来自于麦克风与摄像头，而摄像头与麦克风只不过是两个独立国家的硬件，而音视频实时的原理是坚信摄像头与麦克风收集数据是动态的，并在收集到数据时给他们一个时间砍来标明数据所属的时间，而编码PCB模块只要不改动音视频时间的比较关系就能确保音频与视频在时间上的对应。如此PCB好数据之后，播出末端就需要根据音视频的时间砍来播出对应的音视频，从构建音视频实时的效果。时间砍参照标准所取格林威治时间当作对比标准，即音视频时间砍都为收集时间点相对于格林威治标准时间的时间差；所取系统开机时间当作对比标准，即音视频时间砍都是收集时间点相对于手机开机时间的时间差。

目前iOS上AVCaptureSession这套API就是参照这个时间标准给的时间砍。其它时间砍标准基于“开源项目1”的音视频实时探究原生某开源框架如图：概述音/视频被收集到之后不会再行经过音/视频处置模块，音/视频在被处置之后才转入计算出来时间砍的模块。

在第一帧抵达时记一个计时起点，然后根据收集的帧间隔对接下来每一帧的时间砍展开计算出来：frameTimeStamp=lastFrameTimeStamp+frameDuration。优点能输入frameduration平稳的音视频时间砍。

风险无论是音频还是视频，在手机短路、性能严重不足等极端情况下有可能经常出现收集不稳定的情况，比如说预计1s收集30帧，实际只收集到28帧，而音视频的时间砍是通过相加来计算出来的，这样就有不会经常出现音视频不实时的情况。VideoProcess（人脸检测、滤镜、3D贴）有可能无法在一帧时间内处置完了当前帧，这样就不会经常出现帧数比预期较低的情况，从而经常出现音视频不实时。

帧间隔牵涉到到无限小数时，因为计算机的精度受限不会引起的时间砍位移，此位移不会随着帧数的减少而渐渐被缩放。基于开源项目1的改良方案1如图：时间砍的提供方法十分必要——每一帧都在改为帧转入时间砍计算出来模块时提供当前系统时间作为时间砍。优点APP性能长时间的情况下认同会经常出现音视频不实时；需要动态缺失时间砍，只要APP长时间运转，就能立刻完全恢复准确的时间砍。

风险倚赖VideoProcess与AudioProcess模块处置时长相似，而实际工程中因为人脸检测、贴等原因，VideoProcess可能会经常出现堵塞的情况，从而造成临时性的音视频不实时在AudioProcess与VideoProcess模块处置帧耗时不均匀分布的情况下不会经常出现音视频时间砍不均匀分布的问题，能否长时间播出依赖终端基于开源项目1的一个改良方案2如图：概述音/视频被收集到之后，再行提供收集模块获取的音视频时间砍，然后在音/视频处置模块透传收集模块提供到的音/视频时间砍，在时间砍计算出来模块之后透传收集模块给的时间砍。优点除非收集模块得出错误数据，否则音视频都一定是实时的。

风险可能会经常出现音视频时间砍不均匀分布的情况，特别是在是在手机短路、性能严重不足等极端情况下。直播方向更进一步的优化探究大体流程如图：概述音/视频被收集到之后，再行提供收集模块获取的音视频时间砍，然后在音/视频处置模块透传收集模块提供到的音/视频时间砍。在时间砍计算出来模块透传视频时间砍，并根据下文中提及的方法计算出来音频时间砍。音频时间砍计算方法动态计算出来时间砍：当前时间砍=接续时间砍+帧数*帧取样数/比特率；如果时间砍偏移量远超过阈值，缺失时间砍；缺失频率超过远超过阈值，必要透传收集时间砍。

优点需要获取一个平稳的音频时间砍，可以相容帧间隔小幅晃动导致的音频时间砍不均匀分布；兼容性能严重不足时造成实际收集帧数高于帧亲率。风险缺失时间砍时可能会导致声音卡顿的感觉。总结明确方案最差是针对实际应用于场景有选择性的做到优化，比如说，在可以掌控播放器策略的情况，可以考虑到根据自研播放器特性做到时间砍处置。而如果播放器不高效率，则尽可能通过策略确保帧间隔平稳。

本文来源：尊龙凯时-www.yuanfanglaichaye.com