[B2G][Email][Camera] Camera video becomes unresponsive/ crashes when adding video as email attachment in 480p

RESOLVED WORKSFORME

Status

Firefox OS
Gaia::Camera
RESOLVED WORKSFORME
4 years ago
4 years ago

People

(Reporter: njpark, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Sibling bug of bug 1043724 to track 480p issue.
STR:
1)change  https://github.com/mozilla-b2g/gaia/blob/master/apps/camera/js/config/config.js so that the 'exclude' property includes '720p'. The Camera app will fall back to 480p.
do make reset-gaia to build and flash gaia to flame device
2) Launch the Email app and log in with valid credentials.
3) Tap the Compose icon then the attachment icon.
4) Select Camera.
5) Tap the camera/video switch to activate video mode.
6) Tap the record button and observe the video feed.

Actual:
After a couple of seconds the video becomes laggy, and tapping the record button usually returns no response.

Expected:
The video is recorded with no lag for the entire recording length, and the video stops immediately when the record button is tapped again.

Actual:
286MB Flame v123 w/ 480p directly launching Camera app: records fine, no stutter
286MB Flame v123 w/ 480p launching Camera app from email app: OOMs
319MB Flame v123 w/ 480p directly launching Camera app: records fine, no stutter
319MB Flame v123 w/ 480p launching Camera app from email app: no stutter

Version Info:
Gaia      8cc28fd31905a0ea2b2e15d13e80a0eab2feb1ba
Gecko     https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/25980b5120b0
BuildID   20140807000201
Version   32.0
ro.build.version.incremental=110
ro.build.date=Fri Jun 27 15:57:58 CST 2014
1.4 data from the other bug is:

286MB Flame v123 w/ 480p directly launching Camera app: records fine, no stutter
286MB Flame v123 w/ 480p launching Camera app from email app: initially there is stutter, but that goes away and records normally.
No-Jun - Could you put a github branch online that the contractors can flash to test 480p on 1.4 & 2.0?

Context - I'd like to ask the contractors to determine a breakdown of the behavior across memory settings from 286 MB to 319 MB. Something like:

286 MB - 1.4: stutter, but record, 2.0: OOM
....
319 MB - 1.4: no stutter, 2.0: ?

Flagging qawanted to do this task after No-Jun preps the branches.
Flags: needinfo?(npark)
Keywords: qawanted
QA Contact: jmercado
(Reporter)

Comment 3

4 years ago
Hmm, right now 1.4 and 2.0 branch in B2G does not have flame-kk manifest.  I raised bug 1054311 in General, could you move this bug to appropriate place?

In the meantime, for non-480p testing, contractors can use the daily CI build that William Hsu set up for 2.0.  I have sent instructions for PBylenga.  I can post the instruction in the comment if it isn't confidential.  However, changing the resolution to 480p requires rebuild of gaia so I need to figure out how did William built 2.0.
Flags: needinfo?(npark) → needinfo?(jsmith)
(Reporter)

Updated

4 years ago
Depends on: 1054311
(Reporter)

Comment 4

4 years ago
I created a 2.0 gaia branch with camera set to 480p here:
https://github.com/npark-mozilla/gaia/tree/2.0

clone the branch, and do 'git fetch upstream' to get the latest from the main tree.  afterwards, do make reset-gaia to build and flash the device to 2.0 gaia.

There is no change needed to set the camera to 480p for gecko, so getting the 2.0 gecko from William's CI build depot should be fine.
(Reporter)

Comment 5

4 years ago
in 2.0 KK:
286MB Flame v123 w/ 480p directly launching Camera app: initial stutter, later records fine
286MB Flame v123 w/ 480p launching Camera app from email app: initial stutter, OOMs after 5-6 seconds
319MB Flame v123 w/ 480p directly launching Camera app: records fine, no stutter
319MB Flame v123 w/ 480p launching Camera app from email app: no stutter
Okay, so that works for 2.0. But what about 1.4? We need to be able to test 1.4 as a point of reference to see if there was a memory regression here between releases on Flame kitkat.
Flags: needinfo?(jsmith) → needinfo?(npark)
(Reporter)

Comment 7

4 years ago
(In reply to Jason Smith [:jsmith] from comment #6)
> Okay, so that works for 2.0. But what about 1.4? We need to be able to test
> 1.4 as a point of reference to see if there was a memory regression here
> between releases on Flame kitkat.

Yes, at the moment Viral is working on creating the final manifest for 1.4 and 2.0. Once the dependency bug 1054311 is resolved, I'll work on 1.4 gaia branch.
Flags: needinfo?(npark)
Okay. At a minimum, let's proceed forward with doing the qawanted request at least for 2.0.
(Reporter)

Comment 9

4 years ago
(In reply to Jason Smith [:jsmith] from comment #8)
> Okay. At a minimum, let's proceed forward with doing the qawanted request at
> least for 2.0.

So... that's in Comment 5  for following KK build.  Let me know if you need additional information other than the following version info:

Gaia      1a215917df01bb815811f33665bd3fdca4130708
Gecko     d52b2995e5ea00867eeb425c10131c96e84bd55a
BuildID   20140818143909
Version   32.0
ro.build.version.incremental=18
ro.build.date=Thu Aug 14 19:29:46 CST 2014
Created attachment 8480235 [details]
Memory results.txt

At 304 MB the camera no longer has performance issues on 2.0 Flame with the 165 KK base.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140826030000
Gaia: 1de9e49fc7e3e679f589178e6fbd67903b496ca1
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
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?]
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
No-Jun, is this still an issue with recent builds?
Flags: needinfo?(npark)
(Reporter)

Comment 12

4 years ago
(In reply to Mike Habicher [:mikeh] from comment #11)
> No-Jun, is this still an issue with recent builds?

Hmm, with the latest master build and v184 firmware, I cannot reproduce this issue.  Do you want me to test it with 2.0 and 2.1 with v184 as well?
Flags: needinfo?(npark)
Thanks, No-Jun. The bug was originally filed on 2.0, so it would be good retest that and 2.1 as well, if you have time.
Flags: needinfo?(npark)
(Reporter)

Comment 14

4 years ago
This is no longer reproducible in 2.0 and 2.1 with v184 base image.  Will close this issue.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(npark)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.