この投稿ではH.264、例として使用していますが、ソリューションを拡張して、などMPEG-4の他のコーデックをサポートすることができます。問題を解決するには 2 つの解決策が考えられます。以下にそれらを挙げます。それぞれに長所があります。情報に基づいた決定を下すのに役立ちます。VC-1VP8
解決策 1: コーデックを拡張して新しいモードをサポートする
では、同じタイプの同じコンポーネントを2 つの異なるコンポーネント名、つまり、およびとしてJellyBean登録できます。前者は通常の再生に使用され、より一般的に使用されるコンポーネントです。後者は、パーサーがセキュア コンテンツの存在を示す場合に使用されます。では、コーデックのリストが返された後、ここでコンポーネントを選択する選択を確認できます。OMXMIMEOMX.ABC.XYZOMX.ABC.XYZ.secureMediaExtractorOMXCodec::CreatefindMatchingCodecs.secure
手順:
プラットフォームで、別のコンポーネントを新しい拡張機能などで登録しますOMX.H264.DECODER.decrypt。のみ変更が必要ですmedia_codecs.xml。新しいファクトリ メソッドを登録するか、共通のファクトリ メソッドを使用するかは、ユーザーが選択できます。
パーサーから、特定のユース ケースに遭遇したら、 のような新しいフラグを設定しkKeyDecryptionRequiredます。このためには、 で新しいフラグを定義しMetadata.h、対応する quirk を で定義する必要がありますOMXCodec.h。
メソッドを変更して、上記のサフィックスと同様OMXCodec::createのサフィックスを追加します。.decrypt.secure
OMXCodec、Metadata、MediaExtractorモジュールのすべての変更によりlibstagefright.so、プラットフォームで同じものを再構築して置き換えるだけで済みます。
出来上がり!統合が完了するはずです。ここで、コンポーネント内の主な課題が発生します。コンポーネントの実装の一環として、通常のコンポーネントの作成とコンポーネントの作成を区別できる必要があり.decryptます。
.decryptランタイムの観点からは、コンポーネントがコンポーネントであるかどうかを認識していると仮定すると、呼び出しdecryptionの一部として を処理して、データを復号化し、それを基になるコーデックに渡すことができます。OMX_EmptyThisBuffer
長所:統合が容易、Android フレームワークの変更が最小限、他のコーデックに拡張可能、新しいMIMEタイプの登録が不要。
短所:.decrypt Android の将来のリビジョン、特に新しい癖、フラグ、および拡張機能の選択を追跡する必要があります。Google が同様のものを採用することを決定した場合、それに応じてソリューションを適応または変更する必要があります。
解決策 2: 新しい MIME タイプの登録
あなたの質問から、タイプを定義できたかどうかは明確ではないMIMEため、明確にするために手順をキャプチャしています。
手順:
ここに示すように、新しいMIMEタイプを に登録します。たとえば、新しいタイプを次のように使用できます。MediaDefsMIMEconst char *MEDIA_MIMETYPE_VIDEO_AVC_ENCRYPT = "video/avc-encrypt";
MIMEで、この更新されたタイプで新しいコンポーネントを登録しますmedia_codecs.xml。コンポーネントの癖もそれに応じて処理されるようにする必要があることに注意してください。
メソッドの実装では、ここに示すように、新しい型OMXCodec::setVideoOutputFormatを処理するためのサポートを導入する必要があります。新しいタイプをサポートするには、同様の変更を処理する必要があることに注意してください。MIMEH.264 OMXCodecMIME
では、新しく定義されたタイプを使用して、トラックのタイプMediaExtractorを通知する必要があります。これらの変更により、コンポーネントが選択されて作成されます。MIMEvideo
ただし、課題はまだ残っています。復号化を実行する場所は? このために、前のセクションで説明したのと同じソリューションを採用することもできます。つまり、OMX_EmptyThisBuffer呼び出しの一部として同じように処理します。
良い点:思いつかない..
短所:まず、ソリューションはスケーラブルではありません。MIME新しいタイプを追加し続け、Stagefrightフレームワークを変更し続ける必要があります。次に、 の変更にOMXCodec対応する の変更が必要になりますMediaExtractor。したがって、最初はMP4エクストラクタに焦点を合わせていても、ソリューションを 、 などの他のコンテナ形式に拡張したい場合はAVI、これらのエクストラクタMKVに新しい型のサポートを含める必要があります。MIME
最後に注意点をいくつか。
推奨される解決策として、簡単でシンプルな解決策 1 をお勧めします。
ACodecコーデックのベース実装については触れていません。ただし、将来そのようなサポートが必要になったとしても、ソリューション 1 の方がはるかに簡単に実装できると思います。
OMXコアを変更していない場合は、libstagefrighthw.so. 参考までに、これは通常、ベンダー固有のモジュールの一部としてベンダーによって実装されますvendor/<xyz>/hardware/...。のソースについては、プラットフォーム プロバイダーに確認する必要がありますlibstagefrighthw.so。