I’m having a problem subscribing when publishing with IOS and unsure if its even publishing.
I get this error on the subscriber side. I get this error when not setting a codec filter on the sdp before publishing I found.
It seems the codec chosen breaks the subscriber or it needs a special codec chosen for IOS that isnt H64 or a specific level.
I think there is no candidate in the offer on IOS either. Its extremely difficult to debug with a broken debug proxy for IOS 13 right now.
Any ideas ?
"‘setRemoteDescription’ on ‘RTCPeerConnection’: Failed to set remote offer sdp*: Failed to set remote video description send parameters* "
The simple Safari publish example on IOS brings up no video just audio is sent. No candidates are sent in the offer still.
It would be nice if this form stops breaking my posts. VP8 works. Its this H264 level filtering on IOS that is the problem. Why is this high level breaking is the question ?
I believe if I dont set a h264 level it will choose one wowza doesnt support
not working offer sent to subscriber. for some reason this level is chosen with IOS. And therefore no candidates are sent from wowza either.
a=rtpmap:97 H264/90000
a=fmtp:97 packetization-mode=1;profile-level-id=64C028;sprop-parameter-sets=Z2QAKKwrQDwBE/LCAAADAAIAAAMAeBtBEI1A,aM48MA==
This works however.
a=rtpmap:97 H264/90000
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=fmtp:97 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
m=audio 9 RTP/SAVPF 96
I’ve been discovering this issue trying RTMP ingest and if I dont set a h264 codec level filter. Why is ti if this level is set everything breaks ?
64C028
I have customised simple-peer peering library to include codec filtering. I am however using the actual api to set preferences if supported and not mudge SDP.
IOS claims to support setting preferences. The codecs returned from RTCRtpSender.getCapabilities, has two H264 codecs, but it fails to provide extra information in a sdpFmtpLine to filter the level… This property is empty, so I don’t know what level it is ! Its then set on “setCodecPreferences”
Trying to debug this further now. Another API discrepancy with IOS with empty data where required or not supporting an “ideal” media device constraint.