公式の方法は、開始コード プレフィックスを存在させることです (これは、1 つのパケットに複数の NAL ユニットを含めるために必要です)。これは、すべての OpenMAX IL (MediaCodec の下で内部的に使用される標準) デコーダーが期待するものです (他の形式をサポートするものもある場合でも)。 )。SPS/PPS を別のバッファに (BUFFER_FLAG_CODEC_CONFIG
フラグを設定して) 入れるか、VCL NAL ユニットをバッファの先頭に追加するかは問題ではありません。デコーダは両方を処理できるはずです。ただし、デバイスが実際に何をするかから暗黙のうちに推測する以外に、Android についてこれを明確にする個々のドキュメントは見つからないと思います。
どのデバイス (およびどのプラットフォーム バージョン) がこれらのビットストリーム バリアントのどの組み合わせを出力し、どの組み合わせがどのデバイスで失敗するかを教えてください。私の知る限り、スタートコードが存在するストリームはどこでも機能するはずですが、もちろん例外があるかもしれません。Android 4.3 以降、これらは 4.1 および 4.2 よりもはるかに適切に動作するはずです。
一部のベンダーは、MediaExtractor で非標準的なことを行っているようです。これに関するバグ レポートをhttps://code.google.com/p/android/issues/detail?id=74356に書きました。その場合、Samsung 固有の標準外の動作はisDMCMMExtractor=1
、MediaFormat のキーで通知されます。MediaExtractor をより厳密に指定する必要があることに本当に同意します。現在、ほとんどの場合、データを MediaCodec にフィードするためにしか使用できないためです (少なくともベンダー固有の HW コーデックについては理解されていると想定されています)。 、アプリが MediaExtractor 出力で何か他のことをしたい場合 (たとえば、サードパーティのバンドルされたデコーダーでデコードするか、ネットワーク経由で抽出されたデータを送信するなど)。
一部のデバイスが事実上の標準のビットストリーム形式のデコードに失敗した場合 (ただし、プラットフォームの MediaExtractor が行う方法でマングルされた場合にのみ成功します)、生のハードコードされたパケットのデコードをテストすることによって、別の CTS 互換性テストが保証されているようです (したがって、その MediaExtractor は間に入って物事を変換することはできません)。EncodeDecodeTest ( http://bigflake.com/mediacodec/を参照) などの CTS テストは、このデバイスで正しく動作しますか? その場合でも、標準のパケット形式のデコードに失敗した場合は、デバイスのエンコーダーも非標準のものを出力することを意味します。