GPU accelerated H.264 on Mediasoup

255 views
Skip to first unread message

Dominik Balogh

unread,
Jun 11, 2019, 6:51:31 PM6/11/19
to mediasoup
When testing the H.264 reference app (apprtc.tc) with parameter ?vrc=H264, the H.264 codec is enforced.

In a P2P connection with another user, it seems (based on the very low CPU usage) that the GPU is doing most of the heavy-lifting, as it should.

This is on a MacBook Pro (2017) that supports GPU accelerated H.264 and latest Chrome.

We're not able to reach such performance when Mediasoup facilitates the connection between 2 clients (as opposed to AppRTC P2P mode). My hypothesis is that when Mediasoup is between two clients, some H.264 profile/codec information is not passed over correctly, while Chrome and the OS needs some specific flags to enable hardware acceleration, so instead Chrome uses software-based decoding on the CPU (which increases CPU use and decreases battery life). This is just an idea -- I might be misunderstanding something completely.

Any suggestion on where to look to explore this?

Thank you
Dominik

Iñaki Baz Castillo

unread,
Jun 11, 2019, 7:06:25 PM6/11/19
to medi...@googlegroups.com
On Wed, 12 Jun 2019 at 00:51, Dominik Balogh <dom...@around.xyz> wrote:

> We're not able to reach such performance when Mediasoup facilitates the connection between 2 clients (as opposed to AppRTC P2P mode). My hypothesis is that when Mediasoup is between two clients, some H.264 profile/codec information is not passed over correctly, while Chrome and the OS needs some specific flags to enable hardware acceleration, so instead Chrome uses software-based decoding on the CPU (which increases CPU use and decreases battery life). This is just an idea -- I might be misunderstanding something completely.

No idea how to enable H264 hardware acceleration, but you can pass any
proprietary constraint to the underlying PeerConnection in
mediasoup-client when creating a send or recv Transport:

https://mediasoup.org/documentation/v3/mediasoup-client/api/#TransportOptions

If you figure out how to enable H264 hardware acceleration by passing
a proprietary constrain to the peerconnection, don't hesitase to post
it here.

Regarding H264 profile/codec information, you can configure whichever
codec parameters you wish in the mediasoup Router, including H264
packetization-mode and profile-level-id.

Also, I don't think AppRTC enables H264 simulcast (since it's a P2P
call) so it just encodes the video once instead of 3 times.


PS: Please use the new mediasoup Discourse forum instead of this mailing list:
https://mediasoup.discourse.group/



--
Iñaki Baz Castillo
<i...@aliax.net>

Dominik Balogh

unread,
Jun 13, 2019, 12:48:15 PM6/13/19
to mediasoup
Thank you! That seems right -- would you be able to share a proprietary constraint e.g. to pass/force packetization-mode? We're not sure how to properly use the constraints because there is no (we haven't found) any documentation or examples for it.

Iñaki Baz Castillo

unread,
Jun 13, 2019, 1:05:03 PM6/13/19
to medi...@googlegroups.com
On Thu, 13 Jun 2019 at 18:48, Dominik Balogh <dom...@around.xyz> wrote:
>
> Thank you! That seems right -- would you be able to share a proprietary constraint e.g. to pass/force packetization-mode? We're not sure how to properly use the constraints because there is no (we haven't found) any documentation or examples for it.

Honestly I have no idea about how to enable H264 hardcode encoding
and/or decoding in Chrome OSX, neither I know whether it's possible or
not (may be Chrome already uses it). I did a quick search yesterday
and found nothing. BTW if you open chrome://flags (in OSX) you'll see
that there is an already enabled "Hardware-accelerated video decode"
option (no idea if it's for WebRTC H264 or not, but that's not
something AppRTC can enable/disable via JS, I hope).


I also checked what AppRTC negotiates at SDP level (by checking
chrome://webrtc-internals) when H264 is forced and found absolutely
nothing unusual. Both the caller and the callee use their default SDP
without mangling the H264 codecs at all.

I don't know if the performance is related to which packetization-mode
and/or profile-level-id is finally negotiated (you can check which one
has been chosen in chrome://webrtc-internals by checking the selected
codec, its payload typer number, and then matching that PT in the SDP.

Anyway, mediasoup does a super proper H264 parameters matching. I
wrote h264-profile-level-id library for that purpose and both
mediasoup and mediasoup-client use it to properly match the Router
H264 enabled codec in preference order:

https://mediasoup.org/documentation/v3/mediasoup/rtp-parameters-and-capabilities/#H264

I know that the H264 parameters stuff is a pain nobody understands and
it's unclear what each value pair does. I can just guarantee that
mediasoup negotiates them correctly, so if you discover that Chrome
behaves different by using a specific packetization-mode +
profile-level-id pair, you can set those values in the mediasoup
Router H264 media codec and those will be used by Chrome (for sending
and receiving H264 streams). More info here:

https://mediasoup.org/documentation/v3/mediasoup/rtp-parameters-and-capabilities/#H264


Anyway, as told in my previous email, you may disable simulcast (which
I assume AppRTC does not use since it's a P2P application) and see how
it behaves at performance/CPU level (obviously it will encode just a
single video stream instead of 3, so less CPU usage).

Pavel Serbajlo

unread,
Jun 13, 2019, 1:21:13 PM6/13/19
to mediasoup
I did a few tests here, considering the CPU usage difference is quite noticeable when encoding with HW acceleration.


Firstly, I generated an offer and modified in a way that there's just one video codec left: H264 with payloadType 102:

a=rtpmap:102 H264/90000
a
=rtcp-fb:102 goog-remb
a
=rtcp-fb:102 transport-cc
a
=rtcp-fb:102 ccm fir
a
=rtcp-fb:102 nack
a
=rtcp-fb:102 nack pli
a
=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a
=rtpmap:122 rtx/90000
a
=fmtp:122 apt=102


I generated appropriate answer and set it. Connection was successful and I could see in webrtc-internals that ExternalEncoder is properly used instead of SW-based OpenH264.


I checked on what exactly is mediasoup (v2) doing at the moment.

I'm checking this object after succesfull connection between mediasoup and mediasoup-client:

console.log(this.sendTransport._handler._pc);


from here, I can see localDescription sdp:

v=0
o
=- 2004693108821861147 3 IN IP4 127.0.0.1
s
=-
t
=0 0
a
=group:BUNDLE 0 1
a
=msid-semantic: WMS
m
=audio 59667 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c
=IN IP4 192.168.100.23
a
=rtcp:9 IN IP4 0.0.0.0
a
=candidate:3865830378 1 udp 2113937151 192.168.100.23 59667 typ host generation 0 network-cost 999
a
=ice-ufrag:kR9h
a
=ice-pwd:caEAAyOBz5XAiE4wy0LtyXJI
a
=ice-options:trickle
a
=fingerprint:sha-256 41:F2:B2:5E:0A:35:E2:46:8E:C8:FC:65:56:09:C4:F3:60:98:21:89:7A:A4:ED:D0:F6:1F:62:82:5B:E5:0A:B6
a
=setup:actpass
a
=mid:0
a
=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a
=extmap:2 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a
=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a
=extmap:4 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a
=extmap:5 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a
=sendonly
a
=msid:- 6e0954e1-c80d-47a1-a1bc-a67b65307b62
a
=rtcp-mux
a
=rtpmap:111 opus/48000/2
a
=rtcp-fb:111 transport-cc
a
=fmtp:111 minptime=10;useinbandfec=1
a
=rtpmap:103 ISAC/16000
a
=rtpmap:104 ISAC/32000
a
=rtpmap:9 G722/8000
a
=rtpmap:0 PCMU/8000
a
=rtpmap:8 PCMA/8000
a
=rtpmap:106 CN/32000
a
=rtpmap:105 CN/16000
a
=rtpmap:13 CN/8000
a
=rtpmap:110 telephone-event/48000
a
=rtpmap:112 telephone-event/32000
a
=rtpmap:113 telephone-event/16000
a
=rtpmap:126 telephone-event/8000
a
=ssrc:1494847607 cname:QGoOSNsHFGeXJ+OW
a
=ssrc:1494847607 msid:- 6e0954e1-c80d-47a1-a1bc-a67b65307b62
a
=ssrc:1494847607 mslabel:-
a
=ssrc:1494847607 label:6e0954e1-c80d-47a1-a1bc-a67b65307b62
m
=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116
c
=IN IP4 0.0.0.0
a
=rtcp:9 IN IP4 0.0.0.0
a
=ice-ufrag:kR9h
a
=ice-pwd:caEAAyOBz5XAiE4wy0LtyXJI
a
=ice-options:trickle
a
=fingerprint:sha-256 41:F2:B2:5E:0A:35:E2:46:8E:C8:FC:65:56:09:C4:F3:60:98:21:89:7A:A4:ED:D0:F6:1F:62:82:5B:E5:0A:B6
a
=setup:actpass
a
=mid:1
a
=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a
=extmap:13 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a
=extmap:12 urn:3gpp:video-orientation
a
=extmap:2 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a
=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a
=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a
=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a
=extmap:8 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a
=extmap:9 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a
=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a
=extmap:4 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a
=extmap:5 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a
=sendonly
a
=msid:- 015a425e-f9f2-40ab-acbf-1fc87b42ce71
a
=rtcp-mux
a
=rtcp-rsize
a
=rtpmap:96 VP8/90000
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
=rtpmap:97 rtx/90000
a
=fmtp:97 apt=96
a
=rtpmap:98 VP9/90000
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 profile-id=0
a
=rtpmap:99 rtx/90000
a
=fmtp:99 apt=98
a
=rtpmap:100 VP9/90000
a
=rtcp-fb:100 goog-remb
a
=rtcp-fb:100 transport-cc
a
=rtcp-fb:100 ccm fir
a
=rtcp-fb:100 nack
a
=rtcp-fb:100 nack pli
a
=fmtp:100 profile-id=2
a
=rtpmap:101 rtx/90000
a
=fmtp:101 apt=100
a
=rtpmap:102 H264/90000
a
=rtcp-fb:102 goog-remb
a
=rtcp-fb:102 transport-cc
a
=rtcp-fb:102 ccm fir
a
=rtcp-fb:102 nack
a
=rtcp-fb:102 nack pli
a
=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a
=rtpmap:122 rtx/90000
a
=fmtp:122 apt=102
a
=rtpmap:127 H264/90000
a
=rtcp-fb:127 goog-remb
a
=rtcp-fb:127 transport-cc
a
=rtcp-fb:127 ccm fir
a
=rtcp-fb:127 nack
a
=rtcp-fb:127 nack pli
a
=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a
=rtpmap:121 rtx/90000
a
=fmtp:121 apt=127
a
=rtpmap:125 H264/90000
a
=rtcp-fb:125 goog-remb
a
=rtcp-fb:125 transport-cc
a
=rtcp-fb:125 ccm fir
a
=rtcp-fb:125 nack
a
=rtcp-fb:125 nack pli
a
=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a
=rtpmap:107 rtx/90000
a
=fmtp:107 apt=125
a
=rtpmap:108 H264/90000
a
=rtcp-fb:108 goog-remb
a
=rtcp-fb:108 transport-cc
a
=rtcp-fb:108 ccm fir
a
=rtcp-fb:108 nack
a
=rtcp-fb:108 nack pli
a
=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a
=rtpmap:109 rtx/90000
a
=fmtp:109 apt=108
a
=rtpmap:124 H264/90000
a
=rtcp-fb:124 goog-remb
a
=rtcp-fb:124 transport-cc
a
=rtcp-fb:124 ccm fir
a
=rtcp-fb:124 nack
a
=rtcp-fb:124 nack pli
a
=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d0032
a
=rtpmap:120 rtx/90000
a
=fmtp:120 apt=124
a
=rtpmap:123 H264/90000
a
=rtcp-fb:123 goog-remb
a
=rtcp-fb:123 transport-cc
a
=rtcp-fb:123 ccm fir
a
=rtcp-fb:123 nack
a
=rtcp-fb:123 nack pli
a
=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640032
a
=rtpmap:119 rtx/90000
a
=fmtp:119 apt=123
a
=rtpmap:114 red/90000
a
=rtpmap:115 rtx/90000
a
=fmtp:115 apt=114
a
=rtpmap:116 ulpfec/90000
a
=ssrc-group:FID 3099793010 1042967607
a
=ssrc:3099793010 cname:QGoOSNsHFGeXJ+OW
a
=ssrc:3099793010 msid:- 015a425e-f9f2-40ab-acbf-1fc87b42ce71
a
=ssrc:3099793010 mslabel:-
a
=ssrc:3099793010 label:015a425e-f9f2-40ab-acbf-1fc87b42ce71
a
=ssrc:1042967607 cname:QGoOSNsHFGeXJ+OW
a
=ssrc:1042967607 msid:- 015a425e-f9f2-40ab-acbf-1fc87b42ce71
a
=ssrc:1042967607 mslabel:-
a
=ssrc:1042967607 label:015a425e-f9f2-40ab-acbf-1fc87b42ce71


and remoteDescription sdp:

v=0
o
=- 26696567 2 IN IP4 127.0.0.1
s
=-
t
=0 0
a
=group:BUNDLE 0 1
a
=msid-semantic: WMS
a
=ice-lite
m
=audio 10002 RTP/SAVPF 111
c
=IN IP4 192.168.100.23
a
=rtcp:9 IN IP4 0.0.0.0
a
=candidate:udpcandidate 1 udp 1080142079 192.168.100.23 10002 typ host generation 0
a
=candidate:tcpcandidate 1 tcp 1078862079 192.168.100.23 10045 typ host tcptype passive generation 0
a
=ice-ufrag:6hgmzd35s5m7imu9
a
=ice-pwd:z21zcq4udark7n3a8zi0pv5bef8pw44z
a
=ice-options:renomination
a
=fingerprint:sha-512 91:71:8E:63:C3:BB:28:3E:35:56:E6:7F:EA:8B:DA:E3:D5:26:AB:53:29:A2:71:56:8D:3E:29:36:14:91:78:14:3A:93:33:9B:3D:E0:21:E0:1F:1C:A6:C5:FD:A7:3C:85:83:C8:46:B7:21:ED:17:CF:1F:6F:C8:F3:91:07:2D:F3
a
=setup:active
a
=mid:0
a
=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a
=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a
=recvonly
a
=rtcp-mux
a
=rtcp-rsize
a
=rtpmap:111 opus/48000/2
a
=fmtp:111 cbr=1;useinbandfec=1
m
=video 10002 RTP/SAVPF 102 122
c
=IN IP4 192.168.100.23
a
=rtcp:9 IN IP4 0.0.0.0
a
=candidate:udpcandidate 1 udp 1080142079 192.168.100.23 10002 typ host generation 0
a
=candidate:tcpcandidate 1 tcp 1078862079 192.168.100.23 10045 typ host tcptype passive generation 0
a
=ice-ufrag:6hgmzd35s5m7imu9
a
=ice-pwd:z21zcq4udark7n3a8zi0pv5bef8pw44z
a
=ice-options:renomination
a
=fingerprint:sha-512 91:71:8E:63:C3:BB:28:3E:35:56:E6:7F:EA:8B:DA:E3:D5:26:AB:53:29:A2:71:56:8D:3E:29:36:14:91:78:14:3A:93:33:9B:3D:E0:21:E0:1F:1C:A6:C5:FD:A7:3C:85:83:C8:46:B7:21:ED:17:CF:1F:6F:C8:F3:91:07:2D:F3
a
=setup:active
a
=mid:1
a
=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a
=extmap:13 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a
=extmap:12 urn:3gpp:video-orientation
a
=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a
=extmap:4 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a
=recvonly
a
=rtcp-mux
a
=rtcp-rsize
a
=rtpmap:102 H264/90000
a
=rtcp-fb:102 goog-remb
a
=rtcp-fb:102 ccm fir
a
=rtcp-fb:102 nack
a
=rtcp-fb:102 nack pli
a
=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a
=rtpmap:122 rtx/90000
a
=fmtp:122 apt=102



Trying to put these into the Munge SDP app causes errors and connection is not estabilished there. But it works in our app with mediasoup. Not sure if it's caused by the fact mediasoup uses ice lite?
Anyway, the only video codec paired in offer and answer is H264 with payloadType 102, which is the same one which works properly in the original Munge SDP test above. You can see the only difference is the congestion control parameter "transport-cc", which is being offered by mediasoup-client, but not answered with by mediasoup. I'm not sure if this could cause some stress to Chrome, though.

How do we need to modify the SDPs to make it work in Munge SDP so that we can experiment further?

Iñaki Baz Castillo

unread,
Jun 13, 2019, 1:25:55 PM6/13/19
to medi...@googlegroups.com
The important thing is the SDP answer that is passed to setRemoteDescription. The answer is what enables or disables things. Can you add "pack": "" in mediasoup H264 codec "parameters" and verify whether it's used to generate the SDP answer in Chrome?

Note: mediasoup v3 does a MUCH BETTER codec matching than v2, in which h264 is not properly negotiated at all.


a
=rtcp-fb:123 goog<span st

Pavel Serbajlo

unread,
Jun 13, 2019, 1:33:02 PM6/13/19
to mediasoup
This is the test config:

export const MediaRoomConfig = [
 
{
    kind        
: 'audio',
    name        
: 'opus',
    clockRate  
: 48000,
    payloadType
: 100,
    channels    
: 2,
    parameters
: {
      useinbandfec
: 1,
      cbr
: 1,
   
}
 
},
 
{
    kind        
: 'video',
    name        
: 'h264',
    clockRate  
: 90000,
    payloadType
: 102,
    parameters  
: {
     
'level-asymmetry-allowed': 1,
     
'packetization-mode': 1,
     
'profile-level-id': '42001f',
     
'pack': '',
   
}
 
},
];



remoteDescription sdp:

v=0
o
=- 44875999 2 IN IP4 127.0.0.1

s
=-
t
=0 0
a
=group:BUNDLE 0 1
a
=msid-semantic:
WMS
a
=ice-lite
m
=audio 10074 RTP/SAVPF 111

c
=IN IP4 192.168.100.23
a
=rtcp:9 IN IP4 0.0.0.0

a
=candidate:udpcandidate 1 udp 1080142079 192.168.100.23 10074 typ host generation 0
a
=candidate:tcpcandidate 1 tcp 1078862079 192.168.100.23 10069 typ host tcptype passive generation 0
a
=ice-ufrag:2louvhj5o5mz2qyl
a
=ice-pwd:7qljoqgm527cz7zqgnm4t713efc5k48f
a
=ice-options:renomination
a
=fingerprint:sha-512 BA:4D:93:46:80:AD:AC:F1:2C:6E:B3:EC:23:DA:A2:C9:9A:48:D6:42:67:4B:6F:B1:D1:A4:D9:DA:6A:55:3F:C6:90:BD:78:72:74:09:14:83:4D:BD:CE:F1:EA:93:D9:46:F5:6F:91:66:10:E3:E0:1E:B0:15:FD:F8:C6:A1:FE:CC
a
=setup:active
a
=mid:0

a
=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-
level
a
=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a
=recvonly
a
=rtcp-mux
a
=rtcp-rsize
a
=rtpmap:111 opus/48000/2
a
=fmtp:111 cbr=1;useinbandfec=1
m
=video 10074 RTP/SAVPF 102 122

c
=IN IP4 192.168.100.23
a
=rtcp:9 IN IP4 0.0.0.0

a
=candidate:udpcandidate 1 udp 1080142079 192.168.100.23 10074 typ host generation 0
a
=candidate:tcpcandidate 1 tcp 1078862079 192.168.100.23 10069 typ host tcptype passive generation 0
a
=ice-ufrag:2louvhj5o5mz2qyl
a
=ice-pwd:7qljoqgm527cz7zqgnm4t713efc5k48f
a
=ice-options:renomination
a
=fingerprint:sha-512 BA:4D:93:46:80:AD:AC:F1:2C:6E:B3:EC:23:DA:A2:C9:9A:48:D6:42:67:4B:6F:B1:D1:A4:D9:DA:6A:55:3F:C6:90:BD:78:72:74:09:14:83:4D:BD:CE:F1:EA:93:D9:46:F5:6F:91:66:10:E3:E0:1E:B0:15:FD:F8:C6:A1:FE:CC
a
=setup:active
a
=mid:1

a
=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a
=extmap:13 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a
=extmap:12 urn:3gpp:video-
orientation
a
=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a
=extmap:4 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a
=recvonly
a
=rtcp-mux
a
=rtcp-rsize
a
=rtpmap:102 H264/90000
a
=rtcp-fb:102 goog-remb
a
=rtcp-fb:102 ccm fir
a
=rtcp-fb:102 nack
a
=rtcp-fb:102 nack pli
a
=fmtp:102 level-asymmetry-allowed=1;pack=;packetization-mode=1;profile-level-id=42001f

a
=rtpmap:122 rtx/90000
a
=fmtp:122 apt=102


pack is there. If I understand the coded matching, does it mean there's a possibility the only video codec from the answer is matched to some incorrect offered codec? (Other than the payload 102).

Iñaki Baz Castillo

unread,
Jun 13, 2019, 2:15:30 PM6/13/19
to medi...@googlegroups.com
Will answer tomorrow, already out today :)

cc
a</

Iñaki Baz Castillo

unread,
Jun 14, 2019, 6:07:21 AM6/14/19
to medi...@googlegroups.com
Hi Pavel, Dominik,

Here my research about this:

https://mediasoup.discourse.group/t/h264-openh264-externalencoder-in-chrome/85
> --
> mediasoup
> Cutting Edge WebRTC Video Conferencing
>
> https://mediasoup.org
>
> NOTE: This group is deprecated. Use the mediasoup Discourse Group instead:
>
> https://mediasoup.discourse.group
> ---
> You received this message because you are subscribed to the Google Groups "mediasoup" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mediasoup+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mediasoup/7f1ef7e1-0a85-4382-a850-25dcd60978c0%40googlegroups.com.

Iñaki Baz Castillo

unread,
Jun 14, 2019, 6:12:32 PM6/14/19
to medi...@googlegroups.com
On Fri, 14 Jun 2019 at 12:07, Iñaki Baz Castillo <i...@aliax.net> wrote:
>
> Hi Pavel, Dominik,
>
> Here my research about this:
>
> https://mediasoup.discourse.group/t/h264-openh264-externalencoder-in-chrome/85

In addition, I've found a bug in Chrome when using the H264 ExternalEncoder:

https://bugs.chromium.org/p/webrtc/issues/detail?id=10746

Iñaki Baz Castillo

unread,
Jun 14, 2019, 6:23:54 PM6/14/19
to medi...@googlegroups.com
And you may wish to know that, if H264 ExternalEncoder is used (so OSX
hardware encoder) Chrome does not generate simulcast but a single H264
RTP stream:

https://bugs.chromium.org/p/webrtc/issues/detail?id=10747
Reply all
Reply to author
Forward
0 new messages