Bug 264288 - Ending track on another getUserMedia is not sound
Summary: Ending track on another getUserMedia is not sound
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebRTC (show other bugs)
Version: Safari 16
Hardware: iPhone / iPad iOS 16
: P2 Minor
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2023-11-06 14:13 PST by Serj Lavrin
Modified: 2023-11-15 06:17 PST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Serj Lavrin 2023-11-06 14:13:57 PST
On iOS, when requesting camera video through getUserMedia twice, it ends the existing MediaStreamTrack. This change was implemented in https://bugs.webkit.org/show_bug.cgi?id=179363.

That might be an expected situation when _exactly_ the same device is requested twice. However, on iPhone, it works that way even if a different camera module is requested or even if there's already an existing front camera track and back camera being requested.

This behavior is problematic for several reasons:

	1.	It is unpredictable. Even when using getUserMedia with a different device id and `groupId` from an existing MediaStreamTrack, there is no guarantee that it won't stop any of the existing tracks.
	2.	It is non-deterministic. There is no way to determine in advance if the requested devices belong to a group that is already in use.
	3.	It is inconsistent with other operating systems. On Windows, a device that can't be used twice raises an explicit exception in getUserMedia, the same as on Android. On MacOS, it is possible to reuse the same devices without any restrictions.

All of this makes it difficult to use when a service allows users to work with multiple cameras because it is not possible to know which device is already in use. While it's understandable that the main or front camera can't be reused, a user could have an external device connected, and currently, there is no way to determine if it's part of the device's camera modules.

Here are a few proposed solutions to address this issue:

	1.	Instead of ending the existing MediaStreamTrack, raise an explicit "not allowed" error when a getUserMedia request is made with a constrained device ID that matches a device already in use. This approach would ensure consistency across all operating systems and browsers.
	2.	Use the same groupId for all iPhone/iPad cameras in MediaDeviceInfo. While this is not ideal because other devices might have a shared group ID and support simultaneous use of each device, it would at least provide a way to identify that the requested track probably belongs to the same device and exclude it from the list of options.
	3.	Add an identifier to the MediaDeviceInfo label that indicates it is the device's built-in camera, regardless of the system locale. Currently, the label does not clearly indicate that it's built-in (e.g., "Front Camera," "Back Triple Camera"), and it is also localized, with unique labels for each of the 41 languages supported by iOS.
	4.	Allow front and back cameras to work simultaneously.
Comment 1 Radar WebKit Bug Importer 2023-11-13 14:14:33 PST
<rdar://problem/118355590>
Comment 2 youenn fablet 2023-11-15 06:17:56 PST
Camera concurrent access is very restricted on iOS.
The current support on iOS is as follow:
- If a page captures with a camera A, and it tries to capture with a camera B, the camera A track will be ended
- If a page captures with a camera A and it tries to capture (call getUserMedia) with the same camera A, both tracks will be ok.

Can you clarify what you are after?
Is the request to capture with both back and forward camera concurrently?