What are the advantages of using gstreamer over stagefright? Could anyone please point out the difference.
2 に答える
最初に、非常に一般的なコメントが 1 つあります。GStreamerが有利かどうかは非常に議論の余地がありStagefrightます。ただし、あなたの質問に答えるいくつかのポイントは以下のとおりです。
StagefrightはすべてのコーデックでOMX/インターフェイスのみに依存しますが、コーデック プラグインはインターフェイスを介して記述できます。たとえば、ソフトウェア コーデックでさえフレームワークにカプセル化されますが、同じものは必ずしもインターフェイスを持たなくても簡単に に変換できます。OpenMaxGStreamernon-OMXSoftOMXComponentStagefrightGstElementOMX
ではStagefright、2 つのコンポーネント間の通信インターフェイスは非常に汎用的で、通常はMediaBufferです。これはバインディングではありませんが、接着層、つまりまたはまたはの実装hardによってより容易になります。OMXCodecMediaExtractorAwesomePlayer
ではGStreamer、一般的な通信インターフェイスは、Pads特定の を持つを介したものGstCapsです。2 つのコンポーネントのパッドは、 を介して相互にリンクされていgst_pad_linkます。
GStreamerまたはbinsのような標準テンプレートを提供しますが、 の実装があります。プレーヤーの場合、またはのような 2 つの潜在的なプレーヤー エンジンの実装があります。CameraBinPlayerBinStagefrightcameraHalcameraStagefrightPlayerNuPlayer
では、データ処理は からの(ダウンストリームの) PULLデータStagefrightによって駆動されます。では、データ処理は、バッファを作成し、それを下流にPUSHすることによってトリガーされる可能性があります(参照:ここ)。sinksourceGStreamersource
最後のポイントは、現在 Android 固有のものGstreamerと比較して、広く展開されていることです。Stagefright
リストは続きますが、2 つのフレームワークには多くの類似点があります。例えば、
どちらのフレームワークも、パターンを使用するなどして、
parsersまたはパターンcodecsを介してコンポーネントを作成します。Factory MethodsFactory両方のフレームワークは、
pluginたとえば などの新しいコンポーネントを統合するためのインターフェイスを採用していますparsers。
私は StageFright には詳しくありませんが、GStreamer は非常に成熟したデバッグ機能を提供していることを指摘したいと思います。これには、GraphViz (「ドット」) データのダンプが含まれます。これは、構築中を含め、比喩的な再生グラフのリテラルで視覚的なグラフを構築するために使用できます。 、特定の種類の部分的な障害の後でも。特定の種類のフィルタリングとともに、複数のデバッグ レベルを使用できます。
開発目的でこれら 2 つのライブラリのいずれかを選択する場合は、特にパイプラインの枯渇と同期のトラブルシューティングに関して、デバッグ機能とトラブルシューティング機能を比較することを強くお勧めします。
(ちなみに、これらのドット ダンプを変換するのに最適な形式は SVG です。通常は Firefox で開きます。)