New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 691588 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Remote videostream disappears if local mediastream is changed and localdescription of peerconnection is updated

Reported by ige...@gmail.com, Feb 13 2017

Issue description

Steps to reproduce the problem:
1. Establish a video call between two parties
2. stop local mediaStream tracks
3. remove local mediaStream from peerconnection
4. get a new one with different videoinput id (usually this is front camera)
5. add new mediaStream to peerconnection
6. create offer and set local description, it is not required to send new description to other side
7. local videostream is updated to show data from a different camera

What is the expected behavior?
remote videostream should not disappear

What went wrong?
remote videostream disappears

Did this work before? Yes 53.0.2785.97

Does this work in other browsers? N/A

Chrome version: 55.0.2883.91  Channel: stable
OS Version: 6.0.1 MMB29M
Flash Version: 

Remote device has to be in portrait mode in order to reproduce this bug. Also Android 5 devices seem not to have this problem

 
Owner: guidou@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 2 by faro...@gmail.com, Feb 14 2017

same problem with us. after the camera is switched from front to back or vice versa, we see this warning: error code=-7 seems to be WEBRTC_VIDEO_CODEC_UNINITIALIZED

Comment 3 by faro...@gmail.com, Feb 14 2017

we also tested this with chrome 56 and chrome 57 beta version. we saw the same behavior: the remote video stream disappears

Comment 4 Deleted

Cc: magjed@chromium.org
Guido, are you looking at this? Should it be re-assigned to the Video team?

Comment 6 by ige...@gmail.com, Apr 10 2017

hi! do you need any extra information on the issue? Maybe some specific logs or something?

Comment 7 by faro...@gmail.com, May 3 2017

any action on this bug?
Ping.
Ping :)
Owner: hbos@chromium.org
hbos@: Can you take a look at this and retriage if necessary?

Comment 11 by hbos@chromium.org, Sep 8 2017

I'll take a look on monday

Comment 12 by hbos@chromium.org, Sep 12 2017

Status: Started (was: Assigned)
Maybe it's still monday in some timezone? Taking a look.

Comment 13 by hbos@chromium.org, Sep 12 2017

Labels: Needs-Feedback
Status: WontFix (was: Started)
I think this is intended behavior. If you stop the tracks and remove them they will stop being sent.

In order to get the new stream/track displayed on the remote side renegotiation is required, you have to setRemoteDescription again and with the stream/track events fired, wire up the remote view to use the new track.

With replaceTrack you'll be able to do this without renegotiation.

igeeko@: I'm closing as WontFix (works as intended). If this is incorrect, please comment.

Sign in to add a comment