0

これはばかげた質問かもしれません。gstreamer要素はプロセスでどのように複数回ロードされますか？Gstreamer要素が作成されると、すでに作成されてメモリに存在する場合、それらは共有されますか？私の場合、1つのプロセスで複数のスレッドが作成されます。スレッドごとに次のgstreamer要素を作成し、パイプラインをリンクしてPLAYING状態、filesrc->Q->filesinkに設定します。これは機能します。しかし、Q-> filesinkの間にgstreamer要素（gstバッファーデータを処理するために新しく作成されたもの）を追加すると、すべてのスレッドが機能しなくなります。何が問題になる可能性がありますか？どうすればデバッグできますか？入力を提供してください。前もって感謝します。-opensid

4

2 に答える 2

1

要素は共有ライブラリ内にあるため、コードはメモリ内に1回だけ存在します。ただし、各インスタンスは、それ自体の状態のためにいくらかのメモリを占有します。マルチスレッド処理を行う場合は、メインスレッドからgst_init（）を1回だけ呼び出す必要があります。gstreamerはすでにデータ処理用の新しいスレッドを作成しているため、1つのメインスレッドからすべてのgstreamerパイプラインを作成する方が節約できます。複数のパイプラインを並行して実行できます。

于 2013-01-25T21:01:53.457 に答える
0

klassに保存されているデータに適用されるため、ensonicの回答に同意します。ただし、gbufferには適用されないようです。basetransformに基づくIEEE1278オーディオ変換のバージョンを調べています。1つのバージョンには、設定可能なプロパティに基づいてUDPパケットを通過させるフィルタープラグインと、パッドの設定に応じて双方向変換用のプラグインIEEE1278<->mulawがあります。

簡単なテストのために、私はループを試しました：

  • gst-launch-1.0 -v filesrc location = IsaacAsimov-Foundation1Of8_64kb.mp3 \
  • ！mpegaudioparse \
  • ！mpg123audiodec
  • ！'audio / x-raw、rate = 8000、channels = 1'\
  • ！audioresample \
  • ！'audio / x-raw、rate = 8000、channels = 1'\
  • ！mulawenc \
  • ！'audio / x-mulaw、rate = 8000、channels = 1'\
  • ！dissignalaudio \
  • ！ディスフィルター\
  • ！dissignalaudio \
  • ！'audio / x-mulaw、rate = 8000、channels = 1'\
  • ！mulawdec \
  • ！'audio / x-raw、rate = 8000、channels = 1'\
  • ！自動オーディオシンク

dissignalausio_transformのgbufferデータまたはメタデータに何をしたとしても、出力オーディオには多くの強いクリックノイズがありました。mulawdecのgprintは、私の変換の変更がmulawdecに到達していないことを示しました。UDPループバックを使用してループを2つの起動パイプラインに分割すると、ノイズがなくなりました。どういうわけか、dissignalaudioの最初のインスタンスからのgbufferが2番目のインスタンスをオーバーライドしていました。

学んだ教訓：

双方向変換の例がなく、すべての変換に個別のエンコードプラグインとデコードプラグインがあるのには理由があります。

于 2017-09-02T18:36:05.457 に答える