问题描述
我观察到，对于相同价格范围内的设备，基于 Snapdragon 的解码器的解码延迟比基于 Exynos 的解码器高得多。这在 SPS 中将值“pic_order_cnt_type”设置为 0 而不是 2 的 h264 流解码时最为明显。 我想知道您是否也观察到了这种行为，是否有任何解决方法（我已经打开了一个问题 here，但目前没有任何回应）
一些技术细节：
我构建了一个简单的示例应用程序，它使用 AMediaCodec 来解码 h264 流。它将“解码延迟”作为测试结果上传到 Firestore 数据库中。 code
以下是 Pixel 4（使用骁龙解码器）和三星 galaxy Note 9（使用 exynos 解码器）上不同 h264 流的解码延迟比较：
| Pixel 4 | galaxy Note 9 |
|---|---|
|
|
如您所见，对于名为 jetson/h264/2/test.h264 的视频，在骁龙设备上的解码时间是三星设备的约 21 倍。此流的 pic_order_cnt_type==0。然而，在其他流上，解码时间的差异是微不足道的。 （他们都使用 pic_order_cnt_type==2）
决定snapdragon解码器是否进入“低延迟解码路径”的主要参数似乎就是上面提到的pic_order_cnt_type这个值。 如果我正确理解 h264 规范，如果将此值设置为 2 图片重新排序是不可能的（没有缓冲帧）。如果设置为 0，则图像重新排序是可能的，但编码器不一定使用。但是，骁龙解码器没有区分“可能”和“编码器实际使用”，导致解码延迟差异很大。
我能够在将比特流发送到解码器之前通过操纵比特流来减少它的解码延迟（添加 VUI，num_reorder_frames=0 和 max_dec_frame_buffering=0），但它永远不会产生 0 个缓冲帧，只有更少的缓冲帧。
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）