You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let assume an app in which the user can choose the webcam device in a drop list and get a preview of it. If he selects a front camera, the preview <video> element must enable CSS transform: scaleX(-1); (mirror effect). If he selects a back/rear camera, no mirror effect must be applied.
This seems to be a very common scenario. But AFAIK it's unfeasible with the current API.
The drop list is filled with enumerateDevices() by filtering device.kind === 'videoinput', and (assuming a previous permissions prompt) it can display the device.label of the video devices. But from the API point of view, the app has no way to know whether a device in the list is a front or a back camera.
So, the user chooses one, the app gets its device.deviceId and calls getUserMedia() with video: { exact: device.deviceId }. At that point, the app has no way to know whether it must apply the "mirror effect" to the local video or not.
I know about some developers (including me) matching /(back|rear)/i to the device.label. Hope the API can provide something much better than that. Things would be much easier (or just feasible) if DeviceMediaInfo includes more fields such as facingMode.
I may understand that the proper way to go is by calling getUserMedia() with the choosen deviceId (as above) and then inspect the retrieved video MediaStreamTrack.getConstraints(), which seems to include facingMode. However (at least in Firefox which is closer to the spec) track.getConstraints().facingMode is an empty object. Is that because getUserMedia() was NOT called with a facingMode constrain?
If so, the same problem as the above described applies.
The text was updated successfully, but these errors were encountered:
Let assume an app in which the user can choose the webcam device in a drop list and get a preview of it. If he selects a front camera, the preview
<video>
element must enable CSStransform: scaleX(-1);
(mirror effect). If he selects a back/rear camera, no mirror effect must be applied.This seems to be a very common scenario. But AFAIK it's unfeasible with the current API.
The drop list is filled with
enumerateDevices()
by filteringdevice.kind === 'videoinput'
, and (assuming a previous permissions prompt) it can display thedevice.label
of the video devices. But from the API point of view, the app has no way to know whether a device in the list is a front or a back camera.So, the user chooses one, the app gets its
device.deviceId
and callsgetUserMedia()
withvideo: { exact: device.deviceId }
. At that point, the app has no way to know whether it must apply the "mirror effect" to the local video or not.I know about some developers (including me) matching
/(back|rear)/i
to thedevice.label
. Hope the API can provide something much better than that. Things would be much easier (or just feasible) ifDeviceMediaInfo
includes more fields such asfacingMode
.I may understand that the proper way to go is by calling
getUserMedia()
with the choosendeviceId
(as above) and then inspect the retrieved videoMediaStreamTrack.getConstraints()
, which seems to includefacingMode
. However (at least in Firefox which is closer to the spec)track.getConstraints().facingMode
is an empty object. Is that becausegetUserMedia()
was NOT called with afacingMode
constrain?If so, the same problem as the above described applies.
The text was updated successfully, but these errors were encountered: