6

ネットワーク経由でオーディオをストリーミングするために gstreamer を使用しています。私の目標は一見単純に見えます: 着信ストリームを特定の時間/バイトしきい値までプリバッファリングしてから、再生を開始します。gstreamer の非常に単純な機能を見落としている可能性がありますが、これまでのところ、それを行う方法を見つけることができませんでした。

私の（簡略化された）パイプラインは次のようになりますudpsrc -> alsasink。これまでのところ、私の目標を達成するためのすべての試みは、その間にキュー要素を使用してきました:

  1. 間に queue 要素を追加します。
  2. プロパティを使用しmin-threshold-timeます。これは実際には機能しますが、問題は、すべての着信データが最初だけではなく、指定された最小時間をキューで費やすことです。これは私が望んでいるものではありません。
  3. 前の問題を回避するために、オーディオ シンクにデータが初めて入ったときにキューにコードを通知させようとしました。これは、先ほど設定した min-time プロパティの設定を解除するときだと考えて、 「プリバッファリング」動作。

これは、私が試したコードとほぼ同等です。

def remove_thresh(pad, info, queue):
    pad.remove_data_probe(probe_id)
    queue.set_property("min-threshold-time", 0)

queue.set_property("min-threshold-time", delay)
queue.set_property("max-size-time", delay * 2)
probe_id = audiosink.get_pad("sink").add_data_probe(remove_thresh, queue)

これは、次の 2 つの理由で機能しません。

  1. 私のコールバックは、delay私が提供した変数よりもずっと早く呼び出されます。
  2. 呼び出されると、キューに格納されていたすべてのデータが失われます。キューがまったく存在しないかのように再生が開始されます。

私は、このことがどのように機能するかについて根本的な誤解をしていると思います。誰かが私が間違っていることを知っていますか、または代わりに、これを行うための(おそらく)より良い方法を提供できますか? ここでは python を使用していますが、任意の言語での任意のソリューションを歓迎します。

ありがとう。

4

2 に答える 2

3

バッファリングは GStreamer で既に実装されています。キューなどの一部の要素は、このバッファーを構築し、バッファー レベル (キューの状態) に関するバス メッセージを送信できます。

ネットワークの回復力を高めたいアプリケーションは、これらのメッセージをリッスンし、バッファ レベルが十分に高くない場合 (通常は 100% 未満の場合) は再生を一時停止する必要があります。

したがって、キューがバッファリングしている間、パイプラインをPAUSED状態に設定するだけです。あなたのケースでは、一度だけバッファリングしたいので、これには任意のロジックを使用してください（最初だけパイプラインを一時停止するようにフラグ変数を設定するかもしれません）。

  1. キューの「max-size-bytes」プロパティを必要な値に設定します。
  2. 「オーバーラン」シグナルをリッスンしてバッファがいっぱいになったときに通知するか、 gst_message_parse_buffering () を使用してバッファリング レベルを見つけます。
  3. バッファーがいっぱいになったら、パイプラインをPLAYING状態に設定し、それ以降のすべてのバッファー メッセージを無視します。

最後に、完全なストリーミングの例については、次のチュートリアルを参照してください 。

于 2013-04-22T04:35:27.173 に答える