VideoToolbox HEVC 解码在设备上的 iOS14 失败

问题描述

因此，虽然我确定我不会为任何人提供足够的信息来修复我的特定代码，但我很想知道的是：

有谁知道 iOS14 可能发生了什么改变 HEVC 解码要求？

---

我有一个使用 VideoToolbox 构建的解码器，用于通过网络传输 HEVC 编码的视频流，它在 iOS 13 设备、和 iOS 14 模拟器上运行良好。但它在 iOS 设备上的 iOS 14（在撰写本文时高达 14.4）中大部分时间都失败了。 “大部分时间”，因为有时它确实有效，这取决于我尝试开始解码的流中的哪个位置。

我偶尔从解压输出回调记录中得到的错误是 OSStatus -12909 – kVTVideoDecoderBadDataErr。到目前为止，太没有帮助了。

或者我可能没有错误输出，就像在单元测试中一样，它接收固定的数据包并且应该总是生成视频帧。 （在设备上使用 iOS14 时，此测试同样无法生成预期的帧。）

还有其他人对 iOS 14 中的 HEVC 解码有任何问题吗？我真的是在这里寻找线索......我已经尝试切换 VTDecompressionSessionDecodeFrame() (._EnableAsynchronousDecompression,._EnableTemporalProcessing,...)

的所有常用输入标志

我还尝试重做整个渲染层，以将 AVSampleBufferDisplayLayer 与原始 CMSampleBuffers 一起使用。完美解码！！但是我不能使用它...因为我需要自己对输出帧的时间进行微观管理（而且它们并不总是按顺序排列）。

（如果有帮助，我放入单元测试的固定输入数据包按顺序包含以下类型的 NALU：NAL_UNIT_VPS、NAL_UNIT_SPS、NAL_UNIT_PPS、{{1 }}、NAL_UNIT_PREFIX_SEI，最后是 NAL_UNIT_CODED_SLICE_CRA 和 NAL_UNIT_CODED_SLICE_TRAIL_N。我在过去的某个时候将这些从工作网络流中获取到服务器作为基本的健全性测试。）

解决方法

所以今天早上我遇到了一个解决方案/解决方法。它仍然带有最初的问题“发生了什么？？”但在这里，它可以帮助某人：

kVTVideoDecoderBadDataErr 错误发生在 RASL_R 或 RASL_N 类型的所有 NALU 数据包上，这些数据包通常在第一个内容帧 (CRA输入 NALU。）

简单地跳过这些数据包（即不将它们传递给 VTDecompressionSessionDecodeFrame()）已经为我解决了这个问题，我的解码器现在可以在 iOS 13 和 14 中正常工作。

---

“随机访问支持”部分 here 说“RASL 帧......通常会被丢弃。”我想知道 iOS 13 和更早的 VideoToolbox 实现是否丢弃了这些帧，而较新的实现没有，在这种情况下由开发人员决定？