【音视频】常见问题整理 - 技术提升1.0

1. IDR帧与I帧区别？IDR帧比I帧多些什么信息
   

2. 音视频-音画不同步的策略

• 将视频同步到音频上：就是以音频的播放速度为基准来同步视频。
• 将音频同步到视频上：就是以视频的播放速度为基准来同步音频。
• 将视频和音频同步外部的时钟上：选择一个外部时钟为基准，视频和音频的播放速度都以该时钟为标准。

常见：

• 音频线性增长为参考，视频同步，及时反馈调整做同步。

3. 视频从录制 - 播放

（以下不太记得是从哪里看到的一些问题以及回答了！）

4. 视频卡顿和延时这方面除了NACK，FEC之外还有其他什么方式吗刘连响：

• 其实卡顿不止有NACK与FEC，举个简单的例子，我们遇到在WebRTC中判断码率比较低从而降低帧率，如果降帧率比较激进那么就会造成卡顿，实际上此时完全可以通过一些参数上的调优来改善。我们认为WebRTC中的一些算法过于激进，在一些特殊情况下会将帧率一下降低到几帧，就会使得画面出现卡顿。除此之外，还有SVC和带宽探测等技术都可以进行调优。
• 而在播放端我们更多是针对缓存进行调优，也就是用延迟来换取更加流畅的视频播放体验。不一定只限于NACK或FEC之上。NACK已经足够优秀而FEC则有利有弊，如果FEC没有用好则会造成带宽的占用，反而让情况更糟糕。

5. 音视频-VoIP技术面临的困难和挑战

• VoIP技术是基于当前这样复杂IP网络环境中，同样面临很多挑战。在电路交换中，因为资源是独占的，虽然贵但是质量可以得到保证。但是基于VoIP的解决方案是分组网络，不是独占资源，就会面临很多网络架构上的挑战，以及来自声学方面的挑战。
• 1）丢包挑战
  1. 网络架构上的第一挑战是丢包，因为不是独有，而且整个UDP协议也不保证整个包一定送达目的地。
• 2）延时挑战
  1. 第二个挑战是延时。整个IP网络存在很多交换机、存在各种中间交换节点，在各交换节点会产生延时。
• 3）Jitter
  1. 第三个挑战是分组交换独有的一个概念：Jitter。就是对于延时的变化，虽然从发送的时间上来看，第一个包发出的时间比第二个包要早，但是到达目的地却可能是第二个包先到，导致就算收到第二个包，但是没有收到第一个包，语音也不能放出来。
• 4）回声问题
  1. VoIP电话相对于PSTN电话，会面临延时带来的挑战，导致我们在Echo的处理上也和传统大为不同。
  2. 传统电话很多时候不用考虑Echo，因为本地电话基本延时都能控制在50毫秒以内，人眼是分辨不出来到底是回声还是自己的讲话声音。但是互联网上因为Delay增大，甚至可能超过150毫秒，所以必须要把回声问题很好地解决，否则人耳听起来会感觉非常不舒服。
• 5）带宽问题
  1. 另外整个网络的带宽，也跟通话质量息息相关。如果容量不够，对于VoIP通话路数和质量也会有很大的影响。

6. 大型直播，比如赛事比赛，发布会等直播，主要是用hls、flv等，5G时代是否可以用WebRTC技术呢？

• 两个场景不一样，直播的时候可能会跳动，或者VOD播放的时候如果延时比较大也没有关系，延时超过200毫秒，500毫秒，甚至1秒都没事，直播虽然晚一秒也不妨碍观看和体验。但是实时语音通信就不可以，超过300毫秒，甚至打电话1秒之后才回过来这肯定不行。我不觉得它们会用RTC技术，它们还是会用RTMP推流，或者HLS切包发送这样的技术，因为虽然会带来延时，但是在网络抖动处理，包括其他很多方面都能处理得更好。所以适用的场景不一样，未来做不同技术的考虑点也会不一样。

7. 线上常见声音问题

• 1）无声问题
  1. 首先是无声问题，例如通过VoIP客户端或者通过电话入会过程当中就能碰到无声问题，像驱动异常，硬件设备异常，无麦克风权限，设备初始化，电话打断等也能造成无声问题。
• 2）漏回声
  1. 在实时语音过程当中还会出现漏回声的问题，在传统的PSTN电话系统中基本不存在回声，因为延时比较低，而且大部分电话都是话筒模式，很少使用外放。但是使用VoIP客户端，比如说PC和手机终端，越来越多的人喜欢使用外放，而不需要把耳机放在耳朵，这样就容易产生回声问题。
• 3）声音嘈杂
  1. 同样还有声音嘈杂的问题，比如在移动场景，室外，或者是办公室里办公，大家使用VoIP客户端会经常听到办公室里的敲键盘声音、水杯喝水的声音，这些嘈杂声在以前使用普通电话话筒模式下并不明显。
• 4）音量小，飘忽不定
  1. 还会有音量小，音量飘忽不定的情况出现，这也是跟使用的外设和使用的场景相关。像基于PC、Mac或者移动设备的系统播放回调过高，系统CPU载入过高，手持麦克风姿势不对，音乐语音判断错误，还有网络Jitter导致加减速，这些情况都会导致会议语音过程中碰到各种各样的问题，而在以前的通话里面基本上没有这些问题。
• 5）声音浑浊，可懂度差
  1. 还有声音浑浊，可懂度差的问题，现在的实时通话场景比以前复杂的多，假如是在重混响的场景下，或者采集设备很差的环境下面通话，就容易导致声音的音质比较差。
• 6）音频卡顿
  1. 还有像声音卡顿的问题，这个是所有使用VoIP通话过程当中大家都容易经历到的。声音卡顿大家第一时间会想到是和网络相关，但是实际解决问题的过程当中，我们发现有很多的原因都有可能导致音频卡顿。网络虽然占了很大一块，但不是所有的原因。
  2. 比如在信源质量差的时候进行声音信号处理的过程中会出现卡顿，因为一些很小的语音会被当成噪声消掉。同样，CPU过载，播放线程同步失效也会导致卡段，处理回声采集播放不同步的时候，导致漏回声的现象也会出现卡顿。所以在会议过程当中，会有来自很多方面的原因，导致最后的音质受损。

8. 音频对比答疑

• 如何获取时间戳完全对准的yuv文件？
  1. 采集与编码-解码后的数据，帧数完全一致
  2. 格式：AVC？可转换成yuv文件
• 只能做上行-推流端的网络损失情况？
  1. 一个源文件（参照对象），通过SDK层的录制，进行不同网络下的对比流
  2. 原因：不能做下行的是因为获取接收端的流是经过损失的，与源流没有对比性。
• 播放端的延时自动获取？
  1. 原理：将时间戳打在关键帧/每一帧里，接收端进行解码解出时间戳，进行差值
  2. SCDN可用原因：秒/s级别的，RTC都是毫秒/ms级别的无法区分

9. 概念梳理答疑

• FEC：补帧策略，网络丢包的补偿策略。如果是延时导致的丢包，补偿延时会更大。提供3数据包的算法不一样。根据1，2帧，补偿一个3包，客户端会根据1，3，将2帧恢复出来。
• SEI：计算延时的（webrtc底层有方法回调）会打印每一帧的延时，看网络延时。有两个手机的世界时间校准。
• Nack：丢包重传（webrtc底层自带的功能）30ms当没有帧进行编码了，客户端会请求一个关键帧
• GCC：拥塞算法
• 帧对齐/帧校准：使用场景，在切换分辨率的时候（比如大小流切换）会做一次帧对齐。
• 变模糊，一定是码率不够，编码效率低。
• 华为手机是绿边，三星是码率太高，编不过来。
• 卡顿率计算：就是将卡顿的次数除以时间。
• 丢包率计算：webrtc底层有方法回调，根据丢包率去自适应码率，只有降到最低码率才会考虑去丢包。媒体层返回的包的情况去计算丢包率。
• Jitter：缓存buffer，比如收到了1，2，100序号的包，会等待前面3，4，5…的包回来去还原这个帧