問題タブ [janus-gateway]

webrtc を使用してブラウザーから次のセットアップが機能するサーバーに Web カメラをストリーミングしています。

1. firefox とjanus ゲートウェイからの変更された echo-test html を使用して、webcam ストリームを janus サーバーに送信します
2. janus サーバーは、変更された echotest プラグインを使用して実行されています。このプラグインは、janus_videorecv_incoming_rtp() で指定された char *buf をポート 5060 に単純に udp ストリームします。
3. 次の gstreamer コマンド ラインは、実際にストリーミング ビデオを表示するウィンドウを開きます

GST_DEBUG=p*:5 gst-launch-1.0 -vvv udpsrc caps="application/x-rtp,media=video,clock-rate=90000,payload=96" port=5060 ! rtpvp8depay ! vp8dec ! autovideosink

変更されたエコー テスト JavaScript で、ブラウザーが受け取る sdp 回答から次のように数行を削除します。

以下では、上記のgstreamerコマンドで機能する変更されたfirefox sdpの回答を見つけることができますが、同じように、gstreamerキャップでペイロードを調整することを考えたクロムの場合、変更されたsdpの回答は機能しませんが、32,33,96,100,120動作しませんでした

問題は、クロムの場合、これを機能させるために何が必要ですか?

ここで提案されているように、janusのvideoroom.cのようなfir / pliリクエストも追加しようとしました

クロムの場合の gstreamer 出力は、コマンドが最後の行で待機し続ける場合です。

クロムの答え：

ファイアフォックスの答え:

更新: sdp-answer を変更したので、sdp-offer からコピーした "o=" と "s=" の行を除いて、firefox と chrome の両方がほぼ同じになります。 v=0 o=- 7589782217972865757 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio video a=msid-semantic: WMS janus m=audio 1 RTP/SAVPF 111 a=mid:audio c=IN IP4 192.168.0.1 a=sendrecv a=rtcp-mux a=ice-ufrag:g0kZ a=ice-pwd:d5oEody1jqIzDYUdf1fg6t a=ice-options:trickle a=fingerprint:sha-256 C5:5F:DA:7D:84:47:B1:BF:6B:55:16:62:48:31:3E:D3:F1:7B:25:89:92:4A:4B:4D:4D:D9:D5:AF:EA:D8:15:44 a=setup:active a=connection:new a=rtpmap:111 opus/48000/2 a=ssrc:1038736511 cname:janusaudio a=ssrc:1038736511 msid:janus janusa0 a=ssrc:1038736511 mslabel:janus a=ssrc:1038736511 label:janusa0 a=candidate:1 1 udp 2013266431 192.168.0.1 51232 typ host m=video 1 RTP/SAVPF 100 a=mid:video c=IN IP4 192.168.0.1 a=sendrecv a=rtcp-mux a=ice-ufrag:g0kZ a=ice-pwd:d5oEody1jqIzDYUdf1fg6t a=ice-options:trickle a=fingerprint:sha-256 C5:5F:DA:7D:84:47:B1:BF:6B:55:16:62:48:31:3E:D3:F1:7B:25:89:92:4A:4B:4D:4D:D9:D5:AF:EA:D8:15:44 a=setup:active a=connection:new a=rtpmap:100 VP8/90000 a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=rtcp-fb:100 goog-remb a=ssrc:2455978689 cname:janusvideo a=ssrc:2455978689 msid:janus janusv0 a=ssrc:2455978689 mslabel:janus a=ssrc:2455978689 label:janusv0 a=candidate:1 1 udp 2013266431 192.168.0.1 51232 typ host m=application 0 DTLS/SCTP 0 c=IN IP4 192.168.0.1

webrtc で janus ゲートウェイを使用するのは初めてです。janus ゲートウェイでデモ アプリケーションを実行しました。ここで、gdb で janus アプリケーションを実行して、デバッグ情報をテストしたいと考えています。どうすればこれを実行し、デバッグ情報をファイルに取得できますか。どんな種類の助けもいただければ幸いです。
以下は、janus ゲートウェイのドキュメントへのリンクです。 http://janus.conf.meetecho.com/docs/

Webrtc 提供ブラウザから、janus ゲートウェイを使用して復号化される RTP ストリームを受け取ります。ビデオ rtp パケットのみを受信すると、テスト目的でローカル マルチキャスト グループに中継されます。

したがって、udp ポートで vp8 でエンコードされた rtp パケットを受信するとします。また、いつでも新しいキーフレームをリクエストできます。

問題のパイプライン:

エラーが発生します

Kurento プロジェクトは、この問題を解決する「vp8parse」と呼ばれる gstreamer プラグインを提供しています。

vp8parse ソースを見ると、このプラグインは rtpvp8depay が提供するフレームをそのままシンクにパイプする以外に何もしていないように見えますが、src キャップをビデオの幅、高さ、フレームレートに設定しています。

動作する代替パイプラインは次のとおりです。

しかし、 vp8dec を使用しています! vp8enc は、vp8 でエンコードされたストリームを既に受信しているため、あまり意味がありません。

今私の質問は、ストリームを再エンコードせず、vp8parseに依存せずにこれを解決するにはどうすればよいですか? 代替手段がない場合は、それを使用する必要があるようですが、これは現在、標準の gstreamer プラグイン パッケージでは利用できないプラグインであるため、これは避けたいと思います。キャップを特定の幅、高さ、フレームレートに強制して、webmmux が文句を言わないようにすることは可能ですか? それが、最初のパイプラインがネゴシエートされていない理由だと思います。

rtpvp8depay のように capsfilter を使ってみた! capsfilter caps="video/x-vp8,width=640,height=480,framerate=10/1" ! webmmux でもネゴシエートしません。

Web ブラウザーでの記録に janus-gateway を使用しています。記録が完了すると、オーディオとビデオの 2 つのファイルが生成されます。どちらも mjr 形式です。これらの両方のファイルを結合して 1 つのファイルを作成するにはどうすればよいですか?

ここでこのトピックについていくつかの議論がありましたが、私の質問に固有のものではありません。これは、そこで尋ねられた質問の延長と考えることができます。グーグルは、 KurentoとJanusの 2 つの可能なソリューションしか提供しません。私が持っている質問は次のとおりです。

• オープンソースなど、他のオプションはありますか?

• これらのオプションの中で、誰かが実際の使用に基づいた経験を共有できますか?

• そのようなゲートウェイと互換性のある IP カメラのリストはありますか? または

• そのような WebRTC ゲートウェイを使用できるようにするために、IP カメラに必要な特定の機能は何ですか?

• webRTCが実際に軌道に乗れば、IPカメラのwebRTCサポートは時間の問題であり、Onvifなどの標準に組み込まれると言うのは正しいですか?

アプリケーション自体は必要ありませんが、他の WebRTC コンポーネントをプラグインしてアプリケーションを作成できるようにするための最低限のものは必要です。問題はコーデック変換だけではなく、いくつかの関連するシグナリングに関するものです (とにかく標準化されていない WebRTC シグナリングとは異なります)。これは、Kurento here でうまく議論されています。

また、IP カメラの規格、特に Onvif についても読みました。別の問題であるこの標準との互換性を探しているわけではありません。

おそらく最も人気のあるCCTVカメラ用のオープンソースソフトウェアであるZoneminderを調べましたが、これは非常に肥大化したソフトウェアであり、本格的なアプリケーションであり、webRTCを介したカメラビデオ/オーディオのストリーミングをサポートしていません.