4

AudioContext.createMediaStreamDestination() のデフォルトはモノラル出力のようです。このデフォルトは変更されていますが、必要な出力チャネルの数を手動で設定する方法はありますか?

または、正しい量のチャネルを維持しながら、WebAudio から WebRTC にストリームを取得する他の方法はありますか?

4

1 に答える 1

7

現在、これを行うのはかなり難しいようです。いくつかの調査の後、ドキュメントには、より多くのチャネルを設定できると記載されていることがわかりました。電話をかけたにもかかわらずcontext.createMediaStreamDestination(2)、反対側でモノラル ストリームを受信します。この議論によると、複数のストリームを追加できるようです。これを試してみると、ローカル (ストリーマー) とリモート (レシーバー) の両方がpc.getLocalStreams()、pc.getRemoteStreams()それぞれ呼び出し時に正しいストリームを表示しているように見えます。したがって、チャンネル スプリッターを使用して、入力を 2 つのモノラル出力に分割し、一緒にストリーミングすることができます。

悲しいことに、webRTC と webAudio はまだ開発中であるため、受信したストリームを web Audio API を介してパイプすることはまだできません (context.createMediaStreamSource(<RTCStream>)これはマイク ストリームに対してのみ機能します)。受信したストリームを 2 つの個別の Audio 要素に追加すると、オーディオが同期されるかどうかをまだテストしています。

小さなアップデート

複数のトラックをストリームに追加してからそのストリームを送信するいくつかのテストの後、受信側の<audio>タグは両方のトラックを再生し、実際にそれらを追加しました。左のチャンネルを含むトラックが両方のスピーカーで再生され、右のチャンネルも同様です。 . そのため、レシーバー側で分割することはまだできていませんが、少なくとも左右のオーディオを 2 つの異なるチャンネルで送信することはできました。そうです、開発者が Web オーディオ API を介して受信したオーディオをパイプする機会を私たちに与える時が来ました。

別のアップデート

によって自動的に作成されたストリームstreamDestinationNodeは、ステレオ ストリームのようです。ここでその例を見つけることができます(フィールドに音楽を追加することを忘れないでくださいsrc)。
この動作は、現在受信したストリームを再生する方法 (そこから objectURL を作成し、それを要素の srcに割り当てる) とは関係ありません。 これは、RTC ストリーミング システム自体に関連していることを意味します。上記のコードを でテストした後、チャネルを混合しているだけのようです。<audio>
RTCPeerConnection

コーデックの使用

そこで、別のコーデックである Opus を使用することを検討しました。そのコーデックに変更するコードをいくつか見つけ、ステレオを使用するようにコーデックを設定する方法を探しました。thisとthisを見つけましたが、使い方がわかりません。それに加えて、Opus に変更しても自動的にステレオに変更されることはありません (コーデックが自動的に変更されるように設定されている場合は可能でした)。

Opus 用の sdp を作成するためのドラフトを見つけました。調査中です。

編集：見つけました

rtp opus draftの 3 番目のバージョンで見つけました。これは例にあり、非常に簡単です。行に追加stereo=1; sprop-stereo=1すると、a=fmtp完了です。このドキュメントには、次のプロパティの仕様も含まれています。

ステレオ: デコーダーがステレオまたはモノラル信号の受信を優先するかどうかを指定します。可能な値は 1 と 0 で、1 はステレオ信号が優先されることを指定し、0 はモノラル信号のみが優先されることを指定します。ステレオ パラメータとは無関係に、すべての受信機はステレオ信号を受信して​​デコードできる必要がありますが、モノラル信号の優先度を通知した受信機にステレオ信号を送信すると、ネットワークの使用率が必要以上に高くなり、エンコードが複雑になる可能性があります。値が指定されていない場合は、モノと見なされます (stereo=0)。

sprop-stereo: 送信者がステレオ オーディオを生成する可能性があるかどうかを指定します。可能な値は 1 と 0 で、1 はステレオ信号が送信される可能性が高いことを指定し、0 は送信者がモノラル信号のみを送信する可能性が高いことを指定します。これは、送信者がステレオ オーディオを送信しないという保証ではありませんが (たとえば、ステレオを使用する事前に録音されたプロンプトを送信できます)、受信した信号を安全にモノラルにダウンミックスできることを受信者に示します。このパラメーターは、オーディオ処理パイプライン (エコー キャンセレーションなど) を必要のないときにステレオで操作することにより、受信機のリソースを浪費しないようにするのに役立ちます。値が指定されていない場合、モノラルが想定されます (sprop-stereo=0)。

これがお役に立てば幸いです。これは高品質のオーディオのためのものだと思いますので、そのドキュメントを読んで、高品質のオーディオ ストリーミングの詳細を確認することをお勧めします。

欠点

友人とこれをテストした後、エンコーディング側 (オーディオを送信する側) が chrome 34 でノイズを生成するようです。私は chrome 36 (dev と canary) を使用していますが、このエラーは発生しません。(chrome 34 から 36 にストリーミングするとノイズが発生しますが、36 から 34 にストリーミングするとノイズが発生しないため、エンコード側の問題です)。

（なぜ私はそのような精巧な答えを書くのですか？私も自分自身を知りたいです:D）。

于 2014-04-26T19:54:00.897 に答える