This may be caused by crrev.com/6bb3a090e4233860f837d2f97158f18e0aefacbe.

Could you please verify if this is a regression between CrOS 9312.0.0 and 9313.0.0? Does this reproduce on kevin?

I could not reproduce this issue on Jerry with M58 58.0.3021.0 / 9313.0.0 dev

Apprtc loopback URL used : https://appr.tc/?debug=loopback

Feedback submitted for loopback call on Jerry with VP8 : 53934330661
Feedback submitted for loopback call on Jerry with H264 : 53934404615

Video corruption is observed on Jerry, Jaq and Minnie (Rockchip family devices) only during apprtc or hangout calls with Logitech external camera 
(Related bug https://bugs.chromium.org/p/chromium/issues/detail?id=677573)

On kevin: after playing video for a while both(h264 and vp8) remote videos went black.
feedback report : 53936854106

On jerry on 9312.0.0 issue not reproduced. 

If the issue reproduces on 9313.0.0, but not 9312.0.0, then it's probably related to scaling matrix changes. Owen, could you please take a look? Thanks.

Cannot reproduce the issue on minnie 9327.0.0. Will see if I can reproduce the issue on Kevin.

Just tested on Kevin 9329.0.0. Both h264 and vp8 works fine.

Hi, avkodipelli@, Can you try again and see if it is still reproducible?

crbug.com/698088 is effecting verification. I'll verify once loopback issue resolved.

Issue reproduced on 9334.18.0, 58.0.3029.31 and 9334.20.0, 58.0.3029.36 

Repo steps :
1, start playing h264 and vp8 apprtc loopback video side by side
2. after while close camera with finger and open 
3, Observe corruption in h264 video
4, Some times it might required close and open camera with finger for few times.

Feedback ID: 55678759454

Owen. PTAL.

Still cannot reproduce the issue. 

Maybe it related to 
https://buganizer.corp.google.com/issues/35952661

Finally, I just reproduced the issue. It looks like related to the lightness of the environment. It seems easier to reproduce in a dark environment.

I can confirm this is not a dup to b/359527661, it's a different issue.

Can we add stable blocker for this?

bhthompson@, FYI, I added a release block stable for this. 

Some more observations: I can reproduce this issue on M57 9202.50.0 on veyron_minnie. The issue looks like related to the frame rates. It is much easy to reproduce it when the frame rate is higher.

It seems the initial frame rate for M57 is different, so I need to wait the frame rate goes higher and then can reproduce the issue.

Any update here? This is marked as a stable blocker, and we are nearing stable promotion for 58. 

I would suggest to remove the stable blocker as this issue can be reproduced on earlier version. 

Besides, the issue is not easy to reproduce. (As said in #10)
"Sometimes it might required close and open camera with finger for few times."

Some more observations: after disable the hardware video decoding for WebRTC, I tried several times but cannot reproduce the issue. Indicating this could be a hw decoder issue.

I dump the bitstream from the input of the hardware decoder(v4l2_svda). The video can be played without corruption on my z840 desktop as well as peach pit.

But it has the observed corruption around 00:15 when played on veyron_minnie. I also tried to play the video on kevin, but it even cannot be played.

I am going to file a partner issue on rockchip and ask for help.

Deleted: v4l2_svda_dump.1209.mp4 16.4 MB

v4l2_svda_dump.1209.mp4 16.4 MB Download

Partner issue filed as
https://b.corp.google.com/issues/37614149

As this is not a regression per comment 18, we should not block stable. 

Observing this issue on 9765.16.0, 61.0.3163.30 on jerry.

feedback id: 69850170092