On Thu, 13 Jun 2019 at 18:48, Dominik Balogh <dom...@around.xyz
> 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:
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:
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).