問題タブ [rtcp]

ビデオ ストリームの送受信をできる限り遅延させないようにしています。送信には、Linux で gstreamer を使用します。

このパイプラインはビデオをポート 2000 に送信し、ポート 2001 と 2005 を使用して「魔法の」rtcp 同期を行います。

Linuxでgstreamerをレシーバーとして使用すると、うまく機能します。400 ミリ秒未満の遅延が発生します。

ただし、Windowsでの受信時に同じパフォーマンスを得るのに苦労しています。私は何を試しましたか：

• VLC。rtcp をまったくサポートしていないようです。
• Windows 用の gstreamer。ビデオの代わりに大きな遅延やスライドショーを生成するなど、奇妙な動作をしているようです。rtcp が機能していないようです。
• ffmpeg。rtcp ポートを開きますが、何にも影響しません。-nobuffer オプションでの遅延は約 1000 ミリ秒です。

オプションは残っていますか？あらゆる種類のライブラリまたは SDK?

WebRTC と単純な p2p チャットの実装に関するチュートリアル全体に従いました。私のシグナリング サーバーは、localhost:9090 で別の場所で動作しています。メッセージを送信しようとすると、次のメッセージが表示されます。

ただし、接続は適切に確立されているようです。

client.js のコードは次のとおりです。

各クライアントが実際に他のクライアントに接続されていること、および回答/SDP が正しいことを確認するにはどうすればよいですか? このためのヒント: チャネルの作成が早すぎて、「握手」全体の後にのみ行う必要があるのではないでしょうか? どうもありがとう

__ジブの最初の答えの後編集__

次のように、live555 を使用して、RTSP over TCP を使用してオンデマンド RTSP サーバーから H264 ビデオをストリーミングしています。

RTT が 30 ミリ秒未満の場合にうまく機能します。ただし、Linux の tcp コマンドを使用して RTT を 100 ミリ秒に増やすとtc、半分の品質のビデオしか取得できません。RTT が 100 ミリ秒の場合でも、RTSP over UDP は問題なく動作します。これをローカルで実行しているので、rtt が 100ms の場合でもスループットが最大になることを iperf を使用して確認できるため、ネットワーク トラフィックの問題ではありません。だから私はこれが何が原因なのだろうか？

oRTP の RECVONLY セッションで RTCP を受信しようとすると、現在 segfault が発生します。RTCP は、SENDRECV セッションでの受信時には正常に機能しますが、RECVONLY セッションでは機能しません。

これは私のコードです。segfault は、42 行目の関数から発生します。これは、ファイルを受け取る while ループにあります。

ただし、これは 32 行目でのみ発生します。

rtp_session_enable_rtcp(セッション、TRUE); TRUE に設定されています。

RTCP を FALSE に設定して無効にすると、RECVONLY セッションが機能します。

gdb を使用してデバッグすると、segfault のこのバックトレースが得られます。

バックトレースから、ライブラリ ファイル str_utils.c に問題があるように見えますが、RECVONLY セッションをセットアップするときに何かを初期化するのを忘れているだけなのかどうかはわかりません。

全体として、42 行目のレシーバ機能は、RECVONLY セッションの RTCP では機能しないように見えます。RTCP が無効になっていても問題はありません。

RTP パケットは RTCP とどのように関係していますか?

ssrc (同期ソース識別子) をそれが記述する RTP ストリームと共有することを期待していましたが、一致する場合 (Sender Reports の場合) と一致しない場合があります。

これについては、どの RFC またはドラフトを読む必要がありますか?