The example of getUserMedia at https://simpl.info/getusermedia/ works on Chrome 51, but stops working from version 52 and above when rotating from portrait to landscape many times.

At this link https://jsfiddle.net/kswd7o3a/5/ there is a jsfiddle with the new navigator.mediaDevices.getUserMedia(...) and an iFrame with a MorphCast.
The video connected to the stream from getUserMedia freezes after some seconds.

Tested devices with this issue:
- Samsung galaxy S7 Edge; Chrome 54.0.2840.68; Android 6.0.1
- Nexus 5x; Chrome 54.0.2840.68; Android 7.0.0

Tested devices working properly:
- Motorola Moto E (2nd gen); Chrome 54.0.2840.68; Android 6.0.0

FWIW I can't reproduce the problem changing from portrait to landscape (or refreshing multiple times) on Chrome 56.0.2900.3 or 55.0.2883.28 on Android 6.0.1 on Nexus 6P.

I've tried https://simpl.info/getusermedia and https://webrtc.github.io/samples/.

Looking into it.

We are facing this problem on Nexus 5x and Samsung Galaxy S6/S7/S7 edge. Whereas on other devices it seems to work properly.

For sure it works OK on Motorola Moto E 2nd generation and Motorola Moto G 1st generation.

In addition everything works fine on Firefox, and on Chrome 51 and below.

A bit of more information I hope will be useful:
When the video freezes,
- size is 0x0 and currentTime is 0
- timeupdate stops being called
- progress gets called
- shutting down tracks (stream.getTracks().forEach(function (track) {track.stop();}) and calling getUserMedia again, makes the video work again for a while.

Thanks.

A consideration from our manager:
"We believe it works on Nexus 6P, still remain the fact that not working on these devices for sure: Nexus 5x and Samsung Galaxy S6 and Galaxy S7 and Galaxy S7 Edge. Please check on one of these devices, you can probably find out the problem.  Thanks for your attention."

We have spotted this issue too right before launching very important pilot.

We can confirm that:
 - this bug happens only on certain devices. For us it happens on Samsung S7; Samsung S7 Edge; LG G5 Dual Sim H860
 - doesn't happen on Samsung Galaxy Tab A; Samsung Note 3; Huawei GR5
 - doesn't happen in other browsers like Firefox (android)

The freezing happens much faster in one of our web application. Whereas in other web apps you would have to spend more than 1 minute to actually trigger this bug.

Workaround of shutting down tracks and calling getUserMedia works. However, as there is no known way to programmatically detect video freeze (if somebody actually knows, we will highly appreciate you sharing this with everybody), this workaround isn't usable in production.

There is a way to detect the camera has frozen:
- event "progress" gets called even when the camera is frozen
- video.currentTime, when the camera freezes, doesn't change
- pay attention to the first camera acquisition: currentTime is 0 for a while
- camera may freeze immediately, which means currentTime is 0 and doesn't change

Our workaround:
- if currentTime doesn't change, restart the camera
- if currentTime remains 0 for more than some seconds, restart the camera

@andrea
The workaround works with easyRTC, and sometimes works with Tokbox.

Thank you very much!

Anton

@Anton

you said, that the workaround works somtimes with Tokbox. What does it mean? Do you have some samplecode, which you could share?
Thanks you very much!

Harald

(writing from my personal account)

@Harald
It often happens that I get publishing timeout (it can be seen in browser's console) when I try to revive the video.

Attached a snippet (typescript + react.js)

Anton

Deleted: pastie-10955521.js 2.0 KB

pastie-10955521.js 2.0 KB View Download

@Anton
Thank you very much!

Harald

Hi,

I've done some tests with the links in the first comment: 
 - we could reproduce the issue in 54.0.2840.68 for Android in a Samsung J7 (6.0.1)
 - we could not reproduce the issue in a Samsung Grand Neo (Android 4.2)

We have also experienced another issue which is very likely to be related:


We could reproduce the issue testing https://apprtc.appspot.com. When we join a conf the readyState property of the video track is set to "muted" instead to "live"  and the muted property set to "true". Apparently this is not happening in Chrome 54 for other Operative Systems (at least Linux and Win32). The device we used for tests was a Samsung Galaxy J7 (2016 Android 6.0.1). This also happens in our WebRTC client. 
We could not reproduce the issue with a Samsung Grand Neo (Android 4.2)

Steps we followed to reproduce it:
 - Open https://apprtc.appspot.com/r/<room name> in Chrome 54 for Android
 - The local video from the front cam is shown correctly
 - Click on "Join"
 - The video is stopped

To check the track video status we followed the steps below:
 - Add a breakpoint a https://apprtc.appspot.com/r/<room name> in the line "trace("Got access to local media with mediaConstraints:\n" + "  '" + JSON.stringify(mediaConstraints) + "'");"
 - Reload the page. The  execution is stopped just after accessing the media. We keep a reference to the local stream clicking on "store as Global Variable"
 - Then we continue the execution. We can check the status of the local stream in the console: 
temp1.getVideoTracks()[0]
MediaStreamTrack
enabled: true
id: "ac9ec41a-4da8-478f-a88b-901efc2ba1f4"
kind: "video"
label: "camera2 1, facing front"
muted: false
onended: null
onmute: null
onunmute: null
readyState: "live"
remote: false
__proto__: MediaStreamTrack
 - Click on "Join". After a short time the video is stopped
 - Inspect the status of the local stream again:
temp1.getVideoTracks()[0]
MediaStreamTrack
enabled: true
id: "ac9ec41a-4da8-478f-a88b-901efc2ba1f4"
kind: "video"
label: "camera2 1, facing front"
muted: true
onended: null
onmute: null
onunmute: null
readyState: "muted"
remote: false
__proto__: MediaStreamTrack

Hi,

Issue reproduced with the links of the first comment in my Huawey P9 Lite VNS-L31 with Android 6.0.0 and Chrome 54.0.2840.85. When it occurs we can observe the following error with logcat:

   11-21 15:27:00.512 13147 13543 E BufferQueueProducer: [ImageReader-640x480f23m2-13147-0] queueBuffer: BufferQueue has been abandoned
   11-21 15:27:00.513   574 13728 E Surface : queueBuffer: error queuing buffer to SurfaceTexture, -19

After this the error is repeated until the tab in Chrome closes. Attached file contains the full log for reference.

The same error occurs when the stream is added to a peer connection instead of being used to display it in an HTML video tag. This can be reproduced with next link: https://jsfiddle.net/hs86tLdc/47/

Deleted: Chrome-660738.log.zip 2.0 MB

Chrome-660738.log.zip 2.0 MB Download

we are seeing the same problem of video freezing after couple of seconds on latest chrome on android 6 in the following phones: nexus 5, samsung note 5, samsung galaxy S5 and S6.

Any resolution plan? Estimation when there will be a fix?

also get local camera freeze on Android 6 with HTC 10

braveyao@ can you help with triage?

We are able to repro this issue on Samsung Galaxy Note 5 (SM-N920G) / MMB29K , Samsung Galaxy On Nxt (SM-G610F) / MMB29K - able to repro on M56 . M55 , M54, M53,

As per comment# 15  - https://apprtc.appspot.com. able to repro on M52 build too ( The video is stopped) 


Please find the logs and screenrecord @ http://go/chrome-androidlogs1/6/660738

I can't see 627624. it says
Reason: User is not allowed to view this issue

which release is it supposed to be fixed?

Same issue on my brand-new Google Pixel 5".
Really weird: Chrome not working on Google phone. ;)

I've encountered the same issue on Samsung Galaxy S7 Edge, camera freezes after a few seconds after initiated for WebRTC use. Chrome Canary also had the same problem. Any estimated date for the fix?

We do not have permissions to view  issue #627624  which this bug duplicates. how can we track progress and resolution?

Let's open this one for outsiders, as a copy of  issue627624 .

 Issue 627624  has been merged into this issue.

braveyao@, given your comment in [1]:

> The reproduction is too random. But finally I believe the offending cl should be #392397 (Review-Url: https://codereview.chromium.org/1957733003).

(but see my reply in [2] though), you seem to be in the best
place to address this issue since you have a theory, a potential
culprit and the repro steps. You could try e.g. reverting the 
offending CL and verifying it fixes the issue; I might not have a
lot of time on my hands the next few weeks to address this
important regression, so over to you.


[1] https://bugs.chromium.org/p/chromium/issues/detail?id=627624#c14
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=627624#c15

This problem is consistently on brand-new Google Pixel 5, Samsung Galaxy S7, M56 . M55 , M54, M53, Nexus 5i and other devices.
Reproduce it as written in Comment 1 by andrea.k...@cynny.com, Oct 31
It's random but needs only few seconds to see the camera freezing.

I managed to stumble upon this bug with a Pixel, including the
BufferQueueProducer-related log lines, but those are an effect,
not a cause. Immediately after a rotation even, however, I can
see the art GC kicking in, so I'm thinking that we 
(VideoCaptureCamera2.java) should hold on to the ImageReader. I
made a quick CL and have been rotating for a while with no
problem. Stay tuned.

#31: https://codereview.chromium.org/2637853004/

Hello,

i'm new to chromium, but I want to help verify if the fix helps. Is it possible to have access to daily builds? If yes, how?

Best Regards,
Harald

#33: Best way is to use a Chrome Canary. You can check which version
is current and the associated landed revision in https://omahaproxy.appspot.com/.
branch_base_position tells which CLs are in or not.

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

commit 0e3b718d3342338cb1ba21f4e3ba8c508ca807ae
Author: mcasas <mcasas@chromium.org>
Date: Wed Jan 18 21:12:23 2017

Video capture Android: make ImageReader member to allow surviving GC cycles

As explained in the bug, capturing video with e.g. [1] and
rotating some models screen (e.g. my Pixel), ends up borking
VideoCaptureCamera2.java; this CL has a tentative fix based
on the observation that on every rotation the art GC kicks in,
by holding on to the ImageReader instance.

This was also one of the points touched in the alleged
culprit CL [2].

BUG= 660738 

[1] https://simpl.info/getusermedia
[2] https://codereview.chromium.org/1957733003

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

[modify] https://crrev.com/0e3b718d3342338cb1ba21f4e3ba8c508ca807ae/media/capture/video/android/java/src/org/chromium/media/VideoCaptureCamera2.java

Everyone, latest Android Canary (57.0.2986.0) has the #35 patch
and I can't repro the crash.  Can anyone else Verify? 

Hi, 

I tested it today on Nexus 6  (Android 7) and Nexus 5 (Anrdoid 6.0.1) with Chrome Canary (57.0.2986.0) and could not repro the freeze anymore.

Harald

We tested it with Samsung Galaxy S6, Galaxy S7 and Google Nexus 5x, Motorola Moto E and no camera freeze occurred.

Hi,

Tested yesterday with my Huawey P9 Lite VNS-L31 with Android 6.0.0 with Chrome Canary 58.0.2989.0 and could not reproduce the issue.

It worked for us too.thanks.

Will this patch be part of 57 release? can it be part of stable release 56?

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

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

This change is already in 57 Dev, no need to merge