2014-09-26 113 views
4

我從瀏覽器中使用的WebRTC到以下安裝工作的服務器流式網絡攝像頭:使用Firefox和改進的回聲測試HTML from janus gateway需要哪個gstreamer管道設置來處理chrome的rtp流?

  1. 我的網絡攝像頭流發送到服務器劍鋒
  2. 所述的Janus服務器正在使用的改性EchoTest中插件,它簡單地UDP流在janus_videorecv_incoming_rtp給定char *的buf()到端口5060上運行,只是用於測試目的(pretty much like this
  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幾行回答瀏覽器將接收如下所示:

//jsep.sdp = jsep.sdp.replace(/a=rtcp-mux[^\s]*\s*/g, ''); 
jsep.sdp = jsep.sdp.replace(/a=rtpmap[^\s]*\s*red[^\s]*\s*/g, ''); 
jsep.sdp = jsep.sdp.replace(/a=rtpmap[^\s]*\s*ulpfec[^\s]*\s*/g, ''); 
jsep.sdp = jsep.sdp.replace(/a=fmtp[^\r\n]*\r*\n*/g, ''); 
jsep.sdp = jsep.sdp.replace(/a=rtcp-fb[^\s]*\s*goog-remb[^\s]*\s*/g, ''); 
下面

,可以發現改性的Firefox SDP應答,其適用於上面gstreamer的命令 但在鉻 的情況下,以相同的方式,修改的SDP應答不工作我想了解在gstreamer的帽調整有效載荷,但32,33,96,100,120沒有工作

所以問題是:鉻的情況下需要什麼才能使其工作?

我也嘗試在鉻的情況下,加入在從詹納斯videoroom.c冷杉/ PLI請求等作爲suggested here

的gstreamer的輸出是,這裏的命令只是不斷在最後一行等待:

0:00:00.025791492 22279  0x1954b90 DEBUG    pipeline gstpipeline.c:219:gst_pipeline_init:<[email protected]> set bus <bus2> on pipeline 
Setting pipeline to PAUSED ... 
0:00:00.029798090 22279  0x1954b90 DEBUG    pipeline gstpipeline.c:282:reset_start_time:<pipeline0> reset start_time to 0 
Pipeline is live and does not need PREROLL ... 
/GstPipeline:pipeline0/GstUDPSrc:udpsrc0.GstPad:src: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, payload=(int)96, encoding-name=(string)VP8-DRAFT-IETF-01 
Setting pipeline to PLAYING ... 
0:00:00.030045034 22279  0x1954b90 DEBUG    pipeline gstpipeline.c:377:gst_pipeline_change_state:<pipeline0> selecting clock and base_time 
0:00:00.030053523 22279  0x1954b90 DEBUG    pipeline gstpipeline.c:398:gst_pipeline_change_state:<pipeline0> Need to update start_time 
0:00:00.030058181 22279  0x1954b90 DEBUG    pipeline gstpipeline.c:403:gst_pipeline_change_state:<pipeline0> Need to update clock. 
/GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:src: caps = video/x-vp8, framerate=(fraction)0/1 
/GstPipeline:pipeline0/GstVP8Dec:vp8dec0.GstPad:sink: caps = video/x-vp8, framerate=(fraction)0/1 
0:00:00.030111345 22279  0x1954b90 DEBUG    pipeline gstpipeline.c:443:gst_pipeline_change_state:<pipeline0> start_time=0:00:00.000000000, now=33:52:04.529345754, base_time 33:52:04.529345754 
/GstPipeline:pipeline0/GstRtpVP8Depay:rtpvp8depay0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, payload=(int)96, encoding-name=(string)VP8-DRAFT-IETF-01 
New clock: GstSystemClock 

鉻答案:

v=0 
o=- 8913399741269897639 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 103 104 0 8 106 105 13 126 
a=mid:audio 
c=IN IP4 192.168.0.1 
a=sendrecv 
a=rtcp-mux 
a=ice-ufrag:l0n9 
a=ice-pwd:r1elT1Ew8lP3TNlzwAHUsC 
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=rtpmap:103 ISAC/16000 
a=rtpmap:104 ISAC/32000 
a=rtpmap:0 PCMU/8000 
a=rtpmap:8 PCMA/8000 
a=rtpmap:106 CN/32000 
a=rtpmap:105 CN/16000 
a=rtpmap:13 CN/8000 
a=rtpmap:126 telephone-event/8000 
a=maxptime:60 
a=ssrc:600390024 cname:janusaudio 
a=ssrc:600390024 msid:janus janusa0 
a=ssrc:600390024 mslabel:janus 
a=ssrc:600390024 label:janusa0 
a=candidate:1 1 udp 2013266431 192.168.0.1 45728 typ host 
m=video 1 RTP/SAVPF 100 116 117 96 
a=mid:video 
c=IN IP4 192.168.0.1 
a=sendrecv 
a=rtcp-mux 
a=ice-ufrag:l0n9 
a=ice-pwd:r1elT1Ew8lP3TNlzwAHUsC 
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=rtpmap:96 rtx/90000 
a=ssrc-group:FID 3188003624 3419969288 
a=ssrc:677441062 cname:janusvideo 
a=ssrc:677441062 msid:janus janusv0 
a=ssrc:677441062 mslabel:janus 
a=ssrc:677441062 label:janusv0 
a=candidate:1 1 udp 2013266431 192.168.0.1 45728 typ host 
m=application 0 DTLS/SCTP 0 
c=IN IP4 192.168.0.1 

firefox的答案:

v=0 
o=Mozilla-SIPUA-32.0.3 11426 0 IN IP4 127.0.0.1 
s=SIP Call 
t=0 0 
a=group:BUNDLE audio video 
a=msid-semantic: WMS janus 
m=audio 1 RTP/SAVPF 109 0 8 101 
a=mid:audio 
c=IN IP4 192.168.0.1 
a=sendrecv 
a=rtcp-mux 
a=ice-ufrag:BRBU 
a=ice-pwd:2W4fGNr//HejhiC4UIabW6 
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:109 opus/48000/2 
a=ptime:20 
a=rtpmap:0 PCMU/8000 
a=rtpmap:8 PCMA/8000 
a=rtpmap:101 telephone-event/8000 
a=fmtp:101 0-15 
a=ssrc:3725983979 cname:janusaudio 
a=ssrc:3725983979 msid:janus janusa0 
a=ssrc:3725983979 mslabel:janus 
a=ssrc:3725983979 label:janusa0 
a=candidate:1 1 udp 2013266431 192.168.0.1 56574 typ host 
m=video 1 RTP/SAVPF 120 
a=mid:video 
c=IN IP4 192.168.0.1 
a=sendrecv 
a=rtcp-mux 
a=ice-ufrag:jZ5b 
a=ice-pwd:dQQej9UIpPl5zuXBQNg3Nz 
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:120 VP8/90000 
a=rtcp-fb:120 nack 
a=rtcp-fb:120 nack pli 
a=rtcp-fb:120 ccm fir 
a=ssrc:1425382999 cname:janusvideo 
a=ssrc:1425382999 msid:janus janusv0 
a=ssrc:1425382999 mslabel:janus 
a=ssrc:1425382999 label:janusv0 
a=candidate:2 1 udp 2013266431 192.168.0.1 39063 typ host 
m=application 0 DTLS/SCTP 0 
c=IN IP4 192.168.0.1 

UPDATE: 我修改了SDP-回答這樣既Firefox和Chrome獲得近,除了我剛剛從SDP要約複製「O =」和「s =」行相同 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

+0

在chrome中,並非所有的映射都被刪除。你爲什麼要刪除'a = rtcp-fb:100 goog-remb'?糾正視頻媒體行上顯示的rtp有效載荷,並刪除未被佔用的'rtx' rtp映射。這應該會讓你更進一步。你確定chrome甚至會向你發送任何媒體嗎?我猜測它在答案上很怪,並且不發送任何東西。如果它發送媒體,你可以打破rtp頭,並查看有效載荷,以確保它是VP8 – 2014-09-26 18:15:03

+0

我實際上刪除了goog-remb,因爲我試圖逐行刪除行,也許有一些工作。實際上chrome正在發送數據,我的janus插件也正確轉發,正如我通過wireshark所看到的。關於「視頻媒體行中正確的rtp有效載荷」,你的意思是我應該設置m = video 1 RTP/SAVPF 120,就像在Firefox中一樣?通過分解rtp頭文件究竟是什麼意思?你會怎麼做?感謝您的時間 – 2014-09-26 18:44:38

+0

該行應該是'm = video 1 RTP/SAVPF 100'來表示只有一個映射(對於VP8)。那麼只有VP8映射應該存在。 [一些webrtc sdp指針](http://webrtchacks.com/sdp-anatomy/)。您可以將緩衝區轉換爲rtp數據包,然後訪問該類型。 'rtp_header * packetheader =(rtp_header *)buf; \t \t packetheader-> type; //有效載荷' – 2014-09-26 19:00:18

回答

0

我已經更新了包含the bidirectional streaming plugin的fork,向您展示了一個可用的示例(我已在debian jessie上進行了測試)。

這裏是我的三分球給你的插件改變

  1. 確保您的GStreamer管道被設置爲接收之前,您從鍍鉻請求關鍵幀
  2. 請求你的關鍵幀時WebRTC媒體已準備就緒(見janus_bidirectional_streaming_setup_media功能瞭解詳情)
  3. 請勿使用rtpbin gstreamer元素處理傳入流。由於某些原因,它設置上限的方式並不真正起作用,管道將崩潰。如果你得到的RTP包,並能夠把它們發送到端口,那麼下面的管道的工作沒有問題:gst-launch-1.0 udpsrc port=<your listener> caps="application/x-rtp, clock-rate=90000, payload=100" ! rtpvp8depay ! vp8dec ! autovideosink sync=false async=false

從理論上講,直接推緩衝區到appsrc內的插件應該正常工作。

1

WebRTC使用DTLS-SRTP進行強制加密(Chrome仍支持非標準和明確的MUST-NOT-IMPLMENT SDES鍵控)。

你不能只將一個RTP流提供給webrtc;它必須是一個以初始DTLS連接爲關鍵字的DTLS-SRTP流。

人們已經將node.js掛鉤到webrtc瀏覽器,所以我想象你需要的所有機器都在那裏。

+0

我不確定我是否理解你的權利。你的意思是「不能只喂一個rtp流到webrtc」的情況下,我發送rtp從服務器到瀏覽器?如果是的話,那不是我想要做的。我從webrtc(瀏覽器)發送rtp到服務器,並嘗試使用gstreamer向服務器顯示流,主要是爲了調試/測試目的。關於dtls,儘管我不知道所有的細節,但我讀到janus(服務器)處理這個 – 2014-09-27 07:11:04

+0

數據包在到達gstreamer管道時被解密。 Janus負責處理每個數據包的解密和解複用。 – 2014-09-27 16:23:21

0

Kurento媒體服務器(KMS)是完全寫在GStreamer之上的WebRTC媒體服務器。 KMS提供了一個WebRtcEndpoint,用於實現向Web瀏覽器發送/接收WebRTC流所需的所有協議和算法。 KMS根據媒體元素和媒體管道進行公開和API,這可以轉化爲GStreamer媒體管道。一般來說,您在GStreamer上的所有功能都可以在KMS中使用。您可以在http://www.kurento.org中查看KMS。

聲明:我是Kurento開發團隊的成員。

+0

什麼流水線專門與來自Chrome的WebRTC流的解密,解複用RTP流配合使用?用戶已經在使用janus,所以只是連接另一種技術並不能真正回答問題。 – 2014-09-27 16:24:44