Associated issues for reference:

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

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

Fix of this issue is very critical for our project! Please help! 

We need this fix

This fix very important for us.

This fix is very important for my project.

Our project is blocked with this bug. Please help.

Finally... Guys from Chrome team development - pls fix it ASAP. Our app can't work without this part.

Please fix this bug. Block project issues 

Our project is blocked with this bug too. Please fix

Please, fix it.

Fix of this issue is very critical for our project! Please help! 

Please fix it! Our project dont work without this feature

Magnus, can you take a look? Is this a bug, or WAI?

It's a feature request to support H264 High Profile. Chrome only supports Constrained Baseline at the moment. I think the actual H264 decoder in Chrome often (or always) supports High profile, so it's a matter of reporting the correct supported profile to WebRTC from RTCVideoEncoderFactory. I will try to find time to fix this.

magjed@chromium.org This is about Chrome h.264 encoding at a profile other than Baseline or Main; decoding h.264 was not specified.

@magjed@chromium.org did you have further questions about this bug? It seemed you were confused, as you were mentioning decoding support for high profile in Chrome. We are well aware that that works. In this case we are requesting (via Answer SDP) that Chrome encode with high profile, and that doesn't work. Let us know if you need further clarification. 

Chrome does not officially support decoding anything other than constrained baseline. If you negotiate constrained baseline but send high profile anyway, decoding might work in Chrome, but this behavior is not officially supported.

We might add support for encoding high profile when we have HW encoders that support it. I don't think we have any plan of adding high profile SW encode support.

@magjed@chromium.org well thanks for letting us know. It's unfortunate this isn't a priority, especially considering Safari's new implementation lacks support for any other protocols than h.264. Plus, hey, Firefox already supports high profile encoding, shouldn't Chrome be one step ahead of those guys. :)

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

commit 829b1d57525c3c6549d18a2c85a96527d59ea5e9
Author: magjed <magjed@chromium.org>
Date: Fri Jul 07 10:17:45 2017

Reland of RTCVideoEncoder: Report H264 profile information to WebRTC (patchset #1 id:1 of https://codereview.chromium.org/2521923002/ )

Reason for revert:
Try again.

Original issue's description:
> Revert of RTCVideoEncoder: Report H264 profile information to WebRTC (patchset #3 id:60001 of https://codereview.chromium.org/2499973002/ )
>
> Reason for revert:
> Causes these tests to fail on chromium.webrtc bots for Win and Mac:
> WebRtcPerfBrowserTest.MANUAL_RunsAudioVideoCall60SecsAndLogsInternalMetricsH264
> WebRtcVideoQualityBrowserTests/WebRtcVideoQualityBrowserTest.MANUAL_TestVideoQualityH264
> https://build.chromium.org/p/chromium.webrtc/builders/Win8%20Tester/builds/30367
> https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/62661
>
> Original issue's description:
> > RTCVideoEncoder: Report H264 profile information to WebRTC
> >
> > This CL updates RTCVideoEncoderFactory to report cricket::VideoCodecs
> > instead of WebRtcVideoEncoderFactory::VideoCodecs. The H264 profile
> > information is added to the cricket::VideoCodec so that WebRTC receives
> > this information. Also, the mapping between media::VideoCodecProfiles
> > and cricket::VideoCodecs is cached so that we can send the
> > media::VideoCodecProfile to RTCVideoEncoder instead of having to deal
> > with webrtc::VideoCodecType.
> >
> > BUG= webrtc:6337 
> >
> > Committed: https://crrev.com/510eddede44cb4b67c8f17fdd68cefb780a668c5
> > Cr-Commit-Position: refs/heads/master@{#433508}
>
> TBR=emircan@chromium.org,posciak@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG= webrtc:6337 
>
> Committed: https://crrev.com/c2564bc627cb950b124ac8e41bc5fd3187f7ad9c
> Cr-Commit-Position: refs/heads/master@{#433828}

TBR=emircan@chromium.org,posciak@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 688541 , 735959 

Review-Url: https://codereview.chromium.org/2548443002
Cr-Commit-Position: refs/heads/master@{#484874}

[modify] https://crrev.com/829b1d57525c3c6549d18a2c85a96527d59ea5e9/content/renderer/BUILD.gn
[modify] https://crrev.com/829b1d57525c3c6549d18a2c85a96527d59ea5e9/content/renderer/media/gpu/rtc_video_encoder.cc
[modify] https://crrev.com/829b1d57525c3c6549d18a2c85a96527d59ea5e9/content/renderer/media/gpu/rtc_video_encoder.h
[modify] https://crrev.com/829b1d57525c3c6549d18a2c85a96527d59ea5e9/content/renderer/media/gpu/rtc_video_encoder_factory.cc
[modify] https://crrev.com/829b1d57525c3c6549d18a2c85a96527d59ea5e9/content/renderer/media/gpu/rtc_video_encoder_factory.h
[modify] https://crrev.com/829b1d57525c3c6549d18a2c85a96527d59ea5e9/content/renderer/media/gpu/rtc_video_encoder_unittest.cc

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

commit df6e5a5c7e7c665603f9619930a1d7106b55160d
Author: niklase <niklase@chromium.org>
Date: Fri Jul 07 16:59:38 2017

Revert of TCVideoEncoder: Report H264 profile information to WebRTC (patchset #1 id:190001 of https://codereview.chromium.org/2548443002/ )

Reason for revert:
Reverting this since it's causing multiple perf regression on mac, looks like HW encode/decode might get disabled.

Original issue's description:
> Reland of RTCVideoEncoder: Report H264 profile information to WebRTC (patchset #1 id:1 of https://codereview.chromium.org/2521923002/ )
>
> Reason for revert:
> Try again.
>
> Original issue's description:
> > Revert of RTCVideoEncoder: Report H264 profile information to WebRTC (patchset #3 id:60001 of https://codereview.chromium.org/2499973002/ )
> >
> > Reason for revert:
> > Causes these tests to fail on chromium.webrtc bots for Win and Mac:
> > WebRtcPerfBrowserTest.MANUAL_RunsAudioVideoCall60SecsAndLogsInternalMetricsH264
> > WebRtcVideoQualityBrowserTests/WebRtcVideoQualityBrowserTest.MANUAL_TestVideoQualityH264
> > https://build.chromium.org/p/chromium.webrtc/builders/Win8%20Tester/builds/30367
> > https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/62661
> >
> > Original issue's description:
> > > RTCVideoEncoder: Report H264 profile information to WebRTC
> > >
> > > This CL updates RTCVideoEncoderFactory to report cricket::VideoCodecs
> > > instead of WebRtcVideoEncoderFactory::VideoCodecs. The H264 profile
> > > information is added to the cricket::VideoCodec so that WebRTC receives
> > > this information. Also, the mapping between media::VideoCodecProfiles
> > > and cricket::VideoCodecs is cached so that we can send the
> > > media::VideoCodecProfile to RTCVideoEncoder instead of having to deal
> > > with webrtc::VideoCodecType.
> > >
> > > BUG= webrtc:6337 
> > >
> > > Committed: https://crrev.com/510eddede44cb4b67c8f17fdd68cefb780a668c5
> > > Cr-Commit-Position: refs/heads/master@{#433508}
> >
> > TBR=emircan@chromium.org,posciak@chromium.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG= webrtc:6337 
> >
> > Committed: https://crrev.com/c2564bc627cb950b124ac8e41bc5fd3187f7ad9c
> > Cr-Commit-Position: refs/heads/master@{#433828}
>
> TBR=emircan@chromium.org,posciak@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG= 688541 , 735959 
>
> Review-Url: https://codereview.chromium.org/2548443002
> Cr-Commit-Position: refs/heads/master@{#484874}
> Committed: https://chromium.googlesource.com/chromium/src/+/829b1d57525c3c6549d18a2c85a96527d59ea5e9

TBR=emircan@chromium.org,magjed@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 688541 , 735959 

Review-Url: https://codereview.chromium.org/2973253002
Cr-Commit-Position: refs/heads/master@{#484960}

[modify] https://crrev.com/df6e5a5c7e7c665603f9619930a1d7106b55160d/content/renderer/BUILD.gn
[modify] https://crrev.com/df6e5a5c7e7c665603f9619930a1d7106b55160d/content/renderer/media/gpu/rtc_video_encoder.cc
[modify] https://crrev.com/df6e5a5c7e7c665603f9619930a1d7106b55160d/content/renderer/media/gpu/rtc_video_encoder.h
[modify] https://crrev.com/df6e5a5c7e7c665603f9619930a1d7106b55160d/content/renderer/media/gpu/rtc_video_encoder_factory.cc
[modify] https://crrev.com/df6e5a5c7e7c665603f9619930a1d7106b55160d/content/renderer/media/gpu/rtc_video_encoder_factory.h
[modify] https://crrev.com/df6e5a5c7e7c665603f9619930a1d7106b55160d/content/renderer/media/gpu/rtc_video_encoder_unittest.cc

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

commit 4d10d214a1783c08dd1fb887600e408d87f520e3
Author: magjed <magjed@chromium.org>
Date: Wed Aug 02 11:56:04 2017

Reland of RTCVideoEncoder: Report H264 profile information to WebRTC (patchset #1 id:1 of https://codereview.chromium.org/2973253002/ )

Reason for revert:
Update test to still use HW version of H264.

Original issue's description:
> Revert of TCVideoEncoder: Report H264 profile information to WebRTC (patchset #1 id:190001 of https://codereview.chromium.org/2548443002/ )
>
> Reason for revert:
> Reverting this since it's causing multiple perf regression on mac, looks like HW encode/decode might get disabled.
>
> Original issue's description:
> > Reland of RTCVideoEncoder: Report H264 profile information to WebRTC (patchset #1 id:1 of https://codereview.chromium.org/2521923002/ )
> >
> > Reason for revert:
> > Try again.
> >
> > Original issue's description:
> > > Revert of RTCVideoEncoder: Report H264 profile information to WebRTC (patchset #3 id:60001 of https://codereview.chromium.org/2499973002/ )
> > >
> > > Reason for revert:
> > > Causes these tests to fail on chromium.webrtc bots for Win and Mac:
> > > WebRtcPerfBrowserTest.MANUAL_RunsAudioVideoCall60SecsAndLogsInternalMetricsH264
> > > WebRtcVideoQualityBrowserTests/WebRtcVideoQualityBrowserTest.MANUAL_TestVideoQualityH264
> > > https://build.chromium.org/p/chromium.webrtc/builders/Win8%20Tester/builds/30367
> > > https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/62661
> > >
> > > Original issue's description:
> > > > RTCVideoEncoder: Report H264 profile information to WebRTC
> > > >
> > > > This CL updates RTCVideoEncoderFactory to report cricket::VideoCodecs
> > > > instead of WebRtcVideoEncoderFactory::VideoCodecs. The H264 profile
> > > > information is added to the cricket::VideoCodec so that WebRTC receives
> > > > this information. Also, the mapping between media::VideoCodecProfiles
> > > > and cricket::VideoCodecs is cached so that we can send the
> > > > media::VideoCodecProfile to RTCVideoEncoder instead of having to deal
> > > > with webrtc::VideoCodecType.
> > > >
> > > > BUG= webrtc:6337 
> > > >
> > > > Committed: https://crrev.com/510eddede44cb4b67c8f17fdd68cefb780a668c5
> > > > Cr-Commit-Position: refs/heads/master@{#433508}
> > >
> > > TBR=emircan@chromium.org,posciak@chromium.org
> > > # Skipping CQ checks because original CL landed less than 1 days ago.
> > > NOPRESUBMIT=true
> > > NOTREECHECKS=true
> > > NOTRY=true
> > > BUG= webrtc:6337 
> > >
> > > Committed: https://crrev.com/c2564bc627cb950b124ac8e41bc5fd3187f7ad9c
> > > Cr-Commit-Position: refs/heads/master@{#433828}
> >
> > TBR=emircan@chromium.org,posciak@chromium.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG= 688541 , 735959 
> >
> > Review-Url: https://codereview.chromium.org/2548443002
> > Cr-Commit-Position: refs/heads/master@{#484874}
> > Committed: https://chromium.googlesource.com/chromium/src/+/829b1d57525c3c6549d18a2c85a96527d59ea5e9
>
> TBR=emircan@chromium.org,magjed@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG= 688541 , 735959 
>
> Review-Url: https://codereview.chromium.org/2973253002
> Cr-Commit-Position: refs/heads/master@{#484960}
> Committed: https://chromium.googlesource.com/chromium/src/+/df6e5a5c7e7c665603f9619930a1d7106b55160d

TBR=emircan@chromium.org,niklase@chromium.org,phoglund@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 688541 , 735959 

Review-Url: https://codereview.chromium.org/2985263002
Cr-Commit-Position: refs/heads/master@{#491338}

[modify] https://crrev.com/4d10d214a1783c08dd1fb887600e408d87f520e3/chrome/browser/media/webrtc/webrtc_browsertest.cc
[modify] https://crrev.com/4d10d214a1783c08dd1fb887600e408d87f520e3/chrome/browser/media/webrtc/webrtc_browsertest_base.cc
[modify] https://crrev.com/4d10d214a1783c08dd1fb887600e408d87f520e3/chrome/browser/media/webrtc/webrtc_browsertest_base.h
[modify] https://crrev.com/4d10d214a1783c08dd1fb887600e408d87f520e3/chrome/browser/media/webrtc/webrtc_internals_perf_browsertest.cc
[modify] https://crrev.com/4d10d214a1783c08dd1fb887600e408d87f520e3/chrome/browser/media/webrtc/webrtc_stats_perf_browsertest.cc
[modify] https://crrev.com/4d10d214a1783c08dd1fb887600e408d87f520e3/chrome/browser/media/webrtc/webrtc_video_quality_browsertest.cc
[modify] https://crrev.com/4d10d214a1783c08dd1fb887600e408d87f520e3/chrome/test/data/webrtc/munge_sdp.js
[modify] https://crrev.com/4d10d214a1783c08dd1fb887600e408d87f520e3/chrome/test/data/webrtc/peerconnection.js
[modify] https://crrev.com/4d10d214a1783c08dd1fb887600e408d87f520e3/content/renderer/BUILD.gn
[modify] https://crrev.com/4d10d214a1783c08dd1fb887600e408d87f520e3/content/renderer/media/gpu/rtc_video_encoder.cc
[modify] https://crrev.com/4d10d214a1783c08dd1fb887600e408d87f520e3/content/renderer/media/gpu/rtc_video_encoder.h
[modify] https://crrev.com/4d10d214a1783c08dd1fb887600e408d87f520e3/content/renderer/media/gpu/rtc_video_encoder_factory.cc
[modify] https://crrev.com/4d10d214a1783c08dd1fb887600e408d87f520e3/content/renderer/media/gpu/rtc_video_encoder_factory.h
[modify] https://crrev.com/4d10d214a1783c08dd1fb887600e408d87f520e3/content/renderer/media/gpu/rtc_video_encoder_unittest.cc

The above CL started breaking WebRtcVideoQualityBrowserTest.MANUAL_TestVideoQualityH264/1 tests(flaky).  
https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/70683/steps/browser_tests/logs/stdio

I think I found out why and would like to propose a fix before reverting(for the 3rd time). This test creates two HW encoder instances: for MediaRecorder and peer connection. According to platform availability on the bot, hardware might be busy and throw kVTVideoEncoderNotAvailableNowErr(-12915). When that is the case, we try to initialize a software fallback. However, since HW encode is BASELINE(+possible others) and SW encode is only CONSTRAINED_BASELINE, we cannot match profile or create an instance[0]. We can change it such that H264 SW fallback always sets it as CONSTRAINED_BASELINE, but I am not sure if this information about profile change needs to be upstreamed in some way. magjed@ WDYT?

[13720:775:0803/094846.489860:ERROR:vt_video_encode_accelerator_mac.cc(495)]  VTCompressionSessionCreate failed: -12915
[13720:775:0803/094846.490011:ERROR:vt_video_encode_accelerator_mac.cc(154)] Failed creating compression session.
[13720:775:0803/094846.490036:ERROR:gpu_video_encode_accelerator_factory.cc(116)] VEA initialize failed
[13720:775:0803/094846.490305:ERROR:gpu_video_encode_accelerator.cc(153)] Initialize Could not create VEA
[13724:31263:0803/094846.490479:ERROR:gpu_video_encode_accelerator_host.cc(109)] Send(GpuCommandBufferMsg_CreateVideoEncoder()) failed
[13724:31263:0803/094846.490510:ERROR:rtc_video_encoder.cc(589)] CreateAndInitializeVEA@../../content/renderer/media/gpu/rtc_video_encoder.cc:332kInvalidArgumentError - Error initializing video_encoder
[13724:45059:0803/094846.490621:WARNING:videoencodersoftwarefallbackwrapper.cc(36)] Encoder requesting fallback to codec not supported in software.
[13720:20739:0803/094846.490615:ERROR:gpu_channel.cc(726)] Invalid route
[13724:45059:0803/094846.490641:ERROR:generic_encoder.cc(63)] Failed to initialize the encoder associated with payload name: H264

[0] https://cs.chromium.org/chromium/src/third_party/webrtc/media/engine/videoencodersoftwarefallbackwrapper.cc?rcl=262f12e06b811d265a437d760a3add82477af106&l=35

Yeah, we could change the software fallback encoder to use a SW Constrained Baseline encoder when we have negotiated Basline, because Constrained Baseline is a subset of Baseline and still considered valid Baseline.

However, since we can use a SW decoder to decode video from the HW encoder, are we sure that the Mac HW encoder is actually producing Baseline and not Constrained Baseline? OpenH264 does not claim to be able to decode Baseline.

Another thing, since the name of the test is TestVideoQualityH264, is it actually good if we randomly use the SW encoder sometimes? Can't we just exclude the runs that weren't able to set up the HW encoders?

> Another thing, since the name of the test is TestVideoQualityH264, is it actually good if we randomly use the SW encoder sometimes? Can't we just 
> exclude the runs that weren't able to set up the HW encoders?

I tried to repro the cases where HW encode isn't available locally, but I couldn't hit any. However, I realized a point that I missed earlier. We actually create a peer connection between two tabs for this test. So actually there are three HW encoder instance: Left tab peer connection, right tab peer connection, MediaRecorder for recording left tab output. We ignore the right tab output and only focus on left. I thing these SW fallback cases are coming from right tab which is initialized later. Because when you check the graphs, we see nearly consistent values[0]. If we were switching between HW and SW for left tab, there would be more jumps.

[0] https://chromeperf.appspot.com/report?sid=654da3100803a2895adf045c6d0aaefcec997699480abd47f680d5a68219797e&start_rev=494183&end_rev=494949

> Yeah, we could change the software fallback encoder to use a SW Constrained Baseline encoder when we have negotiated Basline, because Constrained 
> Baseline is a subset of Baseline and still considered valid Baseline.
> However, since we can use a SW decoder to decode video from the HW encoder, are we sure that the Mac HW encoder is actually producing Baseline and 
> not Constrained Baseline? OpenH264 does not claim to be able to decode Baseline.

AFAIK from discussions with posciak and what I read[1], CBP is a subset of MAIN. I tried explaining that in[0]. We should choose MAIN as the default HW encode codec and fall back to CBP if necessary. In WebRTC, since we don't have any other option all our fallbacks would be CBP.

HW encoder implementations are BASELINE as far as I understand the documentations. For instance, MediaFoundation clearly lists BASELINE and CBP as different profiles[2] and says BASELINE is supported[3]. Mac lists only BASELINE and supports it. For decoding H264 in WebRTC, we are using ffmpeg[4] which supports it. OpenH264 is only for encode.

[0] https://bugs.chromium.org/p/chromium/issues/detail?id=688541 first post
[1] https://www.vocal.com/video/profiles-and-levels-in-h-264-avc/ 
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/dd318776(v=vs.85).aspx
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/dd797816(v=vs.85).aspx
[4] https://cs.chromium.org/chromium/src/third_party/webrtc/modules/video_coding/codecs/h264/h264_decoder_impl.cc?rcl=4a604c80cecce18aff6fc5e16296d04675312d83&l=18

CBP is a subset of both Baseline and Main (and High). This means that it's ok to send a CBP bitstream to any decoder that supports Baseline, Main, or High. We have to negotiate the same codec for both encoder and decode (it's a sendrecv codec), but if ffmpeg supports Baseline we can negotiate that since OpenH264 produces CBP which is a subset of Baseline.

I think your CL in https://codereview.webrtc.org/2997913003/ looks fine.

We should also list all H264 profiles that we can decode with ffmpeg that are also supersets of CBP as supported. Do we have a list somewhere what codecs ffmpeg can decode?

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/1fd66656b3754c22a43f4eded57e022916bb6064

commit 1fd66656b3754c22a43f4eded57e022916bb6064
Author: emircan <emircan@chromium.org>
Date: Tue Aug 22 00:30:58 2017

Modify profiles for H264 encode SW fallback

We have only Constrained Baseline profile available in SW encoder impl
so modify the profile to that in case  of a fallback

BUG= chromium:735959 

Review-Url: https://codereview.webrtc.org/2997913003
Cr-Commit-Position: refs/heads/master@{#19436}

[modify] https://crrev.com/1fd66656b3754c22a43f4eded57e022916bb6064/webrtc/media/BUILD.gn
[modify] https://crrev.com/1fd66656b3754c22a43f4eded57e022916bb6064/webrtc/media/engine/videoencodersoftwarefallbackwrapper.cc
[modify] https://crrev.com/1fd66656b3754c22a43f4eded57e022916bb6064/webrtc/media/engine/videoencodersoftwarefallbackwrapper.h

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/296b64eb25949d84d9cb85fce02e7ba05be9d419

commit 296b64eb25949d84d9cb85fce02e7ba05be9d419
Author: zhihuang <zhihuang@webrtc.org>
Date: Tue Aug 22 00:52:41 2017

Revert of Modify profiles for H264 encode SW fallback (patchset #2 id:20001 of https://codereview.webrtc.org/2997913003/ )

Reason for revert:
Breaks the internal bots.
Root cause: The "public_deps" is defined behind an "if" condition which may not be true.

Original issue's description:
> Modify profiles for H264 encode SW fallback
>
> We have only Constrained Baseline profile available in SW encoder impl
> so modify the profile to that in case  of a fallback
>
> BUG= chromium:735959 
>
> Review-Url: https://codereview.webrtc.org/2997913003
> Cr-Commit-Position: refs/heads/master@{#19436}
> Committed: https://chromium.googlesource.com/external/webrtc/+/1fd66656b3754c22a43f4eded57e022916bb6064

TBR=magjed@webrtc.org,emircan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= chromium:735959 

Review-Url: https://codereview.webrtc.org/2995373002
Cr-Commit-Position: refs/heads/master@{#19438}

[modify] https://crrev.com/296b64eb25949d84d9cb85fce02e7ba05be9d419/webrtc/media/BUILD.gn
[modify] https://crrev.com/296b64eb25949d84d9cb85fce02e7ba05be9d419/webrtc/media/engine/videoencodersoftwarefallbackwrapper.cc
[modify] https://crrev.com/296b64eb25949d84d9cb85fce02e7ba05be9d419/webrtc/media/engine/videoencodersoftwarefallbackwrapper.h

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/82fac89381b6981f3f9d83ce38100330c700433d

commit 82fac89381b6981f3f9d83ce38100330c700433d
Author: emircan <emircan@chromium.org>
Date: Wed Aug 23 21:19:50 2017

Reland of Modify profiles for H264 encode SW fallback (patchset #1 id:1 of https://codereview.webrtc.org/2995373002/ )

Reason for revert:
Fix and reland.

Original issue's description:
> Revert of Modify profiles for H264 encode SW fallback (patchset #2 id:20001 of https://codereview.webrtc.org/2997913003/ )
>
> Reason for revert:
> Breaks the internal bots.
> Root cause: The "public_deps" is defined behind an "if" condition which may not be true.
>
> Original issue's description:
> > Modify profiles for H264 encode SW fallback
> >
> > We have only Constrained Baseline profile available in SW encoder impl
> > so modify the profile to that in case  of a fallback
> >
> > BUG= chromium:735959 
> >
> > Review-Url: https://codereview.webrtc.org/2997913003
> > Cr-Commit-Position: refs/heads/master@{#19436}
> > Committed: https://chromium.googlesource.com/external/webrtc/+/1fd66656b3754c22a43f4eded57e022916bb6064
>
> TBR=magjed@webrtc.org,emircan@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG= chromium:735959 
>
> Review-Url: https://codereview.webrtc.org/2995373002
> Cr-Commit-Position: refs/heads/master@{#19438}
> Committed: https://chromium.googlesource.com/external/webrtc/+/296b64eb25949d84d9cb85fce02e7ba05be9d419

TBR=magjed@webrtc.org,zhihuang@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= chromium:735959 

Review-Url: https://codereview.webrtc.org/2997423002
Cr-Commit-Position: refs/heads/master@{#19476}

[modify] https://crrev.com/82fac89381b6981f3f9d83ce38100330c700433d/webrtc/media/BUILD.gn
[modify] https://crrev.com/82fac89381b6981f3f9d83ce38100330c700433d/webrtc/media/engine/videoencodersoftwarefallbackwrapper.cc
[modify] https://crrev.com/82fac89381b6981f3f9d83ce38100330c700433d/webrtc/media/engine/videoencodersoftwarefallbackwrapper.h

I also hope H264 hp support is added in chrome, at least the decoder part.