search

EricssonResearch / openwebrtc

A cross-platform WebRTC client framework based on GStreamer
http://www.openwebrtc.org
BSD 2-Clause "Simplified" License
1.8k stars 537 forks source link

Checking H264 Capability on Firefox #425

Open tobeedelafuente opened 9 years ago

tobeedelafuente commented 9 years ago

Hello everyone,

Have you tried the H264 capability of Firefox? I connected the NativeDemo app for iOS with the Firefox browser. I checked the SDP data and it seems that it is still using VP8 a=rtpmap:120 VP8/90000

Based on the NativeDemo code, handleOfferReceived/handleAnswerReceived checks the encoding name and I always get "VP8"

I have tried using two iOS devices, both with A7 processor (since it supports the H264 hardware encoding) and I get H264 in the SDP data and on the code. However I expect that on Firefox the same behavior will happen. Any thoughts on this guys?

superdump commented 9 years ago

It is meant to be that if a codec is listed first by the offering party, the answering party is supposed to respect that ordering. This has meant so far that if you start a call from an OpenWebRTC client and the answering party is a Firefox client, H.264 has been used.

However, I have seen in Firefox release notes that some changes have been made to various WebRTC components that had some impact on the prioritisation such that VP8 would be chosen.

To be sure - what version of Firefox are you using and did you initiate the call from iOS?

tobeedelafuente commented 9 years ago

The Firefox version is 38.0.5. I have tried initiating from iOS and Firefox. Both goes to VP8. It seems that there must be some prioritization happening. Thank you for the information Robert. Do you think there is a possibility that H264 will be chosen?

superdump commented 9 years ago

https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes/40#Signaling:

https://bugzilla.mozilla.org/show_bug.cgi?id=1146529

So, if you try Firefox 40, it should be fixed.

tobeedelafuente commented 9 years ago

Thanks for the link. It seems that it is a limitation on the Firefox version I have. I will let you know if H.264 is being used. Currently the latest version on my side is at 38.0.5. No updates yet.

agouaillard commented 9 years ago

did you try to force firefox t ouse H264 in priority?

Firefox: Activate H.264 for WebRTC

Firefox: Set H.264 as default video codec in place of VP8

On Mon, Jun 29, 2015 at 9:53 PM, terence notifications@github.com wrote:

Thanks for the link. It seems that it is a limitation on the Firefox version I have. I will let you know if H.264 is being used. Currently the latest version on my side is at 38.0.5. No updates yet.

— Reply to this email directly or view it on GitHub https://github.com/EricssonResearch/openwebrtc/issues/425#issuecomment-116955704 .

Alex. Gouaillard, PhD, PhD, MBA

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

sg.linkedin.com/agouaillard

-

tobeedelafuente commented 9 years ago

Thank you very much. Setting media.navigator.video.preferred_codec to 126 worked like a charm! When I call using Firefox, the codec used was H264. However, the video feed is not being received from the browser. if I call using my iOS device, the codec was VP8 and I was able to get a video feed from the browser.

superdump commented 9 years ago

Can you check the SDP sent from iOS to Firefox? You should be able to see it in about:webrtc for the relevant session.

tobeedelafuente commented 9 years ago

Hi, on http://demo.openwebrtc.io:38080/ I got an "InvalidSessionDescriptionError: Failed to negotiate codec details for all codecs" error. Here is the SDP sent by Firefox: Local SDP v=0 o=mozilla...THIS_IS_SDPARTA-39.0 4294967295 0 IN IP4 0.0.0.0 s=- t=0 0 a=sendrecv a=fingerprint:sha-256 AC:4B:6B:AE:6C:F8:A0:4C:15:E3:95:28:97:E6:7E:66:16:EE:C1:F4:20:BB:59:FC:28:C2:A4:30:76:97:0C:4C a=group:BUNDLE sdparta_0 a=ice-options:trickle a=msid-semantic:WMS * m=video 58974 RTP/SAVPF 126 120 97 c=IN IP4 192.36.158.14 a=candidate:0 1 UDP 2128609535 192.168.255.214 54042 typ host a=candidate:0 2 UDP 2128609534 192.168.255.214 54043 typ host a=candidate:1 1 UDP 1692467199 125.252.71.190 54042 typ srflx raddr 192.168.255.214 rport 54042 a=candidate:1 2 UDP 1692467198 125.252.71.190 54043 typ srflx raddr 192.168.255.214 rport 54043 a=candidate:3 1 UDP 98631679 192.36.158.14 58974 typ relay raddr 192.36.158.14 rport 58974 a=candidate:3 2 UDP 98631678 192.36.158.14 53227 typ relay raddr 192.36.158.14 rport 53227 a=sendrecv a=end-of-candidates a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1 a=fmtp:120 max-fs=12288;max-fr=60 a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1 a=ice-pwd:80b9ec9a80d6d13fe47971a8d3861df1 a=ice-ufrag:9b2e9409 a=mid:sdparta_0 a=msid:{c9a3a036-defb-4a66-a71a-37820f12774b} {a30429cd-da56-486e-a35d-f83e3326afa0} a=rtcp-fb:126 nack a=rtcp-fb:126 nack pli a=rtcp-fb:126 ccm fir a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=rtcp-fb:97 nack a=rtcp-fb:97 nack pli a=rtcp-fb:97 ccm fir a=rtcp-mux a=rtpmap:126 H264/90000 a=rtpmap:120 VP8/90000 a=rtpmap:97 H264/90000 a=setup:actpass a=ssrc:2795552928 cname:{4355e617-e22e-40ec-bd60-120fa21e1ee2}

Here is the SDP sent by my iOS device: Remote SDP v=0 o=- 4294967295 1 IN IP4 127.0.0.1 s=- t=0 0 a=sendrecv m=video 1 RTP/SAVPF 126 c=IN IP4 0.0.0.0 a=candidate:1 1 UDP 2013266431 fe80::80ea:4dff:fe6f:c9d4 59742 typ host a=candidate:2 1 TCP 1019216383 fe80::80ea:4dff:fe6f:c9d4 0 typ host tcptype active a=candidate:3 1 TCP 1015022079 fe80::80ea:4dff:fe6f:c9d4 55012 typ host tcptype passive a=candidate:4 1 UDP 2013266431 192.168.254.231 49766 typ host a=candidate:5 1 TCP 1019216383 192.168.254.231 0 typ host tcptype active a=candidate:6 1 TCP 1015022079 192.168.254.231 55013 typ host tcptype passive a=candidate:7 1 UDP 2013266431 fe80::98:406b:8ad1:cd2 49767 typ host a=candidate:8 1 TCP 1019216383 fe80::98:406b:8ad1:cd2 0 typ host tcptype active a=candidate:9 1 TCP 1015022079 fe80::98:406b:8ad1:cd2 55014 typ host tcptype passive a=candidate:10 1 UDP 1677722111 125.252.71.190 49766 typ srflx raddr 192.168.254.231 rport 49766 a=candidate:11 1 TCP 847249919 125.252.71.190 0 typ srflx raddr 192.168.254.231 rport 0 tcptype active a=candidate:12 1 TCP 843055615 125.252.71.190 55013 typ srflx raddr 192.168.254.231 rport 55013 tcptype passive a=sendrecv a=fingerprint:sha-256 14:FF:74:FD:6E:AD:BF:B6:4D:7B:60:1A:F4:01:87:48:94:D4:95:DF:FA:9C:FE:0C:91:6F:97:62:B4:FCA3:80 a=ice-pwd:ydUc5SCcskzoU4MgGpq7pi a=ice-ufrag:ibhh a=rtcp-fb:126 nack pli a=rtcp-mux a=rtpmap:126 H264/90000 a=setup:active

And then also on XCode debug console I get: owr_session.c:555 _owr_session_emit_ice_state_changed:<OwrMediaSession@session> ICE failed to establish a connection!

agouaillard commented 9 years ago

it looks like your 126 codec is not sending the right stream. The SDPs look correct, now you either have to debug or to look at the exchange using wireshark to find the problem. likely a mode 0 / mode 1 discrepancy between the two clients h264 codecs.

On Tue, Jul 7, 2015 at 12:30 AM, terence notifications@github.com wrote:

Hi, on http://demo.openwebrtc.io:38080/ I got an "InvalidSessionDescriptionError: Failed to negotiate codec details for all codecs" error. Here is the SDP sent by Firefox: Local SDP v=0 o=mozilla...THIS_IS_SDPARTA-39.0 4294967295 0 IN IP4 0.0.0.0 s=- t=0 0 a=sendrecv a=fingerprint:sha-256 AC:4B:6B:AE:6C:F8:A0:4C:15:E3:95:28:97:E6:7E:66:16:EE:C1:F4:20:BB:59:FC:28:C2:A4:30:76:97:0C:4C a=group:BUNDLE sdparta_0 a=ice-options:trickle a=msid-semantic:WMS * m=video 58974 RTP/SAVPF 126 120 97 c=IN IP4 192.36.158.14 a=candidate:0 1 UDP 2128609535 192.168.255.214 54042 typ host a=candidate:0 2 UDP 2128609534 192.168.255.214 54043 typ host a=candidate:1 1 UDP 1692467199 125.252.71.190 54042 typ srflx raddr 192.168.255.214 rport 54042 a=candidate:1 2 UDP 1692467198 125.252.71.190 54043 typ srflx raddr 192.168.255.214 rport 54043 a=candidate:3 1 UDP 98631679 192.36.158.14 58974 typ relay raddr 192.36.158.14 rport 58974 a=candidate:3 2 UDP 98631678 192.36.158.14 53227 typ relay raddr 192.36.158.14 rport 53227 a=sendrecv a=end-of-candidates a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1 a=fmtp:120 max-fs=12288;max-fr=60 a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1 a=ice-pwd:80b9ec9a80d6d13fe47971a8d3861df1 a=ice-ufrag:9b2e9409 a=mid:sdparta_0 a=msid:{c9a3a036-defb-4a66-a71a-37820f12774b} {a30429cd-da56-486e-a35d-f83e3326afa0} a=rtcp-fb:126 nack a=rtcp-fb:126 nack pli a=rtcp-fb:126 ccm fir a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=rtcp-fb:97 nack a=rtcp-fb:97 nack pli a=rtcp-fb:97 ccm fir a=rtcp-mux a=rtpmap:126 H264/90000 a=rtpmap:120 VP8/90000 a=rtpmap:97 H264/90000 a=setup:actpass a=ssrc:2795552928 cname:{4355e617-e22e-40ec-bd60-120fa21e1ee2}

Here is the SDP sent by my iOS device: Remote SDP v=0 o=- 4294967295 1 IN IP4 127.0.0.1 s=- t=0 0 a=sendrecv m=video 1 RTP/SAVPF 126 c=IN IP4 0.0.0.0 a=candidate:1 1 UDP 2013266431 fe80::80ea:4dff:fe6f:c9d4 59742 typ host a=candidate:2 1 TCP 1019216383 fe80::80ea:4dff:fe6f:c9d4 0 typ host tcptype active a=candidate:3 1 TCP 1015022079 fe80::80ea:4dff:fe6f:c9d4 55012 typ host tcptype passive a=candidate:4 1 UDP 2013266431 192.168.254.231 49766 typ host a=candidate:5 1 TCP 1019216383 192.168.254.231 0 typ host tcptype active a=candidate:6 1 TCP 1015022079 192.168.254.231 55013 typ host tcptype passive a=candidate:7 1 UDP 2013266431 fe80::98:406b:8ad1:cd2 49767 typ host a=candidate:8 1 TCP 1019216383 fe80::98:406b:8ad1:cd2 0 typ host tcptype active a=candidate:9 1 TCP 1015022079 fe80::98:406b:8ad1:cd2 55014 typ host tcptype passive a=candidate:10 1 UDP 1677722111 125.252.71.190 49766 typ srflx raddr 192.168.254.231 rport 49766 a=candidate:11 1 TCP 847249919 125.252.71.190 0 typ srflx raddr 192.168.254.231 rport 0 tcptype active a=candidate:12 1 TCP 843055615 125.252.71.190 55013 typ srflx raddr 192.168.254.231 rport 55013 tcptype passive a=sendrecv a=fingerprint:sha-256 14:FF:74:FD:6E:AD:BF:B6:4D:7B:60:1A:F4:01:87:48:94:D4:95:DF:FA:9C:FE:0C:91:6F:97:62:B4:FCA3:80 a=ice-pwd:ydUc5SCcskzoU4MgGpq7pi a=ice-ufrag:ibhh a=rtcp-fb:126 nack pli a=rtcp-mux a=rtpmap:126 H264/90000 a=setup:active

And then also on XCode debug console I get: owr_session.c:555 _owr_session_emit_ice_state_changed:OwrMediaSession@session ICE failed to establish a connection!

— Reply to this email directly or view it on GitHub https://github.com/EricssonResearch/openwebrtc/issues/425#issuecomment-119103783 .

Alex. Gouaillard, PhD, PhD, MBA

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

sg.linkedin.com/agouaillard

-

Anshumakkar commented 8 years ago

Hi All, I have followed the steps to set H264 as preffered codec, but still in Offer SDP H264 is not set as preffered Codec Browser: Mozilla Client:SIPML5

setRemoteDescription(answer) v=0

o=doubango 1983 678902 IN IP4 107.108.209.65 s=- c=IN IP4 107.108.209.65 t=0 0 a=fingerprint:sha-256 F8:FE:A9:76:AA:D8:D1:ED:8E:57:1D:AB:B3:A8:D9:B8:4A:1C:BA:79:42:7D:9A:60:3F:B8:64:79:FE:8B:01:91 a=setup:passive m=audio 58812 RTP/SAVPF 109 0 8 c=IN IP4 107.108.209.65 a=ptime:20 a=minptime:1 a=maxptime:255 a=silenceSupp:off - - - - a=rtpmap:109 opus/48000/2 a=fmtp:109 maxplaybackrate=48000; sprop-maxcapturerate=48000; stereo=0; sprop-stereo=0; useinbandfec=0; usedtx=0 a=rtpmap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/1 a=sendrecv a=rtcp-mux a=ssrc:3429756533 cname:(null) a=ssrc:3429756533 mslabel:6994f7d1-6ce9-4fbd-acfd-84e5131ca2e2 a=ssrc:3429756533 label:doubango@audio a=ice-ufrag:2AjoRYCJUwpHAcX a=ice-pwd:bniafkiJo2SD1s7koa22Bh a=candidate:5byaTNcK9p7Iy24 1 udp 2130706431 107.108.209.65 58812 typ host tr udp fd 22 m=video 35560 RTP/SAVPF 120 126 c=IN IP4 107.108.209.65 a=rtcp-fb:* ccm fir a=rtcp-fb:* nack a=rtcp-fb:* goog-remb a=label:42 a=content:main a=rtpmap:120 VP8/90000 a=imageattr:120 recv [x=[128:16:640],y=[96:16:480]] send [x=[128:16:640],y=[96:16:480]] a=rtpmap:126 H264/90000 a=imageattr:126 recv [x=[128:16:640],y=[96:16:480]] send [x=[128:16:640],y=[96:16:480]] a=fmtp:126 profile-level-id=428016;max-mbps=20250;max-fs=1200;packetization-mode=1; impl=FFMPEG a=sendrecv a=rtcp-mux a=ssrc:3385069209 cname:(null) a=ssrc:3385069209 mslabel:6994f7d1-6ce9-4fbd-acfd-84e5131ca2e2 a=ssrc:3385069209 label:doubango@video a=ice-ufrag:Kec6toZis5hXJjA a=ice-pwd:hEZdpSSsymFc9KZ6MXteDM a=candidate:AS8a3DWEWKIx8sn 1 udp 2130706431 107.108.209.65 35560 typ host tr udp fd 25

Ruedii commented 6 years ago

It depends what you are wanting to use H.264 for.

For basic media playback it is usually enabled by default.

For RTC it is not enabled by default, specifically due to patent licensing concerns with the MPEG encoder.

To enable the decoding for WebRTC Set the following in about:config. media.peerconnection.video.h264_enabled to true

There are also some other settings for ICE and MP4 that are required to run h.264

As a note I recommend VP9 over h.264 if the codec, all other factors equal. However, there are going to be situations where h.264 will be preferred due to hardware acceleration or limitations on the other end, or just wanting to test the possibilities because of these cases.