WebRTC - не может отображать удаленный mediaStream

Это заставляет меня взбираться по стенам. Я работал над коммуникационным приложением webRTC. Базовый вариант использования меня не подводит.

Таким образом, я могу создать RTCPeerConnection просто отлично, добавить к нему только что полученный mediaStream, одноранговый обмен предложения / ответа / iceCandidates, соединение успешно, и я вижу, что объект mediaStream правильно поступает на другой конец соединения, когда вызывается обратный вызов .onaddstream .

До сих пор все в порядке, но теперь я не могу нарисовать медиапоток в элементе видео. Я попытался заменить src существующего элемента видео, а также создать новый элемент видео с нуля. Кажется, ничего не работает.

На всякий случай еще и треки на полученном mediaStream проверил. Все выглядит нормально. Один для звука, один для видео и оба включены = true.

Кто-нибудь сталкивался с этим?

ОБНОВЛЕНО

Предложение:

v=0
↵o=- 6956171358659097378 2 IN IP4 127.0.0.1
↵s=-
↵t=0 0
↵a=group:BUNDLE audio video
↵a=msid-semantic: WMS IqUsuHBZTllg61x1bh2v6hK34e2odmLWZvlc
↵m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
↵c=IN IP4 0.0.0.0
↵a=rtcp:9 IN IP4 0.0.0.0
↵a=ice-ufrag:vXOp
↵a=ice-pwd:J74PQYw8MI2YKF//VXvmpsA/
↵a=fingerprint:sha-256 CB:B5:85:14:ED:2E:1E:8D:0C:2E:69:86:58:F4:B1:52:D0:C4:8B:1B:C8:72:08:5C:16:B6:E3:F8:FF:EE:E2:FE
↵a=setup:actpass
↵a=mid:audio
↵a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
↵a=sendrecv
↵a=rtcp-mux
↵a=rtpmap:111 opus/48000/2
↵a=rtcp-fb:111 transport-cc
↵a=fmtp:111 minptime=10;useinbandfec=1
↵a=rtpmap:103 ISAC/16000
↵a=rtpmap:104 ISAC/32000
↵a=rtpmap:9 G722/8000
↵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:110 telephone-event/48000
↵a=rtpmap:112 telephone-event/32000
↵a=rtpmap:113 telephone-event/16000
↵a=rtpmap:126 telephone-event/8000
↵a=ssrc:1609504167 cname:b7o7HCuRjcMovZC0
↵a=ssrc:1609504167 msid:IqUsuHBZTllg61x1bh2v6hK34e2odmLWZvlc 96ee4822-2115-4704-879c-9ebd87bd7819
↵a=ssrc:1609504167 mslabel:IqUsuHBZTllg61x1bh2v6hK34e2odmLWZvlc
↵a=ssrc:1609504167 label:96ee4822-2115-4704-879c-9ebd87bd7819
↵m=video 9 UDP/TLS/RTP/SAVPF 96 98 100 102 127 97 99 101 125
↵c=IN IP4 0.0.0.0
↵a=rtcp:9 IN IP4 0.0.0.0
↵a=ice-ufrag:vXOp
↵a=ice-pwd:J74PQYw8MI2YKF//VXvmpsA/
↵a=fingerprint:sha-256 CB:B5:85:14:ED:2E:1E:8D:0C:2E:69:86:58:F4:B1:52:D0:C4:8B:1B:C8:72:08:5C:16:B6:E3:F8:FF:EE:E2:FE
↵a=setup:actpass
↵a=mid:video
↵a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
↵a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
↵a=extmap:4 urn:3gpp:video-orientation
↵a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
↵a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
↵a=sendrecv
↵a=rtcp-mux
↵a=rtcp-rsize
↵a=rtpmap:96 VP8/90000
↵a=rtcp-fb:96 ccm fir
↵a=rtcp-fb:96 nack
↵a=rtcp-fb:96 nack pli
↵a=rtcp-fb:96 goog-remb
↵a=rtcp-fb:96 transport-cc
↵a=rtpmap:98 VP9/90000
↵a=rtcp-fb:98 ccm fir
↵a=rtcp-fb:98 nack
↵a=rtcp-fb:98 nack pli
↵a=rtcp-fb:98 goog-remb
↵a=rtcp-fb:98 transport-cc
↵a=rtpmap:100 H264/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=rtcp-fb:100 transport-cc
↵a=fmtp:100 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
↵a=rtpmap:102 red/90000
↵a=rtpmap:127 ulpfec/90000
↵a=rtpmap:97 rtx/90000
↵a=fmtp:97 apt=96
↵a=rtpmap:99 rtx/90000
↵a=fmtp:99 apt=98
↵a=rtpmap:101 rtx/90000
↵a=fmtp:101 apt=100
↵a=rtpmap:125 rtx/90000
↵a=fmtp:125 apt=102
↵a=ssrc-group:FID 3183126486 3711718742
↵a=ssrc:3183126486 cname:b7o7HCuRjcMovZC0
↵a=ssrc:3183126486 msid:IqUsuHBZTllg61x1bh2v6hK34e2odmLWZvlc b5ae9b5a-0555-4a68-814d-cfd124dd4b27
↵a=ssrc:3183126486 mslabel:IqUsuHBZTllg61x1bh2v6hK34e2odmLWZvlc
↵a=ssrc:3183126486 label:b5ae9b5a-0555-4a68-814d-cfd124dd4b27
↵a=ssrc:3711718742 cname:b7o7HCuRjcMovZC0
↵a=ssrc:3711718742 msid:IqUsuHBZTllg61x1bh2v6hK34e2odmLWZvlc b5ae9b5a-0555-4a68-814d-cfd124dd4b27
↵a=ssrc:3711718742 mslabel:IqUsuHBZTllg61x1bh2v6hK34e2odmLWZvlc
↵a=ssrc:3711718742 label:b5ae9b5a-0555-4a68-814d-cfd124dd4b27

Отвечать:

v=0
↵o=- 191937705071419457 2 IN IP4 127.0.0.1
↵s=-
↵t=0 0
↵a=group:BUNDLE audio video
↵a=msid-semantic: WMS
↵m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
↵c=IN IP4 0.0.0.0
↵a=rtcp:9 IN IP4 0.0.0.0
↵a=ice-ufrag:DxU/
↵a=ice-pwd:apFEGyelJKYHQg9eehCSHJ4A
↵a=fingerprint:sha-256 0E:7A:BF:BB:54:04:C1:71:55:2B:6F:36:80:58:71:C0:F9:65:34:92:70:F4:EB:71:1A:97:00:30:7D:CE:E7:CB
↵a=setup:active
↵a=mid:audio
↵a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
↵a=recvonly
↵a=rtcp-mux
↵a=rtpmap:111 opus/48000/2
↵a=rtcp-fb:111 transport-cc
↵a=fmtp:111 minptime=10;useinbandfec=1
↵a=rtpmap:103 ISAC/16000
↵a=rtpmap:104 ISAC/32000
↵a=rtpmap:9 G722/8000
↵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:110 telephone-event/48000
↵a=rtpmap:112 telephone-event/32000
↵a=rtpmap:113 telephone-event/16000
↵a=rtpmap:126 telephone-event/8000
↵m=video 9 UDP/TLS/RTP/SAVPF 96 98 100 102 127 97 99 101 125
↵c=IN IP4 0.0.0.0
↵a=rtcp:9 IN IP4 0.0.0.0
↵a=ice-ufrag:DxU/
↵a=ice-pwd:apFEGyelJKYHQg9eehCSHJ4A
↵a=fingerprint:sha-256 0E:7A:BF:BB:54:04:C1:71:55:2B:6F:36:80:58:71:C0:F9:65:34:92:70:F4:EB:71:1A:97:00:30:7D:CE:E7:CB
↵a=setup:active
↵a=mid:video
↵a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
↵a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
↵a=extmap:4 urn:3gpp:video-orientation
↵a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
↵a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
↵a=recvonly
↵a=rtcp-mux
↵a=rtcp-rsize
↵a=rtpmap:96 VP8/90000
↵a=rtcp-fb:96 ccm fir
↵a=rtcp-fb:96 nack
↵a=rtcp-fb:96 nack pli
↵a=rtcp-fb:96 goog-remb
↵a=rtcp-fb:96 transport-cc
↵a=rtpmap:98 VP9/90000
↵a=rtcp-fb:98 ccm fir
↵a=rtcp-fb:98 nack
↵a=rtcp-fb:98 nack pli
↵a=rtcp-fb:98 goog-remb
↵a=rtcp-fb:98 transport-cc
↵a=rtpmap:100 H264/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=rtcp-fb:100 transport-cc
↵a=fmtp:100 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
↵a=rtpmap:102 red/90000
↵a=rtpmap:127 ulpfec/90000
↵a=rtpmap:97 rtx/90000
↵a=fmtp:97 apt=96
↵a=rtpmap:99 rtx/90000
↵a=fmtp:99 apt=98
↵a=rtpmap:101 rtx/90000
↵a=fmtp:101 apt=100
↵a=rtpmap:125 rtx/90000
↵a=fmtp:125 apt=102

addIceCandidates правильно вызывается в RTCPeerConnenction.


webrtc video mediastream
person FerBorVa    schedule 24.05.2017    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Проверяем состояние ледяного соединения, оно должно быть подключено / завершено. Тогда от источника к месту назначения будут перетекать только медиа.

function gotRemoteStream(e) {
  if (remoteVideo.srcObject !== e.streams[0]) {
    remoteVideo.srcObject = e.streams[0];
    console.log('pc received remote stream');
  }
}
//pc.onaddstream = gotRemoteStream; // this got deprecated
pc.ontrack = gotRemoteStream;

Попробуйте демонстрацию и проверьте источник.

person Ajay    schedule 24.05.2017
comment
Привет @Ajay, проверил. Я использовал обработчик oniceconnectionstatechange для проверки изменений состояния льда. Я вижу, что состояние меняется на «проверка» на удаленном конце и не продвигается оттуда. Ледяные кандидаты правильно обмениваются и правильно добавляются в RTCPeerConnection. Обработчик ontrack никогда не выполняется. - person FerBorVa; 26.05.2017
comment
Если кандидаты должным образом заменены и добавлены, то лед соединится. Добавьте точку останова и проверьте, звонит ли pc.addIceCandidate. Поделитесь своим предложением и ответьте sdp. - person Ajay; 26.05.2017
comment
Вопрос обновлен предложением и ответом sdp. Проверено, что addIceCandidates вызывается правильно. - person FerBorVa; 26.05.2017

arrow_upward
0
arrow_downward

Нашел проблему. Проблема возникла из-за плохой связи между разработчиками по поводу изменения имени API. Все коммуникации между одноранговыми узлами работали правильно, но сторона, создавшая предложение, не добавляла удаленное описание к своему RTC-соединению. Следовательно, iceConnectionStatus остался новым, а signallingStatus - has-local-descripion. После того, как удаленное описание было установлено правильно, все коммуникации завершились и поток прошел.

Немного неприятный, чтобы остановиться, потому что: - Предложение было создано и добавлено правильно. Потом отправили. В этот момент iceCandidates также были получены и отправлены правильно. - Предложение получено правильно, установлено как удаленное и ответ создан правильно. На данный момент iceCandidates были получены и отправлены правильно. - Событие onaddstream было инициировано и сторона, которая ожидала получить поток.

На мой взгляд, это событие не должно запускаться, пока не завершится iceConnection. Думаю, это было то, что меня больше всего смущало.

@Ajay, Спасибо за уделенное время!

person FerBorVa    schedule 26.05.2017
comment
спецификация не согласуется с вашим мнением. - person Philipp Hancke; 26.05.2017
comment
Действительно, это моё мнение - person FerBorVa; 27.05.2017