0

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

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

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

我偶尔会从我的解压输出回调记录中得到一个错误是 OSStatus -12909– kVTVideoDecoderBadDataErr。到目前为止，如此无益。

或者我可能不会得到任何错误输出，例如在一个单元测试中，它接收固定的数据包并且应该始终生成视频帧。（在设备上使用 iOS14 时，此测试同样无法生成预期的帧。）

其他人对 iOS 14 中的 HEVC 解码有任何问题吗？我实际上是在这里寻找线索...我尝试为VTDecompressionSessionDecodeFrame()( ._EnableAsynchronousDecompression, ._EnableTemporalProcessing, ...)切换所有常用的输入标志

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



（如果有帮助，我在单元测试中放入的固定输入数据包按顺序包括以下类型的 NALU ：NAL_UNIT_VPS、NAL_UNIT_SPS、NAL_UNIT_PPS、NAL_UNIT_PREFIX_SEI、NAL_UNIT_CODED_SLICE_CRA最后NAL_UNIT_CODED_SLICE_TRAIL_N和NAL_UNIT_CODED_SLICE_TRAIL_R服务器作为基本的健全性测试。）

4

1 回答 1

0

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

该kVTVideoDecoderBadDataErr错误发生在所有类型的 NALU 数据包上，RASL_R或者RASL_N通常在第一个内容帧（CRA类型 NALU）之后立即从我的视频流中传入。

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

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

于 2021-02-10T10:52:47.367 回答