音视频面试题集锦第 41 期

来自音视频社群“关键帧Keyframe”的分享。最近一位社群的朋友参加了多场音视频方向的面试，遇到了这些面试题，这里给大家分享一下：

1、知道 av1 吗？

2、vp8 和 vp9，谷歌为什么要弄这两个编码出来？应用场景是什么？

3、你在优化播放器时是如何判断卡顿原因来自哪的？硬件问题或网络问题怎么判断？(这里面试官应该想考察我分析问题的能力，但是没答好)

4、hls 直播流会有卡顿或延迟吗？hls 延迟来自哪里？hls 起播优化？

5、用户上传文件时涉及转码，每天都有巨量用户文件被上传到服务端，服务端做转码就需要消耗巨量硬件资源，你有什么好的解决方案？(这里我答了先在客户端转码再上传)。客户端每次启动都要先向服务端拉配置，可能拉配置需要消耗巨大流量，怎么解决？(这里答了本地缓冲，面试官说有更好的方案)

6、你说可以在服务端提前探测提高播放器秒开率，但是服务端探测也需要时间，你怎么保证第一个用户点击这个视频时的秒开率？服务端取数据的时机是什么？(这里我答了用回调函数异步处理)

7、消息队列作用，假如消息队列满了，又有新的消息来了，你怎么保证这个新消息能被正常处理？(答了再创建一个工作线程)消息队列能不能同时多个消费者取消息处理，又能保证顺序不乱？(答了加锁和条件变量，但是面试官想要的是多消费者并行处理的方案)

1、知道 av1 吗？

面试官主要就是考察一下知识面，回答这题的思路也很简单：简要介绍 AV1 – 分析 AV1 的优点和挑战

AV1（AOMedia Video 1）是一种开放、免版税的视频编码格式，旨在用于视频传输和存储。它由开放媒体联盟（Alliance for Open Media, AOM）开发，这是一个由 Google、Mozilla、Cisco、Amazon、Intel、Microsoft、Netflix 等多家公司组成的联盟。AV1 旨在取代 VP9 并成为与 HEVC（H.265）竞争的主要视频编码标准。

AV1 的优点：

• 高效压缩：AV1 旨在比现有的视频编码标准（如 H.264/AVC 和 HEVC/H.265）提供更高的数据压缩率，这意味着在相同的视频质量下，AV1 编码的视频文件将占用更少的存储空间和带宽。
• 开源免费：与某些其他视频编码标准（如 HEVC）不同，AV1 是完全开放且免版税的，这使得它对于开发人员和内容创作者来说是一个吸引人的选择，因为它消除了版权费用的负担。
• 广泛兼容：AV1 旨在支持从低端移动设备到高端生产和播放设备的广泛兼容性。随着技术的发展和采纳，越来越多的浏览器、操作系统和硬件开始原生支持 AV1。
• 适用于多种应用：从在线视频流媒体（如 YouTube 和 Netflix）到视频会议和实时广播，AV1 的设计目标是满足各种视频应用的需求。

AV1 的挑战：

• 编码效率：虽然 AV1 提供了优于先前视频编码标准的压缩效率，但在早期，它的编码过程比较耗时和计算密集，这可能是对于实时编码和低延迟应用的一个挑战。
• 硬件支持：尽管软件支持正在迅速增长，但对 AV1 编解码的硬件支持仍然相对有限。随着更多的芯片和设备开始内置 AV1 支持，这一点正在逐渐改善。
• 过渡期：任何新的技术标准的推广都需要时间。虽然 AV1 具有显著的技术优势和行业支持，但从现有的编码标准向 AV1 过渡仍然需要时间和资源。

2、vp8 和 vp9，谷歌为什么要弄这两个编码标准出来？应用场景是什么？

谷歌开发 VP8 和 VP9 视频编码标准的主要动机是打破专利壁垒、推动开源免费的视频压缩技术，并满足互联网时代对高效视频传输的需求。其中 VP8 侧重实时性与兼容性，VP9 则面向更高压缩需求场景。随着 AV1 的普及，VP9 可能逐步向 AV1 过渡。

YouTube 广泛采用 VP9 来节省服务器和带宽资源。VP8 是 WebRTC 的默认编解码器。

• 实时视频会议：如 Zoom、Google Meet 早期版本依赖 VP8 实现低延迟通信。
• 超高清流媒体：YouTube 4K/8K 视频采用 VP9，压缩效率比 VP8 提升 30% 以上。
• 多路视频传输：企业级视频会议中，VP9 的 SVC 特性允许单流多层级编码，适配不同终端带宽。

3、你在优化播放器时是如何判断卡顿原因来自哪的？硬件问题或网络问题怎么判断？

硬件问题引起的卡顿通常是由于解码性能跟不上导致，对应典型特征：

• 持续帧率不稳：画面持续掉帧，即使暂停后恢复播放仍卡顿。
• 高 CPU/GPU 占用：设备发热严重，任务管理器显示播放器进程占用资源过高（如 CPU > 80%）。
• 仅高分辨率卡顿：播放低分辨率视频流畅，但切换到 4K 或 HDR 时卡顿。
• 音频不同步：音画不同步（硬件解码失败时常见）。

网络问题引起播放卡顿的通常是由于缓冲区数据不足导致，对应的典型特征：

• 缓冲频繁：播放时频繁出现加载中状态，也就是缓冲区频繁数据不足需要等待网络数据加载。
• 初始加载缓慢：点击播放后需要长时间等待才能开始播放。
• 卡顿规律性：卡顿集中在视频开始或中途跳转时，且卡顿后可能恢复正常。

要准确判断原因则需要通过数据埋点来监控与上述特征对应的指标，比如：帧率、CPU/GPU 占用率、音画不同步、缓冲区、起播时长、卡顿率、卡顿时长等。

4、hls 直播流会有卡顿或延迟吗？hls 延迟来自哪里？hls 起播优化？

HLS 直播流可能会有卡顿，并且大概率会有延迟。HLS 的延迟是因为它的直播流需要在服务端处理为一系列连续的小切片文件（通常为 ts 格式），并生成一个索引文件对这些切片文件进行索引，我们通常需要为这个切片指定一个最小时长（比如 3s、5s 等），生成完一个切片文件才能被客户端拉取，这就带来了延迟，所以除了网络传输延时外，HLS 直播流最大的延时就来自于切片生成本身的延时。

HLS 的起播优化可以考虑：

1）优化起播策略

对于播放 HLS 时，起播速度跟播放器的策略有很大的关系。比如 iOS 的 AVPlayer 可能需要下载 3 个 ts 切片才会开始播放。要优化起播速度，则不必等待下载太多切片才起播，比如可以使用水位线策略下载到一定量的数据就开始播放流程，这样相对起播会更快一些。

2）优化起播 seek

由于播放 HLS 通常是拉取对应时间点的 ts 切片，这里就可能会遇到播放器拉取到时机正好映射到某个 ts 切片的中间，这时候就需要把这个 ts 切片下载下来，然后 seek 到对应的时间点再解码渲染播放，一般 HLS 的 ts 切片是按照直播的 GOP 来切片的，如果 seek 到某个 ts 切片的中间位置，会需要从这个 ts 切片的开始位置下载数据并解码，再计算 seek 到的位置来展示画面，这样的 seek 过程会比较慢，就会导致起播较慢。这里可以用一些策略：比如非精准播放，不一定非要精准 seek 到拉取到时间点，而是从对应的一个 ts 切片的头部开始起播；比如降低 ts 切片长度，来降低加载时长、解码 seek 时长。

5、用户上传文件时涉及转码，每天都有巨量用户文件被上传到服务端，服务端做转码就需要消耗巨量硬件资源，你有什么好的解决方案？客户端每次启动都要先向服务端拉配置，可能拉配置需要消耗巨大流量，怎么解决？

这里有两个问题：

• 1）优化服务端转码消耗。
• 2）优化客户端拉取服务端配置的消耗。

遇到这种问题，一般你都可以先把思路推到极致，然后再往回收。

我们先说第一个问题：优化服务端转码消耗。

思路推到极致就是：服务端不转码不就没有消耗了嘛！但是有的视频不能不转码，所以思路往回收：有一部分视频不用转码。那接下来的问题就是：哪些视频不需要转码呢？我这里列出一些：

• 视频格式满足一定条件，且播放量低于一定阈值的视频不用转码。比如一些粉丝量很低的号，他们的视频没几个人看，没必要转码。但是要有个底线，就是视频格式满足一定条件，不能因为没转码导致客户端播不出来。或者在客户端上传时就做好转码容错控制。
• 重复上传的视频不用转码。一个大的视频平台上，有不少的搬运工，他们上传的视频其实服务端视频库里已经有了，这时候就不需要再转码了，甚至上传都不需要走，直接服务端 copy 一下记录就好了。
• 分级转码。服务端的转码通常不止一路，可能分为多个档次，同样的，我们可以根据视频的播放量热度来渐进开启不同档次的转码，热度低的转码一路基础档位即可，热度上来了再增加转码一档高清的。

总之，就是配合分发和播放数据反馈来减少不必要的转码。你还可以想想其他的案例。

第二个问题：优化客户端拉取服务端配置的消耗。

同样的，思路推到极致：能不能不拉配置？不能不拉的时候，能不能少拉。我这里给几点思路：

• 客户端本地缓冲配置，并且配置设置版本号，拉取配置前先查版本号，客户端缓存的版本是最新的就不用拉了。
• 必须要拉配置的时候，只拉取客户端缓存配置与服务端最新配置的 diff 量。就像 git 一样。这样也能降低消耗。

你可以继续发散。

6、在服务端提前探测提高播放器秒开率，但是服务端探测也需要时间，你怎么保证第一个用户点击这个视频时的秒开率？服务端取数据的时机是什么？

对任何视频要完全保证第一个用户点击视频的秒开率其实并不划算，一般不会这么做。单从技术方案上可以考虑如下：

• 1、首帧优先处理 + 渐进式加载
  • 首帧快速提取与缓存：视频上传后，服务端立即提取首帧画面（耗时极短，通常<100ms），存储为独立文件（如JPEG或低分辨率关键帧）。用户首次请求时，优先返回首帧，同时后台异步处理完整视频（转码、分片等），实现“伪秒开”。
  • 渐进式传输协议：使用 MPEG-DASH 或 HLS 的“低延迟模式”，将视频拆分为极小块（如 1 秒分片），首块优先传输。服务端边处理边传输，用户端收到首块即可播放，后续分片通过 HTTP 长连接持续推送。
• 2、实时处理加速
  • 边缘节点实时转码：在 CDN 边缘节点部署轻量级转码器（如 FFmpeg + GPU 加速），首个用户请求触发就近节点实时转码，减少回源延迟。甚至可以仅转码首片段（如前 5 秒），后续分片异步处理。
  • 硬件加速与并行化：使用 GPU/TPU 加速首帧提取和转码（如 NVIDIA NVENC 编码器），将首帧处理时间压缩至 50ms 内。并行处理音频轨与视频轨，优先输出音频（用户对音频延迟更敏感）。
• 3、动态预热与预测
  • 热度预测模型：基于上传者历史、内容标签、上传时段等特征，预测新视频成为热门的概率。对高热度概率视频提前全量转码并预热至CDN，牺牲部分资源换取首用户秒开。

7、消息队列作用，假如消息队列满了，又有新的消息来了，你怎么保证这个新消息能被正常处理？消息队列能不能同时多个消费者取消息处理，又能保证顺序不乱？

问题一：消息队列已满时，如何保证新消息正常处理？

• 1、生产者端策略
  • 阻塞与重试机制：生产者在发送消息时设置超时和重试策略（如指数退避）。比如生产者可配置在队列满时阻塞并等待缓冲区释放。
  • 降级与异步存储：若队列持续满载，可将消息临时写入本地磁盘或数据库，待队列空闲后异步重放。例如，使用本地 SQLite 暂存消息，并通过定时任务重新投递。
  • 死信队列（DLQ）兜底：配置死信队列接收无法处理的消息，避免数据丢失。
• 2、队列容量动态扩展
  • 自动扩缩容：基于监控指标（如队列深度、CPU 负载）自动扩容队列资源。
  • 多级队列分流：将消息按优先级拆分到不同队列（高/中/低优先级），优先保证核心业务消息处理。
• 3、消费者端优化
  • 批量消费加速处理：消费者批量拉取消息，减少网络开销，提升处理效率。
  • 横向扩展消费者：增加消费者实例数量，通过负载均衡分摊压力。

问题二：能否用多个消费者并发消费且保证顺序？

• 1、顺序性保障的核心逻辑
  • 分区顺序性（Partition Ordering）：在分区队列中，单个分区内的消息顺序严格保证，但不同分区的消息可能乱序。生产者控制：将需保序的消息发送到同一分区（如按用户 ID 哈希选择分区）。消费者单线程处理：每个分区仅由一个消费者线程处理，避免并发冲突。
  • 全局顺序性（Global Ordering）：若需全局严格有序（如金融交易），则只能使用单分区单消费者，牺牲并行性换顺序性。
• 2、并发消费与顺序性平衡
  • 消息分组（Message Grouping）：同一组的消息由同一消费者处理。例如，订单 ID 作为分组 Key，相同订单的消息串行处理。
  • 本地队列缓冲：消费者将消息按 Key 存入本地内存队列，每个 Key 对应一个线程处理。

总结：

• 队列满载应对：通过生产者阻塞重试、降级存储、队列扩容组合解决，优先保障核心消息不丢失。
• 顺序与并发平衡：利用分区、消息分组等技术实现局部有序，避免全局锁竞争。
• 关键设计原则：
  • 分层兜底：本地缓存→死信队列→自动扩容逐级降级。
  • 业务适配：根据场景选择顺序性强度（如用户级有序 vs 全局有序）。

音视频方向学习、求职，欢迎加入我们的星球

丰富的音视频知识、面试题、技术方案干货分享，还可以进行面试辅导