Closed Bug 1057145 Opened 11 years ago Closed 11 years ago

[Loop]The Camera feed is shifted to the right during a video call

Categories

(Firefox OS Graveyard :: Gaia::Loop, defect)

ARM
Gonk (Firefox OS)
defect
Not set
blocker

Tracking

(b2g-v2.0 affected, b2g-v2.1 affected)

RESOLVED FIXED
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected

People

(Reporter: JMercado, Assigned: song)

References

Details

(Whiteboard: [mobile application][blocking][2.0-exploratory-kk][tef-triage][loop in v1.1])

Attachments

(6 files)

Attached image Device A.png
Description: When a user centers themselves in the preview at the bottom of the screen, the feed sent to the other device shows them on the far right. Repro Steps: 1) Update a Flame to 20140821030000 on two devices 2) Set up Loop on both devices 3) Have one device video call another 4) Center the video previews on both devices Actual: Both devices show the other feed as shifted to the right. Expected: The video feeds are centered on the other device. Environmental Variables: Device: Flame 2.0 (319 MB) Build ID: 20140821030000 Gaia: ed257456c512c3b345f5a89e9211581e7ae0f1c0 Gecko: 6329352ca531b977979451e77e5862af485388b2 Version: 32.0 (2.0) Firmware Version: 165 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Loop version: 8c71431 Repro frequency: 100% See attached: screenshots
This issue does occur on 2.1 Flame, 2.0 Flame on the v123 base, 2.0 Flame (512 MB) on the v165 base and 2.0 OpenC. The video feeds are shifted to the right on the receiving device. Environmental Variables: Device: Flame Master BuildID: 20140821040201 Gaia: 3584b2723412ed3299c6761f465885d80651c87e Gecko: dac8b4a0bd7c Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Environmental Variables: Device: Flame 2.0 BuildID: 20140821000201 Gaia: 60cedd4aa6ba408174bcd20a7bf774e73f927674 Gecko: 45eca5871dd0 Version: 32.0 (2.0) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Environmental Variables: Device: Flame 2.0 (512 MB) Build ID: 20140821030000 Gaia: ed257456c512c3b345f5a89e9211581e7ae0f1c0 Gecko: 6329352ca531b977979451e77e5862af485388b2 Version: 32.0 (2.0) Firmware Version: 165 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Environmental Variables: Device: Open_C 2.0 BuildID: 20140821000201 Gaia: 60cedd4aa6ba408174bcd20a7bf774e73f927674 Gecko: 45eca5871dd0 Version: 32.0 (2.0) Firmware Version: P821A10V1.0.0B06_LOG_DL User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Whiteboard: [2.0-exploratory-kk]
The 2.0 Flame on the v123 base in comment 1 is on 319 MB.
Please include a logcat for this issue.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Flags: needinfo?(ktucker) → needinfo?(jmercado)
Flags: needinfo?(jmercado)
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Massimo, can you take look at this issue and weigh in on whether or not this should be nominated as a blocker?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(mbarone976)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
We don't think this should be a blocker
Whiteboard: [2.0-exploratory-kk] → [mobile app[not blocking]
Whiteboard: [mobile app[not blocking] → [mobile app][not blocking]
Whiteboard: [mobile app][not blocking] → [mobile app][not blocking][2.0-exploratory-kk]
Attached image Desktop to Flame
I just tried a Desktop - Flame call using the latest loop master (via link sharing). Here's the screenshot that I get. You can see that the flame device only shows a small proportion of my local camera, and its so far off centre that my face isn't even on the screen. This is using a Flame 2.2 build (35.0a1), build id 20140918040210, with a Mac Book Pro with a Logitech 1080p HD camera (I forget the model).
Testing a call between Desktop and Flame, the camera feed is left to the right even more than in the screenshot attached by Mark. So changing the severity of the bug to blocker due to the Desktop-FirefoxOS scenario.
Severity: normal → blocker
Whiteboard: [mobile app][not blocking][2.0-exploratory-kk] → [mobile application][blocking][2.0-exploratory-kk]
Whiteboard: [mobile application][blocking][2.0-exploratory-kk] → [mobile application][blocking][2.0-exploratory-kk][tef-triage]
Assignee: nobody → josea.olivera
Status: NEW → ASSIGNED
Update: We are blocked here and need some help from our friends at Tokbox. Song is having a look. I hope we can keep us updated about his progress.
Flags: needinfo?(mbarone976)
I think I have identified the problem. In call_screen/style/oncall.css I noticed that you are changing the css of opentok elements. This causes unexpected behavior and is very hard to debug, I'd advise against it: https://github.com/mozilla-b2g/firefoxos-loop-client/blob/master/app/call_screen/style/oncall.css#L737 I have successfully reproduced the bug in this sample code: http://jsbin.com/joxeju/5/edit The easiest fix is to remove lines to style OT_video-container: https://github.com/mozilla-b2g/firefoxos-loop-client/blob/master/app/call_screen/style/oncall.css#L737 If you want the stream to fill a parent element, the best practice is to apply your css to ONLY the parent element (that you created). Then when you call session.subscribe, pass in the following properties: {insertMode: 'append', width: "100%", height: "100%"} This will create an OpenTok element that fills up your parent element and you won't need to touch any of opentok elements (video and .OT_video-container)
Cristian, as Borja is on PTO, could you have look at what song describes in comment 12?
Flags: needinfo?(crdlc)
Attached image fixed centering issue
Wow, it works as expected. Thank you Song. We'll review the change and land this today!
seems there is a patch here
Flags: needinfo?(crdlc)
Comment on attachment 8513280 [details] [review] Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/260 LGTM and it works like a charm. Left a comment, please address before merging, thanks a lot, good job
Attachment #8513280 - Flags: review?(crdlc) → review+
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [mobile application][blocking][2.0-exploratory-kk][tef-triage] → [mobile application][blocking][2.0-exploratory-kk][tef-triage][loop in v1.1]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: