https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/615272/

Thanks for the report! Big and Blaze are part of the same device "family;" do you see similar freezes on any other ChromeOS device?

niklase@ - while we wait for a response to that question from srcv@, can you find someone to look into this? You should be able to borrow a Big or Blaze from srcv@ when she gets into the office.

This issue is so far seen only on Big and Blaze. I will update this bug if this issue is seen on any other devices.

Ranjani, is this a regression from M51?

Could you please confirm the following: this is reproducible on H264 apprtc loopback when sending H264, but not with peer2peer apprtc when also sending H264, and from the same device?

The histograms show a mix of VP8 and H264 for encoder profile, is it possible that peer2peer was using VP8 when it worked?

Looks like we are hitting a NOTREACHED() in https://chromium.googlesource.com/chromium/src/+blame/master/content/renderer/media/webrtc/webrtc_video_capturer_adapter.cc#230.

This was last modified by emircan@ in crrev.com/379932. Could also be related to how formats are handled in VideoFrame after crrev.com/379932? Tentatively adding release block based on severity.

I will take a look at this tomorrow when I have access to Blaze. 

posciak@, that CL adds YV12A to the accepted formats, and the check has been there already. Is there smt different for this device family that would cause capture of a different format than the listed?
https://codereview.chromium.org/1737253002/diff/160001/content/renderer/media/webrtc/webrtc_video_capturer_adapter.cc

Regarding #6, this is isn't reproducible with VP8/VP9. Only H264 has the problems: remote video starts playing after ~30 seconds, pushes 1~2 frames and freezes.

posciak@, note that we recently enabled HW H264 encode with the below CL. Earlier on, it was only enabled for extensions. Now, it is enabled by default when SW fallback is available. 
https://codereview.chromium.org/1972333002/
 

Here is some logs from Blaze with ToT.
https://paste.googleplex.com/5782678435528704

It looks like a number of buffers are enqueued in v4l2_video_encode_accelerator, but doesn't get dequeued(), destroyed right before.

Looking at l.854 in the logs above, this fails with kInvalidArgumentError. Looks very much like  issue 614641 .

wuchengli@, can you PTAL? 

Some new logs: https://paste.googleplex.com/6302221352304640

l.678 [1:12:0531/183710:VERBOSE3:gpu_video_encode_accelerator_host.cc(85)] Initialize
l.706 [1:12:0531/183711:ERROR:gpu_video_encode_accelerator_host.cc(106)] Send(GpuCommandBufferMsg_CreateVideoEncoder()) failed

This is interesting that after destroy, we aren't able to send messages to GPU service. Adding fsamuel@ as well.

Sorry. I'll be OOO during Jun 3-12. I still need to fix several issues tomorrow. Can you revert CL https://codereview.chromium.org/1972333002 and merge to M52 first? Then we'll find someone to look at the freeze issue.

rohitbm@:

This issue is not a regression from M51 as H264 support is introduced with M52.

emircan@: will you revert the CL and request a merge as we go beta next Tue?

I prepared a CL for revert here: https://codereview.chromium.org/2030833002/ It will request a merge once it lands.
 
In the meantime, I made some more progress in debugging:
- When VEA is reset due to resizing, we see a crash in gpu process. I added more logging and found out that the crash comes when destructing TegraV4L2Device. See l.1006 in https://paste.googleplex.com/4560652328763392. I will add a bug for it now.
- When resize issue eliminated by hardcoding the size, we still cannot see the encoded frames in AppRTC loopback. However, when I open a connection with a remote client(Mac OSX), I can see that encoded frames reach there and get decoded and rendered properly. This is probably the same underlying reason as  issue 615265 .

Thanks. 

https://appr.tc/?debug=loopback&vsc=h264: is this only app side change or change in M52 WebRTC as well?

For M52 we enabled HW H264 encode by default. Earlier on it was enabled only for extensions. See comment 9. 

Thanks, emircan@ for the details!

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

commit d7e93a2d1bae10c260230a1de7c5d9f1f0272d03
Author: emircan <emircan@chromium.org>
Date: Fri Jun 03 02:48:10 2016

Revert "Use kEnableWebRtcHWH264Encoding flag when SW fallback is available"

Because we came across issues in some CrOS platforms in HW H264 encode,
we decided to revert this CL such that HW H264 is only enabled for MacOSX.
Please see the bug below for details.

BUG= 615272 

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

[modify] https://crrev.com/d7e93a2d1bae10c260230a1de7c5d9f1f0272d03/content/renderer/media/rtc_video_encoder_factory.cc

holmer@ do you want to use this bug for the freezes in:

https://bugs.chromium.org/p/webrtc/issues/detail?id=5675#c27

Since they hit software as well.

I tested with the revert patch to see how things go with SW H264 encode. 

Now what I see is that HW H264 Decode is having an issue, namely hitting a WeakPtr DCHECK as you can see on https://paste.googleplex.com/6523866897711104. When I disable it in code, SW decode H264 works properly. posciak@ can you PTAL?

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

commit c91c0dba98b29249bb41ad1bda1702f76ba0048a
Author: emircan <emircan@chromium.org>
Date: Fri Jun 03 21:47:57 2016

Revert "Use kEnableWebRtcHWH264Encoding flag when SW fallback is available"

Because we came across issues in some CrOS platforms in HW H264 encode,
we decided to revert this CL such that HW H264 is only enabled for MacOSX.
Please see the bug below for details.

BUG= 615272 

Review-Url: https://codereview.chromium.org/2030833002
Cr-Commit-Position: refs/heads/master@{#397601}
(cherry picked from commit d7e93a2d1bae10c260230a1de7c5d9f1f0272d03)

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

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

[modify] https://crrev.com/c91c0dba98b29249bb41ad1bda1702f76ba0048a/content/renderer/media/rtc_video_encoder_factory.cc

[Automated comment] Reverts referenced in bugdroid comments, after merge request, needs manual review.

Cl has been reverted. Will remove beta-blocker label.

As emircan@ mentioned in Comment#25, this issue is not seen on device Blaze when "Hardware-accelarated video decode Mac, Windows, chrome OS" flag is disabled in chrome://flags. Filed a separate bug for this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=617811
 

sprang@ FYI

Verified in M52-(8350.38.0) 52.0.2743.49

Changing the status to Fixed for Ranjani to verify this as she knows more about the problem :-)

Tested AppRTC loopback calls with H264 on devices Big, Blaze and Kitty with M52 52.0.2743.50 / 8350.39.0 beta and verified that there are no video freezes during apprtc calls with H264.

URL used :  https://appr.tc/?debug=loopback&vsc=h264

WebRTC internal dump from devices Big, Blaze and Kitty:
https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/615272/cr_615272_verification_logs/