Got WebRTC publishing to work in Safari but players get incorrect profile-level-id

[Teodor_Nica1]

Got webRTC publishing to work with Safari in BroadcastLiveVideo.com solution (can be tested in live demo at VideoNow.Live).

Publishing works (received on server) and is available for playback over RTMP or HLS / MPEG DASH after transcoding but does not work directly in WebRTC.

Publisher JS reports correctly configured profile-level-id 42e01f (Constrained Baseline) in SDP:

a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f

Playback JS reports incorrect profile-level-id in SDP:

a=fmtp:97 packetization-mode=1;profile-level-id=64C029

And results in error:

OperationError: Failed to set remote offer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to set remote video description send parameters..

The RTSP stream accessible on server seems to have High profile when publishing with Safari:

h264 (High), yuv420p(progressive), 640x480, 30 tbr, 90k tbn, 180k tbc

When publishing with Chrome is Constrained Baseline:

h264 (Constrained Baseline), yuv420p(progressive), 640x480, 30 tbr, 90k tbn, 180k tbc

Same code works fine when broadcasting from Chrome:

a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f

And Chrome stream plays fine in all browsers, including in Safari:

a=fmtp:97 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f

The issue seem to be related to Safari publishing stream with High 64C029 profile instead of Constrained Baseline 42e01f.

The question: Is there something that can be done in JS code or Wowza configuration for Safari WebRTC stream to playback using WebRTC directly (without transcoding), similar to how Chrome streams work?

[Rose_Power-Wowza_Com]

Thanks for sharing this with the community @Teodor Nica and sharing so many code snippets. Because WebRTC is still in preview here at Wowza and does not currently support Safari playback, I do not have any docs to share with you for a solution here in the forums.

However, you are welcome to submit a support ticket and see if an engineer can assist you with some ideas since you have made so much progress.

---

• Currently, playback of WebRTC streams from Wowza Streaming Engine are only supported in Google Chrome and Mozilla Firefox browsers.
• Google Chrome and Mozilla Firefox don’t support AAC audio over WebRTC. Streams with AAC audio are played as video-only.

[Rose_Power-Wowza_Com]

Open a Support Ticket | Wowza Media Systems

[Teodor_Nica1]

Upgraded from 4.7.6 to 4.7.7 and tested with the exact “webrtcexamplepages” provided, to easily replicate and make sure it’s not something related to our code.

In Chrome, publishing, playback and SDP profiles work fine but Safari publishing generates same issue.

Safari receives High encoded stream and profile in SDP, 64C029:

m=video 9 RTP/SAVPF 97 
a=rtpmap:97 H264/90000 
a=fmtp:97 packetization-mode=1;profile-level-id=64C029;sprop-parameter-sets=J2QAKawTFlAoD2wAMDAAXcAAF3Be98HaCIRlgA==,KO8fLA== 

When publishing from Safari, in JS console stream has correct profile in SDP, 42e01f:

a=rtpmap:96 H264/90000
a=fmtp:96 x-google-min-bitrate=360;x-google-max-bitrate=360 
a=rtcp-fb:96 goog-remb 
a=rtcp-fb:96 transport-cc a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack a=rtcp-fb:96 nack pli
a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f

Suspecting issue is somewhere between Safari and server.

Submitted a support ticket.

[Piotr_Kedziora]

Did you found the solution?

I’m having a similar problem. I installed a fresh Wowza 4.7.7 and webRTC from Wowza works fine in Chrome (Publish and Play) However in Safari

seems that the profile-id I have is 640029

[Jay_Charles1]

If you look at the SDP offer Chrome generates (particularly on Windows) you’ll find that there are multiple h264 profiles in the offer, including main and baseline without constraint flags which aren’t supported in all browsers. Wowza parrots that list back in the answer, leaving it up to Chrome to choose which profile to publish.

The solution is to remove them from your SDP offer before sending the offer over the socket to wowza. See internet for “sdp munging”. You need to get rid of the fmtp lines for the offending profiles and all references to them. Strip it down to only 42e01f (spec mandatory), and your video will play almost everywhere.

[Piotr_Kedziora]

Thanks Jay, Ths thing is that is have only 42e01f in me sdpOffer on the publisher side. Anyways I will experiment with SDP offers on both sides.

v=0
o=- 5961871527461151003 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 261b2156-7668-42d3-ba42-afd70aca12f4
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:TnBB
a=ice-pwd:/sCiuJftFD7Byg4dcvkyv2er
a=ice-options:trickle
a=fingerprint:sha-256 6A:D7:EB:F1:FF:D0:DB:50:65:3A:21:91:95:9E:4C:E9:E8:D8:71:DF:02:E2:F3:E7:BE:EA:5C:5F:5D:0C:39:E4
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=fmtp:111 x-google-min-bitrate=64;x-google-max-bitrate=64
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=ssrc:1643664416 cname:utz/napF5lUZQEux
a=ssrc:1643664416 msid:261b2156-7668-42d3-ba42-afd70aca12f4 552a6560-572d-47b8-9da6-7d158e03257c
a=ssrc:1643664416 mslabel:261b2156-7668-42d3-ba42-afd70aca12f4
a=ssrc:1643664416 label:552a6560-572d-47b8-9da6-7d158e03257c
m=video 9 UDP/TLS/RTP/SAVPF 98
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:TnBB
a=ice-pwd:/sCiuJftFD7Byg4dcvkyv2er
a=ice-options:trickle
a=fingerprint:sha-256 6A:D7:EB:F1:FF:D0:DB:50:65:3A:21:91:95:9E:4C:E9:E8:D8:71:DF:02:E2:F3:E7:BE:EA:5C:5F:5D:0C:39:E4
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=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:10 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:98 H264/90000
a=fmtp:98 x-google-min-bitrate=360;x-google-max-bitrate=360
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=ssrc-group:FID 3680798038 1539139510
a=ssrc:3680798038 cname:utz/napF5lUZQEux
a=ssrc:3680798038 msid:261b2156-7668-42d3-ba42-afd70aca12f4 cf24986a-a0d4-47c6-b62d-d6b30dc1813a
a=ssrc:3680798038 mslabel:261b2156-7668-42d3-ba42-afd70aca12f4
a=ssrc:3680798038 label:cf24986a-a0d4-47c6-b62d-d6b30dc1813a
a=ssrc:1539139510 cname:utz/napF5lUZQEux
a=ssrc:1539139510 msid:261b2156-7668-42d3-ba42-afd70aca12f4 cf24986a-a0d4-47c6-b62d-d6b30dc1813a
a=ssrc:1539139510 mslabel:261b2156-7668-42d3-ba42-afd70aca12f4
a=ssrc:1539139510 label:cf24986a-a0d4-47c6-b62d-d6b30dc1813a

And it plays on all browsers except Safari that has this “additional” High Profile.

I tried to remove it from sdp on the player but that didn’t helped

[Piotr_Kedziora]

Also with this SDP(there is only 42e01f in profile) In Wowza logs there is a warrnig that safari is sending indeed High Profile

INFO server comment - LiveStreamPacketizerCupertino.handlePacket[live/_definst_/myStream][avc1.100.41]: H.264 (Video may not be playable on older iPhone and iPod touch devices where Main/Level 3.1 or lower is required) Video info: {H264CodecConfigInfo: codec:H264, profile:High, level:4.1, frameSize:640x480, displaySize:640x480}