[Webkit-unassigned] [Bug 179363] iOS calling getUserMedia() again kills video display of first getUserMedia()

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=179363

--- Comment #5 from youenn fablet <youennf at gmail.com> ---
>  - It's common practice to show a user their own local video feed with one
> (higher resolution) stream, and publish another (lower resolution) stream to
> other users

Understood that this is not optimal, although in most UI, the local video track usually takes a smaller part of the screen than the remote video track.
Also applyConstraints should be the solution for changing the resolution of a given video track.

At this point, it is not feasible to have two tracks with different resolutions. Ideally, this should be feasible using MediaStream cloning and applyConstraints.

Note that general support for multiple video streams might not always be feasible, in particular if the streams are coming from multiple capture devices.

>  - To accommodate receivers with different bandwidth capabilities, a common
> practice is to publish both a high resolution and a low resolution stream

Simulcast might be a better option there.

(In reply to daginge from comment #4)
> Just chiming in here. This is a blocker for us in switching between front
> and back camera on Safari iOS. At least with minimal disruption to the user
> experience.

I would be interested in what disruption you encounter.
The following is expected to work without too much trouble:

navigator.mediaDevices.getUserMedia({video: { facingMode: "user"} }).then((s) => {
   localVideo.srcObject = s;
   peerConnection.getSenders()[0].replaceTrack(s.getVideoTracks()[0]);
});

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180629/ed6b50d3/attachment.html>