I don't know how to solve this in Chrome and inform clients if the codecs are HW or SW. Other WebRTC clients besides Chrome typically know what codecs are hardware accelerated because they are injecting those HW codecs into PeerConnectionFactory themselves. What we could do in Chrome is to list the HW codecs before the SW codecs so that they are preferred by default. I tried to do this in CL https://codereview.webrtc.org/2974383002/, but that broke stuff and I'm pretty sure people will complain about this when the default changes.

How do you want to solve this? I haven't been working with Chrome or H264 in a long while and I don't want to spend a lot of time on this. I only enabled more H264 profiles in WebRTC to help you out. I still want the WebRTC-in-Chrome team to own this.

For the short term, what about not offering high in Chrome and having baseline with higher prio than CBP? 

Actually for a short term solution, I can add a high profile support in HW after testing. 

Both suggestions in #2 and #3 sounds good to me. #2 sounds easy, should we do that first so we can update the HW codecs in peace?

Adding high support would be nice, but nothing we want to merge to 63, so I agree with #4.

Adding high and main support to Mac HW encoder works as far as I tested via sdp munge. Here is the CL: https://chromium-review.googlesource.com/c/chromium/src/+/743023 Note that Windows also added high and CrOS had it for a long time although not really tested.

magjed@, #2 would be webrtc change as those are internal codecs. Can you take a look at that? 
https://webrtc-review.googlesource.com/c/src/+/6341/5/modules/video_coding/codecs/h264/h264.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/98a22d8fe63b2dfa16c37c955c357835280adcf5

commit 98a22d8fe63b2dfa16c37c955c357835280adcf5
Author: Emircan Uysaler <emircan@chromium.org>
Date: Mon Oct 30 19:42:35 2017

Add more H264 profiles to VTVideoEncodeAccelerator

This CL adds MAIN and HIGH profile support.

Bug:  779246 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I5af448a35d2e8dfa97e0f30ea988f64ce74ad1ea
Reviewed-on: https://chromium-review.googlesource.com/743023
Reviewed-by: Magnus Jedvert <magjed@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#512583}
[modify] https://crrev.com/98a22d8fe63b2dfa16c37c955c357835280adcf5/media/gpu/vt_video_encode_accelerator_mac.cc
[modify] https://crrev.com/98a22d8fe63b2dfa16c37c955c357835280adcf5/media/gpu/vt_video_encode_accelerator_mac.h

Is the main issue this is tracking solved now, or do we have more P1 work to do?

afaik this should be fixed now.