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)
Tracking
(b2g-v2.0 affected, b2g-v2.1 affected)
RESOLVED
FIXED
People
(Reporter: JMercado, Assigned: song)
References
Details
(Whiteboard: [mobile application][blocking][2.0-exploratory-kk][tef-triage][loop in v1.1])
Attachments
(6 files)
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
Reporter | ||
Comment 1•11 years ago
|
||
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?]
status-b2g-v2.0:
--- → affected
status-b2g-v2.1:
--- → affected
Flags: needinfo?(ktucker)
Whiteboard: [2.0-exploratory-kk]
Reporter | ||
Comment 2•11 years ago
|
||
Comment 4•11 years ago
|
||
Please include a logcat for this issue.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Flags: needinfo?(ktucker) → needinfo?(jmercado)
Reporter | ||
Comment 5•11 years ago
|
||
Flags: needinfo?(jmercado)
Reporter | ||
Updated•11 years ago
|
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Comment 6•11 years ago
|
||
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)
Updated•11 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Comment 7•11 years ago
|
||
We don't think this should be a blocker
Whiteboard: [2.0-exploratory-kk] → [mobile app[not blocking]
Updated•11 years ago
|
Whiteboard: [mobile app[not blocking] → [mobile app][not blocking]
Updated•11 years ago
|
Whiteboard: [mobile app][not blocking] → [mobile app][not blocking][2.0-exploratory-kk]
Comment 8•11 years ago
|
||
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).
Comment 9•11 years ago
|
||
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]
Updated•11 years ago
|
Whiteboard: [mobile application][blocking][2.0-exploratory-kk] → [mobile application][blocking][2.0-exploratory-kk][tef-triage]
Updated•11 years ago
|
Assignee: nobody → josea.olivera
Updated•11 years ago
|
Status: NEW → ASSIGNED
Comment 11•11 years ago
|
||
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.
Assignee | ||
Comment 12•11 years ago
|
||
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)
Comment 13•11 years ago
|
||
Cristian, as Borja is on PTO, could you have look at what song describes in comment 12?
Flags: needinfo?(crdlc)
Assignee | ||
Comment 14•11 years ago
|
||
Assignee | ||
Comment 15•11 years ago
|
||
Fixed the bug and created a pull request: https://github.com/mozilla-b2g/firefoxos-loop-client/pull/260
Picture of fix working: https://bug1057145.bugzilla.mozilla.org/attachment.cgi?id=8513098
Comment 16•11 years ago
|
||
Wow, it works as expected. Thank you Song. We'll review the change and land this today!
Comment 17•11 years ago
|
||
Attachment #8513280 -
Flags: review?(crdlc)
Comment 19•11 years ago
|
||
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+
Comment 20•11 years ago
|
||
Landed on master branch at:
https://github.com/mozilla-b2g/firefoxos-loop-client/commit/6dd3cf9575e6155958437825239c9cc6cecd5262
Assignee: josea.olivera → song
Updated•11 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 21•11 years ago
|
||
Landed on 1.1 branch at:
https://github.com/mozilla-b2g/firefoxos-loop-client/commit/d2c9881f2cc8496fc3aaaea160ef6019aad5ea94
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.
Description
•