magjed@ since this only happens for H264, can you take a look if it is related to codec profiles. It does not happen on M55. 

I can't really say from the log, but it's possible it's related to H264 profiles. The profile change was reverted in WebRTC 3 days ago: https://codereview.webrtc.org/2440123002/, and rolled into Chromium 2 days ago: https://codereview.chromium.org/2451753002/ (branch base position 427625).

56.0.2899.0 is on branch base position 426989 so it still has the codec change. Can you try again once the Chrome version is after 427625?

Issue is also observed on lulu, wizip devices on 8953.0.0/56.0.2905.0 for H264.

But not reproduced on blaze and skate . Looks like it is intel specific issue.

If it happens on 56.0.2905.0, then it's not related to H264 profiles.

Observed this issue on chrome device Engurade with M56 56.0.2907.0 / 8954.0.0 dev. Both AppRTC loopback and peer2peer calls are not connected with H264 codec on Engurade.

I'll take a look.

H264 loopback worked on cyan M53 8530.80.0. I'll try M56.

I reproduced the issue on cyan M56 8954.0.0.

Disabling HW encoder fixed the issue. Disabling HW decoder didn't fix the issue.

I used #disable-webrtc-hw-decoding and #disable-webrtc-hw-encoding in chrome://flags.

Could you provide logs from repro please? Thanks.

VEA was sending encoder frames to webrtc. But apprtc was not connected.

Deleted: chrome 51.3 KB

chrome 51.3 KB View Download

Hi all. HW encoders did not generate errors in the log. We need to dive into webrtc to know why the loopback was not connected. How do we enable all webrtc and libjingle logs?

Or is there any pointer for the next debugging step in webrtc?

This issue is observed on chrome devices Paine,Candy,Kip,Sentry and Ultima with M56 56.0.2907.0 / 8971.0.0  dev

Javascript logs and WebRTC internal dump from device Candy:
https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/660221/

I enabled all verbose logs.

VP8 loopback has the following logs.
[1:14:1110/100402:INFO:jitter_buffer.cc(1201)] Received first complete key frame

H264 loopback doesn't have anything from jitter_buffer.cc.

Deleted: chrome_h264.txt 1.0 MB

chrome_h264.txt 1.0 MB View Download

Deleted: chrome_vp8.txt 1.0 MB

chrome_vp8.txt 1.0 MB View Download

A note for myself: some comments in https://bugs.chromium.org/p/chromium/issues/detail?id=653434 are related to this issue.

Reverting https://codereview.chromium.org/2274493002 (Improve H264 stream header handling) didn't fix the issue.

Reverting https://chromium.googlesource.com/external/webrtc/trunk/webrtc/+/553f5ae3597df8bfd8519643e0ec48d5bb081c55 (Use sps and pps to determine decodability of H.264 frames) didn't fix the issue.

I forgot to enable vaapi vea logs. Here is the log of h264 loopback with vaapi vea logs.
 

Deleted: chrome_h264_vaapi_logs_enabled.txt 1.1 MB

chrome_h264_vaapi_logs_enabled.txt 1.1 MB View Download

VEA test failed. The encoded video dumped from the test could not be played by mplayer.

localhost home # ./video_encode_accelerator_unittest --test_stream_data=bear_320x192_40frames.yuv:320:192:1:out1.h264:200000:30:200000:30
[==========] Running 11 tests from 8 test cases.
[----------] Global test environment set-up.
[----------] 2 tests from SimpleEncode/VideoEncodeAcceleratorTest
[ RUN      ] SimpleEncode/VideoEncodeAcceleratorTest.TestSimpleEncode/0
libva info: VA-API version 0.39.2
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
libva info: VA-API version 0.39.2
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
../../media/gpu/video_encode_accelerator_unittest.cc:1383: Failure
Value of: seen_keyframe_in_this_buffer_
  Actual: false
Expected: key_frame
Which is: true
../../media/gpu/video_encode_accelerator_unittest.cc:1383: Failure
Value of: seen_keyframe_in_this_buffer_
  Actual: false
Expected: key_frame
Which is: true
../../media/gpu/video_encode_accelerator_unittest.cc:1383: Failure
Value of: seen_keyframe_in_this_buffer_
  Actual: false
Expected: key_frame
Which is: true
../../media/gpu/video_encode_accelerator_unittest.cc:1383: Failure
Value of: seen_keyframe_in_this_buffer_
  Actual: false
Expected: key_frame
Which is: true
../../media/gpu/video_encode_accelerator_unittest.cc:1383: Failure
Value of: seen_keyframe_in_this_buffer_
  Actual: false
Expected: key_frame
Which is: true
../../media/gpu/video_encode_accelerator_unittest.cc:1383: Failure
Value of: seen_keyframe_in_this_buffer_
  Actual: false
Expected: key_frame
Which is: true

H264 loopback worked in cyan 8940.0.0.

H264 loopback worked in cyan 8940.0.0 with tot chrome synced today.

H264 loopback failed in cyan 8941.0.0.

This is part of http://crbug.com/662792. Assigning to Kuang-che.

The fix in ChromeOS is landed https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/b91b6f0b013d44535bc47fb2be6ea577daa54d67

see https://bugs.chromium.org/p/chromium/issues/detail?id=662792#c21 for detail.

Verified on 9000.19.0/56.0.2924.18 on guado