h264 doesn't work in Firefox macOS

[Kukunin]

I try to make Safari 11 working with jitsi, so I have to switch to H264 via preferH264 option.

While Safari works like a charm I can't get Firefox working. it returns the only VP8 codec in the local SDP. The weirdest thing that it works like a charm in https://safari.opentokrtc.com and has H264 codec inside the local SDP. I can't notice any difference between it and Jitsi setup.

This is Firefox 57.0 on macOS 10.13.1. Here is log for SDP:

Remote:

v=0
o=- 1923518516 2 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=group:BUNDLE audio-4279955460 video-394632305 data audio-2024687154 video-3620681355
a=msid-semantic:WMS *
m=audio 1 RTP/SAVPF 111 103 104 126
c=IN IP4 0.0.0.0
a=candidate:1 1 tcp 2130706431 2001:41d0:a:f84d:0:0:0:1 4443 typ host tcptype passive generation 0
a=candidate:2 1 tcp 2130706431 37.187.127.77 4443 typ host tcptype passive generation 0
a=candidate:3 1 udp 2113939711 2001:41d0:a:f84d:0:0:0:1 10000 typ host generation 0
a=candidate:4 1 udp 2113932031 37.187.127.77 10000 typ host generation 0
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=fingerprint:sha-1 C1:7E:BA:6C:48:3A:20:7B:F1:14:4E:D1:0E:61:2B:C6:4B:0F:ED:55
a=ice-pwd:17unprlo8or5o3dng3imetdp0r
a=ice-ufrag:2p8o21bvdpp24r
a=mid:audio-4279955460
a=msid:mixedmslabel mixedlabelaudio0
a=rtcp:1 IN IP4 0.0.0.0
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000/1
a=rtpmap:104 ISAC/32000/1
a=rtpmap:126 telephone-event/8000
a=setup:actpass
a=ssrc:4279955460 cname:mixed
a=ssrc:4279955460 label:mixedlabelaudio0
a=ssrc:4279955460 mslabel:mixedmslabel
m=video 1 RTP/SAVPF 107 100 101
c=IN IP4 0.0.0.0
a=candidate:1 1 tcp 2130706431 2001:41d0:a:f84d:0:0:0:1 4443 typ host tcptype passive generation 0
a=candidate:2 1 tcp 2130706431 37.187.127.77 4443 typ host tcptype passive generation 0
a=candidate:3 1 udp 2113939711 2001:41d0:a:f84d:0:0:0:1 10000 typ host generation 0
a=candidate:4 1 udp 2113932031 37.187.127.77 10000 typ host generation 0
a=sendrecv
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=fingerprint:sha-1 C1:7E:BA:6C:48:3A:20:7B:F1:14:4E:D1:0E:61:2B:C6:4B:0F:ED:55
a=ice-pwd:17unprlo8or5o3dng3imetdp0r
a=ice-ufrag:2p8o21bvdpp24r
a=mid:video-394632305
a=msid:mixedmslabel mixedlabelvideo0
a=rtcp:1 IN IP4 0.0.0.0
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:107 ccm fir
a=rtcp-fb:107 nack
a=rtcp-fb:107 nack pli
a=rtcp-fb:107 goog-remb
a=rtcp-fb:101 ccm fir
a=rtcp-fb:101 nack
a=rtcp-fb:101 nack pli
a=rtcp-fb:101 goog-remb
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtpmap:107 H264/90000
a=rtpmap:101 VP9/90000
a=setup:actpass
a=ssrc:394632305 cname:mixed
a=ssrc:394632305 label:mixedlabelvideo0
a=ssrc:394632305 mslabel:mixedmslabel
m=application 1 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=candidate:1 1 tcp 2130706431 2001:41d0:a:f84d:0:0:0:1 4443 typ host tcptype passive generation 0
a=candidate:2 1 tcp 2130706431 37.187.127.77 4443 typ host tcptype passive generation 0
a=candidate:3 1 udp 2113939711 2001:41d0:a:f84d:0:0:0:1 10000 typ host generation 0
a=candidate:4 1 udp 2113932031 37.187.127.77 10000 typ host generation 0
a=sendrecv
a=fingerprint:sha-1 C1:7E:BA:6C:48:3A:20:7B:F1:14:4E:D1:0E:61:2B:C6:4B:0F:ED:55
a=ice-pwd:17unprlo8or5o3dng3imetdp0r
a=ice-ufrag:2p8o21bvdpp24r
a=mid:data
a=rtcp-mux
a=sctpmap:5000 webrtc-datachannel 1024
a=setup:actpass
m=audio 1 RTP/SAVPF 111 103 104 126
c=IN IP4 0.0.0.0
a=candidate:1 1 tcp 2130706431 2001:41d0:a:f84d:0:0:0:1 4443 typ host tcptype passive generation 0
a=candidate:2 1 tcp 2130706431 37.187.127.77 4443 typ host tcptype passive generation 0
a=candidate:3 1 udp 2113939711 2001:41d0:a:f84d:0:0:0:1 10000 typ host generation 0
a=candidate:4 1 udp 2113932031 37.187.127.77 10000 typ host generation 0
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=fingerprint:sha-1 C1:7E:BA:6C:48:3A:20:7B:F1:14:4E:D1:0E:61:2B:C6:4B:0F:ED:55
a=ice-pwd:17unprlo8or5o3dng3imetdp0r
a=ice-ufrag:2p8o21bvdpp24r
a=mid:audio-2024687154
a=msid:036cd665-5e3e-46ad-adbb-b558166e7ecb 823e0b3b-e74e-49b0-a6a9-8e1166abd431
a=rtcp:1 IN IP4 0.0.0.0
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000/1
a=rtpmap:104 ISAC/32000/1
a=rtpmap:126 telephone-event/8000
a=setup:actpass
a=ssrc:2024687154 cname:3kpvpOtPTQ22bz1
m=video 1 RTP/SAVPF 107 100 101
c=IN IP4 0.0.0.0
a=candidate:1 1 tcp 2130706431 2001:41d0:a:f84d:0:0:0:1 4443 typ host tcptype passive generation 0
a=candidate:2 1 tcp 2130706431 37.187.127.77 4443 typ host tcptype passive generation 0
a=candidate:3 1 udp 2113939711 2001:41d0:a:f84d:0:0:0:1 10000 typ host generation 0
a=candidate:4 1 udp 2113932031 37.187.127.77 10000 typ host generation 0
a=sendrecv
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=fingerprint:sha-1 C1:7E:BA:6C:48:3A:20:7B:F1:14:4E:D1:0E:61:2B:C6:4B:0F:ED:55
a=ice-pwd:17unprlo8or5o3dng3imetdp0r
a=ice-ufrag:2p8o21bvdpp24r
a=mid:video-3620681355
a=msid:a57bd2fc-b05e-4b30-a17d-7357704ff1e7 2716ba70-0e4f-4dd9-b0fc-dd5be03aad77
a=rtcp:1 IN IP4 0.0.0.0
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:107 ccm fir
a=rtcp-fb:107 nack
a=rtcp-fb:107 nack pli
a=rtcp-fb:107 goog-remb
a=rtcp-fb:101 ccm fir
a=rtcp-fb:101 nack
a=rtcp-fb:101 nack pli
a=rtcp-fb:101 goog-remb
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtpmap:107 H264/90000
a=rtpmap:101 VP9/90000
a=setup:actpass
a=ssrc:3620681355 cname:3kpvpOtPTQ22bz1

Local:

v=0
o=mozilla...THIS_IS_SDPARTA-57.0 1470357373771936821 1 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 AD:F4:70:20:06:69:D6:F0:FE:48:34:0A:2F:BD:BC:A1:61:55:62:93:42:48:24:AB:90:8C:07:DA:6E:2E:F3:FB
a=group:BUNDLE audio-4279955460 video-394632305 data audio-2024687154 video-3620681355
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 51706 RTP/SAVPF 111 126
c=IN IP4 93.178.246.135
a=candidate:0 1 UDP 2122252543 192.168.0.100 51706 typ host
a=candidate:1 1 TCP 2105524479 192.168.0.100 9 typ host tcptype active
a=recvonly
a=end-of-candidates
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=fmtp:111 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:126 0-15
a=ice-pwd:157422a5909f3050fbb26a7a76610ed4
a=ice-ufrag:19f96971
a=mid:audio-4279955460
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtpmap:126 telephone-event/8000
a=setup:active
a=ssrc:3843323696 cname:{836df805-3925-194b-bd53-d5fb9067b761}
m=video 51706 RTP/SAVPF 100
c=IN IP4 93.178.246.135
a=recvonly
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=fmtp:100 max-fs=12288;max-fr=60
a=ice-pwd:157422a5909f3050fbb26a7a76610ed4
a=ice-ufrag:19f96971
a=mid:video-394632305
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 goog-remb
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=setup:active
a=ssrc:4135888019 cname:{836df805-3925-194b-bd53-d5fb9067b761}
m=application 51706 DTLS/SCTP 5000
c=IN IP4 93.178.246.135
a=sendrecv
a=ice-pwd:157422a5909f3050fbb26a7a76610ed4
a=ice-ufrag:19f96971
a=mid:data
a=rtcp-mux
a=sctpmap:5000 webrtc-datachannel 256
a=setup:active
a=max-message-size:1073741823
m=audio 51706 RTP/SAVPF 111 126
c=IN IP4 93.178.246.135
a=recvonly
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=fmtp:111 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:126 0-15
a=ice-pwd:157422a5909f3050fbb26a7a76610ed4
a=ice-ufrag:19f96971
a=mid:audio-2024687154
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtpmap:126 telephone-event/8000
a=setup:active
a=ssrc:1795029193 cname:{836df805-3925-194b-bd53-d5fb9067b761}
m=video 51706 RTP/SAVPF 100
c=IN IP4 93.178.246.135
a=recvonly
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=fmtp:100 max-fs=12288;max-fr=60
a=ice-pwd:157422a5909f3050fbb26a7a76610ed4
a=ice-ufrag:19f96971
a=mid:video-3620681355
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 goog-remb
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=setup:active
a=ssrc:3550091066 cname:{836df805-3925-194b-bd53-d5fb9067b761}

Another question: why do I have two pairs of audio/video on remoteDescription, since it's H264 and I have disableSimulcast: true?

[bbaldino]

Can you verify that you can get h264 working in firefox 57 on appr.tc? I tried and firefox did vp8 (as I mentioned in your thread on the mailing list) so I'm wondering if something is up with ffox 57.

You can force clients to use h264 in appr.tc by adding the following to the url: ?vsc=h264&vrc=h264, e.g.: https://appr.tc/r/h264test?vrc=h264&vsc=h264. Once in the call, you can press i to bring up in-call information (which will include the codec)

[bbaldino]

I did some more testing and was able to get firefox to do h264, but only if it was the offerer (not the answerer). Not sure what's going on there.

Firefox offers h264 with:

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

And chrome answers with
a=fmtp:126 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f

When chrome is the offerer, it offers:

a=fmtp:100 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=fmtp:107 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d0032
a=fmtp:109 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640032

But firefox only answers with vp8.

[bbaldino]

Ok, so the issue above is something minor and is related to apprtc, so we can ignore that. I'm wondering why the chrome offer doesn't include h264 profile information though...that may be what firefox is tripping up on. Can you try and have firefox be the offerer and see if that works?

[nils-ohlmeier]

If the a=fmtp parameters for the H264 PT's are really missing that would explain why Firefox does not choose them, as it doesn't have a clue which H264 profile the offer contains.

[Kukunin]

Is it the fault of jicofo? I can't find it adds a=fmtp for h264 https://github.com/jitsi/jicofo/blob/21f8270029eafc467395fe1cfa928c6ce69cd091/src/main/java/org/jitsi/jicofo/util/JingleOfferFactory.java

It sounds very plausible because there is a=fmtp in an SDP from the opentok.

Tried p2p between Safari and Firefox, and it works fine, because there is

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

in both local and remote SDPs.

I'm going to duplicate the issue in jicofo repository. I'd appreciate if anybody can write a quick patch here to workaround the problem until it gets fixes in the master

[bbaldino]

in JingleOfferFactory.java in jicofo, around this line, you'll need to add a parameter extension for h264. Since this has multiple key/values in one line, i think the easiest thing would be to just 'fake it' a bit, like so:

addParameterExtension(h264, "profile-level-id",  "42e01f;level-asymmetry-allowed=1;packetization-mode=1"

I think that should do it.

[sapkra]

If this is still an issue please open a new issue with updated details.