video from getUserMedia() is inverted (reflected vertically)
Categories
(Core :: WebRTC: Audio/Video, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox67 | --- | affected |
People
(Reporter: karlt, Assigned: dminor)
References
Details
(Keywords: parity-chrome)
Attachments
(1 file)
8.20 KB,
text/plain
|
Details |
e.g. click video on https://mozilla.github.io/webrtc-landing/gum_test.html
Chrome does not demonstrate the bug.
This seems to be an issue talking with the camera, as video from Firefox to Chrome over webrtc is inverted, but video from Chrome to Firefox is not.
Reproduces with 65.0.2. I have not tried other versions.
This is on a 6th generation Lenovo Thinkpad X1 Carbon, the same model supplied by Mozilla to its non-developer employees, but this laptop was not supplied by Mozilla and I do recall two different camera options being available. This camera was the IR option for MS Hello, not the one with the sliding cover.
Reporter | ||
Comment 1•6 years ago
|
||
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Updated•6 years ago
|
Assignee | ||
Comment 2•6 years ago
|
||
There's also this report on reddit: https://www.reddit.com/r/firefox/comments/b2v5a1/upside_down_webcam_in_firefox_webrtc/
Assignee | ||
Comment 3•6 years ago
|
||
Unfortunately there is no existing logging for this, but it would be very helpful to see the values of the following variables around [1]:
apply_rotation
height
frameInfo.videoType
A negative height indicates that the image should be flipped during the conversion. I've seen that in local testing if I force my camera to select RGB24 by removing other capabilities in device_info_ds.cc.
Reporter | ||
Comment 4•6 years ago
|
||
The video is flipped rather than rotated.
apply_rotation=1, width=640, height=-480, frameInfo.videoType=3
according to https://treeherder.mozilla.org/logviewer.html#?job_id=236523040&repo=try
Assignee | ||
Comment 5•6 years ago
|
||
Hi Karl,
This try job has a potential workaround. It would be great if you could try it when you get a chance: https://treeherder.mozilla.org/#/jobs?repo=try&revision=bc5383f9d075dec4cf739d16778d6f456acb1220.
Reporter | ||
Comment 6•6 years ago
|
||
Yes, that avoids the problem, thank you.
Assignee | ||
Comment 7•6 years ago
|
||
The workaround landed in Bug 1539220, so I'm going to resolve this as fixed. Basically, the camera code always assumes that RGB24 values should be flipped [1] which is obviously not the case for some cameras. Since we're planning on switching video capture backends eventually in Bug 1451394, I don't think it is worth spending time trying to fix up the webrtc.org video capture code to avoid this problem. I spent a little time investigating this, and there doesn't seem to be an easy way of determining whether or not the video should be flipped, so we might end up with a list based upon camera model which doesn't great.
Please re-open if the problem shows up again.
Description
•