5

カスタムの「ラッパー」ビデオ コーデックを開発し、Android に統合する必要があります (現在は JB、後で ICS)。SIM からいくつかのカスタム復号化キーを使用したいと考えています (聞かないでください!)。最善の方法 (暗号化されていない他のメディアと一緒に動作し、標準のメディア プレーヤーなどを使用できるようにする) は、独自の MIME タイプを定義し、それをカスタム ラッパー コーデックにリンクすることです。復号化してから、データを実際のコーデックに渡します。(ファイルタイプは今のところだとしましょう.mp4。)

(別の方法として、独自のメディア プレーヤーを作成することもできますが、メディアを他のメディアと一緒にシームレスに表示したいので、その方法は避けたいと考えています)

私はこのガイドに従おうとしてきました: デコーダーをマルチメディア フレームワークに統合する方法

  1. OMX Core の登録に問題があります - libstagefright.soAndroid ソースから入力してビルドできますmake stagefrightが、ガイドではlibstagefrighthw.soJB に適していると思われる を使用するように指示されていますが、これをビルドする方法がわかりません。make stagefright私が何か間違ったことをしていない限り、使用から構築されているようですか?

  2. もう 1 つの問題は、カスタム ラッパー コーデックを登録したとしても、実際のコーデックにデータを渡す方法がわからないことです。

誰か提案があれば(または赤ちゃんに段階的な指示を与えることができます!)、本当に感謝します-概念実証の締め切りは非常に厳しく、コーデックやメディアフレームワークについてはほとんど知りません...

どうもありがとう。(ps drm やアナログ ホールなどについての泥棒争いにはなりたくありません.., ありがとう)

4

1 に答える 1

9

この投稿ではH.264、例として使用していますが、ソリューションを拡張して、などMPEG-4の他のコーデックをサポートすることができます。問題を解決するには 2 つの解決策が考えられます。以下にそれらを挙げます。それぞれに長所があります。情報に基づいた決定を下すのに役立ちます。VC-1VP8

解決策 1: コーデックを拡張して新しいモードをサポートする

では、同じタイプの同じコンポーネントを2 つの異なるコンポーネント名、つまり、およびとしてJellyBean登録できます。前者は通常の再生に使用され、より一般的に使用されるコンポーネントです。後者は、パーサーがセキュア コンテンツの存在を示す場合に使用されます。では、コーデックのリストが返された後、ここでコンポーネントを選択する選択を確認できます。OMXMIMEOMX.ABC.XYZOMX.ABC.XYZ.secureMediaExtractorOMXCodec::CreatefindMatchingCodecs.secure

手順:

  1. プラットフォームで、別のコンポーネントを新しい拡張機能などで登録しますOMX.H264.DECODER.decrypt。のみ変更が必要ですmedia_codecs.xml。新しいファクトリ メソッドを登録するか、共通のファクトリ メソッドを使用するかは、ユーザーが選択できます。

  2. パーサーから、特定のユース ケースに遭遇したら、 のような新しいフラグを設定しkKeyDecryptionRequiredます。このためには、 で新しいフラグを定義しMetadata.h、対応する quirk を で定義する必要がありますOMXCodec.h

  3. メソッドを変更して、上記のサフィックスと同様OMXCodec::createのサフィックスを追加します。.decrypt.secure

  4. OMXCodecMetadataMediaExtractorモジュールのすべての変更によりlibstagefright.so、プラットフォームで同じものを再構築して置き換えるだけで済みます。

出来上がり!統合が完了するはずです。ここで、コンポーネント内の主な課題が発生します。コンポーネントの実装の一環として、通常のコンポーネントの作成とコンポーネントの作成を区別できる必要があり.decryptます。

.decryptランタイムの観点からは、コンポーネントがコンポーネントであるかどうかを認識していると仮定すると、呼び出しdecryptionの一部として を処理して、データを復号化し、それを基になるコーデックに渡すことができます。OMX_EmptyThisBuffer

長所:統合が容易、Android フレームワークの変更が最小限、他のコーデックに拡張可能、新しいMIMEタイプの登録が不要。

短所:.decrypt Android の将来のリビジョン、特に新しい癖、フラグ、および拡張機能の選択を追跡する必要があります。Google が同様のものを採用することを決定した場合、それに応じてソリューションを適応または変更する必要があります。

解決策 2: 新しい MIME タイプの登録

あなたの質問から、タイプを定義できたかどうかは明確ではないMIMEため、明確にするために手順をキャプチャしています。

手順:

  1. ここに示すように、新しいMIMEタイプを に登録します。たとえば、新しいタイプを次のように使用できます。MediaDefsMIMEconst char *MEDIA_MIMETYPE_VIDEO_AVC_ENCRYPT = "video/avc-encrypt";

  2. MIMEで、この更新されたタイプで新しいコンポーネントを登録しますmedia_codecs.xml。コンポーネントの癖もそれに応じて処理されるようにする必要があることに注意してください。

  3. メソッドの実装では、ここに示すように、新しい型OMXCodec::setVideoOutputFormatを処理するためのサポートを導入する必要があります。新しいタイプをサポートするには、同様の変更を処理する必要があることに注意してください。MIMEH.264 OMXCodecMIME

  4. では、新しく定義されたタイプを使用して、トラックのタイプMediaExtractorを通知する必要があります。これらの変更により、コンポーネントが選択されて作成されます。MIMEvideo

ただし、課題はまだ残っています。復号化を実行する場所は? このために、前のセクションで説明したのと同じソリューションを採用することもできます。つまり、OMX_EmptyThisBuffer呼び出しの一部として同じように処理します。

良い点:思いつかない..

短所:まず、ソリューションはスケーラブルではありません。MIME新しいタイプを追加し続け、Stagefrightフレームワークを変更し続ける必要があります。次に、 の変更にOMXCodec対応する の変更が必要になりますMediaExtractor。したがって、最初はMP4エクストラクタに焦点を合わせていても、ソリューションを 、 などの他のコンテナ形式に拡張したい場合はAVI、これらのエクストラクタMKVに新しい型のサポートを含める必要があります。MIME

最後に注意点をいくつか。

  1. 推奨される解決策として、簡単でシンプルな解決策 1 をお勧めします。

  2. ACodecコーデックのベース実装については触れていません。ただし、将来そのようなサポートが必要になったとしても、ソリューション 1 の方がはるかに簡単に実装できると思います。

  3. OMXコアを変更していない場合は、libstagefrighthw.so. 参考までに、これは通常、ベンダー固有のモジュールの一部としてベンダーによって実装されますvendor/<xyz>/hardware/...。のソースについては、プラットフォーム プロバイダーに確認する必要がありますlibstagefrighthw.so

于 2013-04-23T00:32:55.630 に答える