Fatal error in ../../../../../../../home/chrome-bot/chrome_root/src/third_party/webrtc/modules/video_coding/codecs/h264/h264.cc, line 94
# Check failed: g_rtc_use_h264
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc/modules/video_coding/codecs/h264/h264.cc&l=94 

This stack points at the below line:
https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/media/webrtc/peer_connection_dependency_factory.cc&l=174

I assume this error won't happen with kWebRtcH264WithOpenH264FFmpeg. However, that isn't the case on 51. I am not sure what would happen if we just remove this webrtc::DisableRtcUseH264() line. Passing it to hbos who added it on https://codereview.chromium.org/1718883002. Can you PTAL?

I think the problem is the #if defined mismatch between IsH264CodecSupported and H264Encoder/H264Decoder::Create.
I created this CL, hopefully it + rolling will resolve the issue. Is there a way to confirm this?

I agree that this won't be a problem when kWebRtcH264WithOpenH264FFmpeg is enabled, which it now is by default.

Can we upstream the fix?

This is the CL btw: https://codereview.webrtc.org/2018273002/

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

commit 073eb7ed1e398bedb8aeef1ce1bfd99f6cd0131c
Author: hbos <hbos@webrtc.org>
Date: Mon May 30 12:15:25 2016

Updated #if in IsH264CodecSupported to match H264[En/De]coder::Create.

This will hopefully resolve a crash that might occur if it thinks H264 is
supported when in fact it isn't.

BUG= chromium:615513 

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

[modify] https://crrev.com/073eb7ed1e398bedb8aeef1ce1bfd99f6cd0131c/webrtc/modules/video_coding/codecs/h264/h264.cc

This should probably be merged for M52, right?

Looking at the patch this shouldn't have affected ChromeOS should it?

Yes, I am not sure if your change would have affect on CrOS. I think the culprit for this error would be https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/media/webrtc/peer_connection_dependency_factory.cc&l=173 Can you take a look if we actually need it?

Shouldn't that still be required if we ever want to turn this off? This flag should be default-enabled, right?

Oops you're right, I jumped the gun in concluding this was the problem when I saw mismatching #ifs, not noting the fact that it was clearly an iOS macro.

https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/media/webrtc/peer_connection_dependency_factory.cc&l=173 affects if the SW implementation is supported or not. This happens or not due to a compiler flag, and I would expect before anyone would check if H264[En/De]coder::IsSupported() since PeerConnectionDependencyFactory::CreatePeerConnectionFactory() initializes webrtc stuff including the signaling/worker threads.

Why would a decoder be created if !IsSupported? And why "random crashes"?

Other code that might affect if H264 is supported would be external factories. Could an external factory say H264 is supported but then somehow we fall back on SW and hit this?

emircan@ didn't you have a CL that did SW fallback? Maybe it does SW fallback even though there is no SW support?

This bug is coming from webex which runs under extensions. AFAIK, HW H264 encode has been enabled for extensions for quite a while, including 51. Therefore, it still needs to create a decoder for it. 

However, it hits this line [0] since the kWebRtcH264WithOpenH264FFmpeg flag isn't there. HW H264 is enabled via kEnableWebRtcHWH264Encoding flag. In the logs there are lines pointing to VDA errors. If it is consistent enough, it falls back to SW decode. I think we should check for if (base::FeatureList::IsEnabled(kWebRtcH264WithOpenH264FFmpeg) || base::FeatureList::IsEnabled(kEnableWebRtcHWH264Encoding)) there. WDYT?

[7123:8487:0526/224150:ERROR:vaapi_video_decode_accelerator.cc(613)] Error decoding stream
[7123:7123:0526/224150:ERROR:vaapi_video_decode_accelerator.cc(276)] Notifying of error 4
[1:21:0526/224150:ERROR:rtc_video_decoder.cc(496)] VDA Error:4

[0] https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/media/webrtc/peer_connection_dependency_factory.cc&l=173 

PTAL at https://codereview.chromium.org/2024303003/.

Sounds like we have a good idea why this might be happening. :)

Enabling SW to ensure that we can always do SW fallback makes it not care about the runtime feature flag in an unexpected way, and only works if we're building with SW. On Chromium builds (as opposed to Chrome Official builds) we don't have SW regardless, and so this would still be an active bug for Chromium.

Assuming it's crashing because it's trying to do SW fallback when HW fails too much, I think a proper fix should be to make sure the HW only attempts to do SW fallback if SW is available. Trying to do fallback without knowing if there's anything to fall back on is a bug, if that is the case.

Could you make a CL like that, perhaps checking webrtc::H264Decoder::IsSupported() before falling back? Would that work?

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

commit 177cc1d1d66346ea9e2e85ecb3d6812e13b11907
Author: emircan <emircan@chromium.org>
Date: Sat Jun 04 00:35:42 2016

Enable RTCVideoDecoder SW H264 fallback only when it is available

Extensions have HW H264 encode enabled in 51. However SW implementations
of H264 isn't enabled by default. So, we need to be careful about SW fallback
as we cannot do it when it isn't available.

BUG= 615513 

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

[modify] https://crrev.com/177cc1d1d66346ea9e2e85ecb3d6812e13b11907/content/renderer/media/rtc_video_decoder.cc

Your change meets the bar and is auto-approved for M52 (branch: 2743)

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

commit 58387c55503c847bffe1a4450cb10b8b53376498
Author: emircan <emircan@chromium.org>
Date: Mon Jun 06 20:46:53 2016

Enable RTCVideoDecoder SW H264 fallback only when it is available

Extensions have HW H264 encode enabled in 51. However SW implementations
of H264 isn't enabled by default. So, we need to be careful about SW fallback
as we cannot do it when it isn't available.

BUG= 615513 

Review-Url: https://codereview.chromium.org/2024303003
Cr-Commit-Position: refs/heads/master@{#397856}
(cherry picked from commit 177cc1d1d66346ea9e2e85ecb3d6812e13b11907)

NOTRY=true
NOPRESUBMIT=true
TBR=mcasas@chromium.org

Review-Url: https://codereview.chromium.org/2044643002
Cr-Commit-Position: refs/branch-heads/2743@{#249}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/58387c55503c847bffe1a4450cb10b8b53376498/content/renderer/media/rtc_video_decoder.cc

Is this now Fixed?

I will mark it as fixed, since there isn't much we can do at this point. The fix will be in M52. I have talked to branch owners of M51 in another CL and they said there wouldn't be a respin on it. 
https://bugs.chromium.org/p/chromium/issues/detail?id=602834#c20