iOS 12 WebRT C поток, отправленный с H264 High Profile, даже если стороны договорились о базовом профиле - PullRequest
Новая
       63

iOS 12 WebRT C поток, отправленный с H264 High Profile, даже если стороны договорились о базовом профиле

0 голосов
/ 16 июня 2020

Я разрабатываю потоковое приложение WebRT C, которое использует Wowza для создания вызовов. У меня проблемы с соединением между двумя клиентами, когда один из них использует iOS 12 или iOS 11, а другой использует Chrome браузер на P C.

Я заметил в журналах wowza что даже несмотря на то, что я настроил SDP, чтобы он содержал только базовый профиль H264, он все еще отображается как a=fmtp:97 packetization-mode=1;profile-level-id=64C01F;sprop-parameter-sets=J2QAH6xWgKA9puBAQEDaCIRqAA==,KO48sA== на сервере.

Я обнаружил ошибку в радаре webkit https://bugs.webkit.org/show_bug.cgi?id=195124, которая соответствует вышеупомянутому

Интересно, а можно ли как-нибудь обойти это и заставить Chrome на другой стороне декодировать видео?

Вот локальный SDP: 

o=- 9001760195467366328 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS 5113e7f1-363b-406e-bc68-3ae57daa0d1a
m=video 9 UDP/TLS/RTP/SAVPF 99
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:n8Ba
a=ice-pwd:2NwRnFdR5IvWpNRPiA9UqL6Q
a=ice-options:trickle
a=fingerprint:sha-256 C3:B0:13:62:B2:96:27:6F:4B:F6:97:B4:BE:3C:46:00:98:D1:98:ED:57:80:96:E9:6E:9C:33:9F:3F:2A:70:22
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:99 H264/90000
a=rtcp-fb:99 ccm fir
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 goog-remb
a=rtcp-fb:99 transport-cc
a=fmtp:99 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=fmtp:97 apt=96
a=fmtp:100 apt=99
a=ssrc-group:FID 138058512 1765676750
a=ssrc:138058512 cname:1qSotaZJYR/SLq+u
a=ssrc:138058512 msid:5113e7f1-363b-406e-bc68-3ae57daa0d1a 6f3574c4-06ca-49fe-812f-f4e9b9d3cdbf
a=ssrc:138058512 mslabel:5113e7f1-363b-406e-bc68-3ae57daa0d1a
a=ssrc:138058512 label:6f3574c4-06ca-49fe-812f-f4e9b9d3cdbf
a=ssrc:1765676750 cname:1qSotaZJYR/SLq+u
a=ssrc:1765676750 msid:5113e7f1-363b-406e-bc68-3ae57daa0d1a 6f3574c4-06ca-49fe-812f-f4e9b9d3cdbf
a=ssrc:1765676750 mslabel:5113e7f1-363b-406e-bc68-3ae57daa0d1a
a=ssrc:1765676750 label:6f3574c4-06ca-49fe-812f-f4e9b9d3cdbf

Удаленный: 

o=WowzaStreamingEngine-next 2021784490 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS *
m=video 9 UDP/TLS/RTP/SAVPF 99
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:55de6aa9
a=ice-pwd:60187779305a687c507cef701c99a6d2
a=ice-options:trickle
a=fingerprint:sha-256 35:5A:C1:C8:57:EB:46:2C:1E:98:9D:14:B8:4F:80:59:CF:7A:35:4D:57:71:47:8C:6A:9B:76:CA:EE:A9:E5:BC
a=setup:passive
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:99 H264/90000
a=rtcp-fb:99 ccm fir
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 goog-remb
a=rtcp-fb:99 transport-cc
a=fmtp:99 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f

1 Ответ

0 голосов
/ 17 июня 2020

Похоже, что независимо от выбора пользователя при вызове метода supportedCodecs безоговорочно выбирается первый профиль. В моем случае я решил это, изменив метод supportedCodecs в файле RTCVideoEncoderFactoryH264.mm фреймворка Google WebRT C, чтобы базовый профиль отображался первым. Однако я решил это, потому что мне нужно было поддерживать только базовый профиль, но потребовалось бы немного больше изменений, чтобы сделать профиль доступным для выбора.

...