This issue is also observed on device Yuna with M51 51.0.2704.55 / 8172.39.0 beta.

Webrtc_internals dump from device Yuna and desktop(Linux):
https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/612198/

Does these devices have the same CPU?

#2 - doesn't look like it. http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices indicates that the blaze is based on  Tegra K1, while yuna is based on  Celeron 3250U.

This issue is also seen on Big and Kitty(which belong to the same "Nyan(ARM)" family as Blaze) with M52 52.0.2743.39 / 8350.28.0 beta 

Note: I could not reproduce this issue on device Yuna with latest M52 beta build. Separate bug will be filed if this issue is observed again on Yuna.

Could you provide ChromeOS logs as well please? Thank you.

WebRTC internal dumps from each of the devices Big, Blaze and Kitty during hangout with desktop(Linux):
https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/612198/

Feedback submitted for issue seen on device Kitty:
https://feedback.corp.google.com/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReportSearch=user:srcv&lReport=9795690918

This seems to be a stable blocker as hangout is affected due to this problem.

This issue was found on device Blaze with M51 beta as mentioned in the bug initial report. I am rechecking devices Big and Kitty with M51 stable and will update this bug accordingly.

https://codereview.chromium.org/2069923005 should fix this.

 Issue 620617  has been merged into this issue.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I was able to reproduce this issue (2/3 times) on devices Big and Kitty with M51 stable (51.0.2704.79 / 8172.47.0)

WebRTC internal dumps from devices Big and Kitty (both with M51 stable) during hangout with Linux desktop :
https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/612198/M51%20stable%20logs/

Note: This issue is not seen sometimes when :
a) you stay in the hangout call for some time or 
b) start screensharing (which doesn't work until few attempts are made for sharing) or
c) turn on/off the camera

Thanks! Should we fix this in M51 then?

wuchengli@: looks like the patch is failing some tests. Please ask for M52 branch merge after successfully landing it in ToT

Re 17: Sorry. I didn't notice CQ rejected it. It was a flaky test. I've sent it to CQ again. 

Re 16: I'll request a merge for M51 and M52 after it's submitted. This CL is small and shouldn't have much risk.

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

commit 5a83a05e8647c71db1e155dec4c030d5f581e380
Author: wuchengli <wuchengli@chromium.org>
Date: Fri Jun 17 01:48:15 2016

V4L2VEA: fix keyframe is not generated on nyan

Nyan does not support V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME yet.
But it reports success to V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME
and keyframe is not generated. Switch the order of two controls
and try V4L2_CID_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE first.

BUG= chromium:612198 
TEST=Run VEA test on nyan and oak.

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

[modify] https://crrev.com/5a83a05e8647c71db1e155dec4c030d5f581e380/media/gpu/v4l2_video_encode_accelerator.cc

Since this is a Chrome side fix is there any chance this would impact desktop builds or is this CrOS specific?

If this is limited in impact to CrOS the merge seems ok to me, if not we may need to consult the desktop release TPM. 

[Automated comment] Request affecting a post-stable build (M51), manual review required.

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

Re 24: v4l2_video_encode_accelerator.cc modified by the fix is only used by CrOS. No other platforms use it. It won't impact Windows, Mac, or Android.

SGTM, lets land it.

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Chrome just uprev in the latest build 8481.0.0. I'll test it the first thing tomorrow and merge the fix to M51 and M52.

Great, we are building another stable release wednesday afternoon, so if we can land this today we will get in the next push.

Comment 20: if this verified, please go ahead and merge.

Verified on nyan, oak, and minnie 8484.0.0. apprtc loopback and VEA test passed. I'm merging this to M51 and M52 now.

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

commit c67053364e031746af29283a5113fae2214abe8b
Author: Wu-Cheng Li <wuchengli@chromium.org>
Date: Wed Jun 22 02:19:36 2016

V4L2VEA: fix keyframe is not generated on nyan

Nyan does not support V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME yet.
But it reports success to V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME
and keyframe is not generated. Switch the order of two controls
and try V4L2_CID_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE first.

BUG= chromium:612198 
TEST=Run VEA test on nyan and oak.

Review-Url: https://codereview.chromium.org/2069923005
Cr-Commit-Position: refs/heads/master@{#400328}
(cherry picked from commit 5a83a05e8647c71db1e155dec4c030d5f581e380)

Review URL: https://codereview.chromium.org/2086183003 .

Cr-Commit-Position: refs/branch-heads/2743@{#445}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/c67053364e031746af29283a5113fae2214abe8b/media/gpu/v4l2_video_encode_accelerator.cc

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

commit 87cc040a0d78a96d8a7dcfd6acb1f6fc821ed740
Author: Wu-Cheng Li <wuchengli@chromium.org>
Date: Wed Jun 22 02:51:37 2016

V4L2VEA: fix keyframe is not generated on nyan

Nyan does not support V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME yet.
But it reports success to V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME
and keyframe is not generated. Switch the order of two controls
and try V4L2_CID_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE first.

BUG= chromium:612198 
TEST=Run VEA test on nyan and oak.

Review-Url: https://codereview.chromium.org/2069923005
Cr-Commit-Position: refs/heads/master@{#400328}
(cherry picked from commit 5a83a05e8647c71db1e155dec4c030d5f581e380)

Review URL: https://codereview.chromium.org/2085193002 .

Cr-Commit-Position: refs/branch-heads/2704@{#726}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/87cc040a0d78a96d8a7dcfd6acb1f6fc821ed740/content/common/gpu/media/v4l2_video_encode_accelerator.cc

The fix has been merged to M51 and M52. Can someone from test eng team verify this in M51 and M52 in the next build? Thanks.

Today's M51 is using the same Chrome from the last stable release build so it seems Nyan users won't have this fix available.

Ranjani, in the meantime can you verify this fix on M52 and M53?

Verification on M52 and M53 in progress.

Tested hangouts on devices Big, Blaze and Kitty with M52 52.0.2743.50 / 8350.39.0 beta and M53 53.0.2773.0 / 8481.0.0 dev and verified that:
a) device camera starts as soon as hangout started
b) screensharing works as soon as a window is selected for screensharing

Note: Observed that "Internal display" screen on chrome device, occasionally displays blank screen during hangout screenshare. This issue was seen on all the three devices Big, Blaze and Kitty with M52 beta and M53 builds
- "Internal display" screen is displayed normally after 1-2 seconds and screensharing on that window worked properly
- I was not able to consistently repro this issue
- Feedback submitted for this issue :
https://feedback.corp.google.com/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReportSearch=user:srcv&lReport=10155179570

WebRTC internal dump from hangouts on devices Big, Blaze and Kitty:
https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/612198/Bug_verification_logs/?pli=1

Thanks, Ranjani! 

Could you file a new bug for 'displays blank screen during hangout screenshare" problem? Not sure if this is a new problem or it has been there.

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=623625 ("Internal display" window shows blank screen(sometimes) during hangout screenshare selection )