問題タブ [qualcomm]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
android - h264 を使用した Exynos デバイスと比較して、Snapdragon デバイスのデコード レイテンシが高い
私は、同じ価格帯のデバイスの場合、Snapdragon ベースのデコーダーは Exynos ベースのデコーダーよりもはるかに長いデコード レイテンシを持つ可能性があることを観察しました。これは、SPS 内の値「pic_order_cnt_type」を 2 ではなく 0 に設定して h264 ストリームをデコードする場合に最も顕著です。この動作を確認したかどうか、およびその修正方法があるかどうか (私は既に問題をここで開いています)しかし、今のところ反応なし）
いくつかの技術的な詳細:
AMediaCodec を使用して h264 ストリームをデコードする簡単なサンプル アプリを作成しました。テスト結果として、「デコード レイテンシ」を Firestore データベースにアップロードします。コード
これは、Pixel 4 (snapdragon デコーダーを使用) と Samsung Galaxy Note 9 (exynos デコーダーを使用) でのさまざまな h264 ストリームのデコード レイテンシの比較です。
| ピクセル 4 | ギャラクシーノート9 |
|---|---|
 |
 |
ご覧のとおり、jetson/h264/2/test.h264 というビデオの場合、snapdragon デバイスでのデコード時間は、Samsung デバイスのデコード時間の約 21 倍です。このストリームでは pic_order_cnt_type==0。ただし、他のストリームでは、デコード時間の違いは重要ではありません。(それらはすべて pic_order_cnt_type==2 を使用します)
Snapdragon デコーダーが「低遅延デコード パス」に入るかどうかを決定する主なパラメーターは、上記の値 pic_order_cnt_type のようです。h264 の仕様を正しく理解している場合、この値が 2 に設定されている場合、画像の並べ替えは不可能です (バッファリングされたフレームはありません)。0 に設定すると、ピクチャの並べ替えが可能になりますが、エンコーダによって必ずしも使用されるわけではありません。ただし、snapdragon デコーダーは、「可能」と「実際にエンコーダーによって使用される」を区別しないため、デコード レイテンシに大きな違いが生じます。
デコーダーに送信する前にビットストリームを操作する (num_reorder_frames=0 および max_dec_frame_buffering=0 で VUI を追加する) ことで、Snapdragon のデコード レイテンシを減らすことができましたが、バッファリングされたフレームが 0 になることはなく、バッファリングされたフレームが少なくなります。