WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
264288
Ending track on another getUserMedia is not sound
https://bugs.webkit.org/show_bug.cgi?id=264288
Summary
Ending track on another getUserMedia is not sound
Serj Lavrin
Reported
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.
Attachments
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2023-11-13 14:14:33 PST
<
rdar://problem/118355590
>
youenn fablet
Comment 2
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?
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug