因此，虽然我确定我不会为任何人提供足够的信息来修复我的特定代码，但我想知道的是:
有人知道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,NAL_UNIT_PREFIX_SEI,NAL_UNIT_CODED_SLICE_CRA，最后是NAL_UNIT_CODED_SLICE_TRAIL_N和NAL_UNIT_CODED_SLICE_TRAIL_R。)在过去的某个时候，我从一个工作的网络流中获取了这些数据，作为一个基本的完整性测试。
所以今天早上我遇到了一个解决方案/变通方法。它仍然带有最初的问题"发生了什么?"但在这里，它可能会帮助别人:
kVTVideoDecoderBadDataErr错误发生在类型为RASL_R或RASL_N的所有NALU数据包上，这些数据包通常在第一个内容帧(CRA类型NALU.)之后立即从我的视频流进入
简单地跳过这些数据包(即不将它们传递给VTDecompressionSessionDecodeFrame())已经为我解决了这个问题，我的解码器现在在iOS 13和14中都可以正常工作。
关于"随机访问支持"的部分;这里说"RASL框架是…通常被丢弃的!"我想知道iOS 13和早期的VideoToolbox实现是否丢弃了这些帧，而较新的实现没有，在这种情况下留给开发人员?