1043724 - [B2G] [Email] [Camera] Camera video becomes unresponsive when attempting to record it as an email attachment

Status: RESOLVED WONTFIX

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

Description

[Chris Kreinbring [:CKreinbring]]

Attachment: Log of laggy video recording

Description:
If a user attempts to record a video to add it as an attachment to an email, the interface will become laggy and unresponsive while it is recording.

Repro Steps:
1) Update a Flame to 20140724000201
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.

Environmental Variables:
Device: Flame 2.0
Build ID: 20140724000201
Gaia: 29266e18c35f4e72e35f1bba0e34f2fb6b995cc3
Gecko: 178fe2efc41d
Platform Version: 32.0
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Repro frequency: 100%
See attached video clip and logcat logs

Comment 1

[Joshua Mitchell (Inactive)]

QA-Wanted for branch checks

Comment 2

[Chris Kreinbring [:CKreinbring]]

The bug repros on Flame 2.1 (319 MB)

Build ID: 20140730040205
Gaia: 25e998814ba89f30fe44cd2fdfbb44d160a04641
Gecko: 55c4d770f88b
Platform Version: 34.0a1
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Actual result: After tapping the record button while attempting to create an email attachment, the viewfinder will become very laggy and the buttons will be difficult to interact with.

--------------------------------------------------------------------------------------------------------

The bug does not repro on Flame 2.0 (512 MB), Flame 1.4 (319 MB), Buri 2.0 and Open C 2.0

Flame 2.0 (512 MB)
Build ID: 20140729000201
Gaia: b11775fcbfe076a3fc560c2041f5b2fe1b345009
Gecko: 86b56e101512
Platform Version: 32.0
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 1.4
Build ID: 20140729000201
Gaia: eb3b185325901d4c04e2d43eb58d90835213bea9
Gecko: 8c8883bb5797
Platform Version: 30.0
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Buri 2.0
Build ID: 20140729000201
Gaia: b11775fcbfe076a3fc560c2041f5b2fe1b345009
Gecko: 86b56e101512
Platform Version: 32.0
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Open C 2.0
Build ID: 20140729000201
Gaia: b11775fcbfe076a3fc560c2041f5b2fe1b345009
Gecko: 86b56e101512
Platform Version: 32.0
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Actual result: After tapping the record button while attempting to create an email attachment, the viewfinder will remain smooth and the buttons respond immediately when tapped.

Comment 3

[Joshua Mitchell (Inactive)]

[Blocking Requested - why for this release]: regression in a major feature (email and cam) in a highly probable user path (mid - high visibility)

Comment 4

[Hema Koka [:hema]]

Marcia, can you also try to reproduce this on Open 2?

Mike or Andrew - can one of you investigate this on Flame with 319MB to see if this is an issue on the camera side (looks like this is not reproducible in other configs)

Comment 5

[Mike Habicher [:mikeh] (high bugzilla latency)]

I don't see this on Flame/319:
- gonk:  v123
- gecko: b2g-inbound:195943:8dc3c0b11f4d
- gaia:  master:dd8d9ad3e6ad7a0ed778353a745eda4cae44fcb4

Will try to reproduce with more recent gecko/gaia.

Chris, it would help if we had a video demonstrating the issue.

Comment 6

[Mike Habicher [:mikeh] (high bugzilla latency)]

Nevermind, I just noticed the YT link up above (http://youtu.be/049ACxlh1HU). I don't see anything like what's in that video.

Comment 7

[Jason Smith [:jsmith]]

QA Wanted - Can we have a retest on 319 MB Flame on 2.0 & 2.1?

Comment 8

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Issue still occurs as written on the latest Flame 2.1 and Flame 2.0 builds running 319 MB.  When trying to record a video to add as an attachment to an email, the video recorder becomes laggy and unresponsive.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140731042106
Gaia: 794cae6a38bb9c517f362fde75b95f91e7c28bd8
Gecko: 34a7fa40265a
Version: 32.0 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Environmental Variables:
Device: Flame Master
BuildID: 20140730141509
Gaia: b67ddd7d40b52e65199478b8d6631c2c28fdf41d
Gecko: 005424a764da
Version: 34.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 9

[Joshua Mitchell (Inactive)]

This was one of the most difficult windows I have seen. There was an issue that when you go back in time over builds there is not a definitive 'broken' state and 'working' state - but levels of unresponsiveness and lag. We did our best to identify a Last Working and First Broken - and there is a significant difference in the performance. Unfortunately the initial push-log indicated Both B2G-inbound AND Mozilla-inbound changes so we had to do both windows. Jayme is the Qa-Contact but I closely double-checked his work and feel that this is a "as-good-as-it-gets" window. Additionally there are a TON of changes in each pushlog even though the window is only 2 hours big - they pushed a lot of changes in those 2 hours. I am posting all the windows below.

Mozilla Central Regression Window

Last Working
Environmental Variables:
Device: Flame Master
BuildID: 20140501103002
Gaia: f98b024ffd52b55ea3fa18ece0ed8742d970d4ef
Gecko: 35f9431188ca
Version: 32.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


First Broken
Environmental Variables:
Device: Flame Master
BuildID: 20140501193006
Gaia: 386b5478eb9c3970972966123517e993e8a1092a
Gecko: e2e1b19fcffc
Version: 32.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Last Working Gaia First Broken Gecko: Issue does reproduce
Gaia: f98b024ffd52b55ea3fa18ece0ed8742d970d4ef
Gecko: e2e1b19fcffc

First Broken Gaia Last Working Gecko: Issue does not reproduce
Gaia: 386b5478eb9c3970972966123517e993e8a1092a
Gecko: 35f9431188ca

Gecko Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=35f9431188ca&tochange=e2e1b19fcffc

-------------------------------------------------------------------------------------------
B2g-inbound Regression Window

Last Working
Environmental Variables:
Device: Flame Master
BuildID: 20140429083002
Gaia: feef47764b9ae49fa5cc28a07186db7905481297
Gecko: 81dc74c9a5a2
Version: 32.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

First Broken
Environmental Variables:
Device: Flame Master
BuildID: 20140429113000
Gaia: db3bcec51a361daddb7d3d4ba4d8a2a664b7b6aa
Gecko: fbcdaf0a6aeb
Version: 32.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Last Working Gaia / First Broken Gecko - Issue DOES occur 
Gaia: feef47764b9ae49fa5cc28a07186db7905481297
Gecko: fbcdaf0a6aeb

First Broken Gaia /  Last Working Gecko - Issue does NOT occur
Gaia: db3bcec51a361daddb7d3d4ba4d8a2a664b7b6aa
Gecko: 81dc74c9a5a2

Gecko Pushlog: https://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=81dc74c9a5a2&tochange=fbcdaf0a6aeb

-----------------------------------------------------------------------------------------
Mozilla-inbound Regression Window

Last Working
Environmental Variables:
Device: Flame Master
BuildID: 20140429073004
Gaia: 725a23802708eb70e3d7e8a2ce7179adbac806e4
Gecko: e8f577aa0d07
Version: 32.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

First Broken
Environmental Variables:
Device: Flame Master
BuildID: 20140429103004
Gaia: 1892ba3a857f7e9cd1d2a0cf1c87481f3dcaca2c
Gecko: cb62031a7b51
Version: 32.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Last Working Gaia / First Broken Gecko - Issue DOES occur
Gaia: 725a23802708eb70e3d7e8a2ce7179adbac806e4
Gecko: e8f577aa0d07

First Broken Gaia /  Last Working Gecko - Issue does NOT occur
Gaia: 1892ba3a857f7e9cd1d2a0cf1c87481f3dcaca2c
Gecko: cb62031a7b51

Gecko Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e8f577aa0d07&tochange=cb62031a7b51

Comment 10

[Preeti Raghunath(:Preeti)]

Per YT lin looks bad and hence blocking

Comment 11

[Diego Marcos [:dmarcos]]

Is the regression window the same with OEM build v123?

Comment 12

[Diego Marcos [:dmarcos]]

(In reply to Jayme Mercado [:JMercado] from comment #8)
> Issue still occurs as written on the latest Flame 2.1 and Flame 2.0 builds
> running 319 MB.  When trying to record a video to add as an attachment to an
> email, the video recorder becomes laggy and unresponsive.
> 
> Environmental Variables:
> Device: Flame 2.0
> BuildID: 20140731042106
> Gaia: 794cae6a38bb9c517f362fde75b95f91e7c28bd8
> Gecko: 34a7fa40265a
> Version: 32.0 (2.0) 
> Firmware Version: v122
> User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
> 
> Environmental Variables:
> Device: Flame Master
> BuildID: 20140730141509
> Gaia: b67ddd7d40b52e65199478b8d6631c2c28fdf41d
> Gecko: 005424a764da
> Version: 34.0a1 (Master) 
> Firmware Version: v122
> User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

We should be using Firmware v123

Comment 13

[Joshua Mitchell (Inactive)]

Diego - my office has not been given the go-ahead to move over to v123 however we do have access to it and can test on it.


Qa-wanted to verify regression-window with v123

Comment 14

[Diego Marcos [:dmarcos]]

The problem doesn't reproduce recording from the messages application because it limits the size of the  video when launching the pick activity. That's understandable because MMS are limited to 300Kb.

if (Settings.mmsSizeLimitation) {
  activityData.maxFileSizeBytes = Settings.mmsSizeLimitation;
}

activity = new MozActivity({
  name: 'pick',
  data: activityData
});

Email doesn't limit the size of the pick activity and the video gets recorded at full size: 720p in flame
319 MB is not enough memory to have the email app application opened while recording 720p video at the same time.

The bug doesn't reproduce while recording video with the front camera because it has a cif (352 x 288) maximum resolution.

This bug is again a consequence of using flame to simulate a low end device by just limiting the amount of memory. As far as I know, there are no devices in the market with 256MB with cameras capable of recording 720p video. The issue won't hit any user. I want to flag this as a WONTFIX. 

ni Mike and Hema for alternative points of view.

Comment 15

[Jason Smith [:jsmith]]

(In reply to Diego Marcos [:dmarcos] from comment #14)
> The problem doesn't reproduce recording from the messages application
> because it limits the size of the  video when launching the pick activity.
> That's understandable because MMS are limited to 300Kb.

So why can't we do the same with email here?

> 
> if (Settings.mmsSizeLimitation) {
>   activityData.maxFileSizeBytes = Settings.mmsSizeLimitation;
> }
> 
> activity = new MozActivity({
>   name: 'pick',
>   data: activityData
> });
> 
> Email doesn't limit the size of the pick activity and the video gets
> recorded at full size: 720p in flame
> 319 MB is not enough memory to have the email app application opened while
> recording 720p video at the same time.

Why are we recording at 720p if we know we can't support it on 319 MB? Shouldn't the camera be able to detect that's a memory limitation here and adjust accordingly? 2.1 I know supports memory detection, so I would think this should be possible. 2.0 would likely have to use a different methodology though.

> 
> The bug doesn't reproduce while recording video with the front camera
> because it has a cif (352 x 288) maximum resolution.
> 
> This bug is again a consequence of using flame to simulate a low end device
> by just limiting the amount of memory. As far as I know, there are no
> devices in the market with 256MB with cameras capable of recording 720p
> video. The issue won't hit any user. I want to flag this as a WONTFIX. 

The agreement we established on drivers was that 319 MB Flame was going to be a minimum spec, so I would rather avoid going down a path of increasing the memory size again for Flame to get around this issue, as we are placing more risk of not being able to detect low memory issues. I would argue that we should instead either 1) fix this by implementing the same limitation the messages app on the email app 2) adjust accordingly in the camera app when you detect the memory is below a certain value.

Comment 16

[Diego Marcos [:dmarcos]]

(In reply to Jason Smith [:jsmith] from comment #15)
> (In reply to Diego Marcos [:dmarcos] from comment #14)
> > The problem doesn't reproduce recording from the messages application
> > because it limits the size of the  video when launching the pick activity.
> > That's understandable because MMS are limited to 300Kb.
> 
> So why can't we do the same with email here?

Emails doesn't have the same limitations as MMS. What size is reasonable for an email attachment is a decision of the email application not camera. 

> 
> > 
> > if (Settings.mmsSizeLimitation) {
> >   activityData.maxFileSizeBytes = Settings.mmsSizeLimitation;
> > }
> > 
> > activity = new MozActivity({
> >   name: 'pick',
> >   data: activityData
> > });
> > 
> > Email doesn't limit the size of the pick activity and the video gets
> > recorded at full size: 720p in flame
> > 319 MB is not enough memory to have the email app application opened while
> > recording 720p video at the same time.
> 
> Why are we recording at 720p if we know we can't support it on 319 MB?
> Shouldn't the camera be able to detect that's a memory limitation here and
> adjust accordingly? 2.1 I know supports memory detection, so I would think
> this should be possible. 2.0 would likely have to use a different
> methodology though.

Nobody reasonable is going to ship to the market a phone with 256 MB of memory and a 720p camera. You're pairing 2007 memory specs with a 2010-2011 camera HW. It's not a configuration we should be caring about. The iPhone didn't get 720p video until the iphone4 and it had 512 MB of memory. Adding special code paths and checks for non existing hardware adds unnecessary complexity to the code.

> 
> > 
> > The bug doesn't reproduce while recording video with the front camera
> > because it has a cif (352 x 288) maximum resolution.
> > 
> > This bug is again a consequence of using flame to simulate a low end device
> > by just limiting the amount of memory. As far as I know, there are no
> > devices in the market with 256MB with cameras capable of recording 720p
> > video. The issue won't hit any user. I want to flag this as a WONTFIX. 
> 
> The agreement we established on drivers was that 319 MB Flame was going to
> be a minimum spec, so I would rather avoid going down a path of increasing
> the memory size again for Flame to get around this issue, as we are placing
> more risk of not being able to detect low memory issues. I would argue that
> we should instead either 1) fix this by implementing the same limitation the
> messages app on the email app 2) adjust accordingly in the camera app when
> you detect the memory is below a certain value.

We don't have to increase memory in Flame. If we are going to simulate a low end device the other components have to be paired accordingly: Screen size, camera resolution, CPU speed. It's like having a Macbook Pro with retina display, getting rid of 75% of the memory and expect that everything is going to work fine.

Comment 17

[Diego Marcos [:dmarcos]]

My recommendation is flagging this as WONTFIX if it doesn't reproduce on a production 256 MB device (QRD or Buri)

Comment 18

[Jason Smith [:jsmith]]

(In reply to Diego Marcos [:dmarcos] from comment #17)
> My recommendation is flagging this as WONTFIX if it doesn't reproduce on a
> production 256 MB device (QRD or Buri)

From a reference device perspective, I think this isn't a direction we should pursue. We're trying to strive to build a reference environment for testing & maintain across releases. We can't take a strategy that tries to break reference setups just because it isn't a perfect match to a low end device. We also have proven this is a regression, so there is a performance problem here present here that we should look into. On that regard, I still believe this is an issue that we need to fix.

Comment 19

[Diego Marcos [:dmarcos]]

It's a regression because from 1.4 to 2.0 the b2g memory footprint has gone up across all apps. When you try to record a 720p video the memory usage spikes and on a 316 MB device slows the system down to crawl due to the opened apps competing for the limited resources. The problem is not specific to camera and the solution is complex. As far as I know all the teams are working to reduce memory footprint as much as they can. We've already done work on the camera side on bug 1028253.

The flame in 316 MB memory configuration doesn't fairly represent a low end device. You're pairing low end memory specs with a high resolution screen and camera HW. In the case of this bug, flame is not a valid analog of a low end device.

There won't be in the market any device with such combination of components so no user will be hitting this bug. If no user is affected this should not block.

Comment 20

[Duane Dixon [:ddixon]]

The following results were tested with the v123 Base Image for the Flame device. 

All the Regression Windows are correct from Comment 9. 

Actual Results: User experiences significant lag times while recording a video to attach in an email.


Central Window Check: 
Last Working:  20140501103002  Correct
First Broken:  20140501193006  Correct
----------------------------------------------------------

B2G Inbound Window Check:
Last Working:  20140429083002  Correct 
First Broken:  20140429113000   Correct
----------------------------------------------------------

Mozilla Inbound Check:
Last Working:   20140429073004  Correct 
First Broken:  20140429103004  Correct

Comment 21

[Hema Koka [:hema]]

Based on camera tests run by Mike Habicher on JB based Flame, the results showed:

    a mem limit of 319MB for recording 720p

    a mem limit of 345MB for taking HDR photos (though we artificially limit this to 512MB)

mem limits for 480p recording:

    to somewhere between 273MB and 309MB for a minimum-viable threshold

    to somewhere between 273MB and 319MB to avoid basic background process kills

Is the lag seen only when recording 720p video for email attachment? From comment 5, Mike says he is not able to reproduce it. Is this happening on Open 2?

For 2.0, I believe CAF is testing with 480p and I don't think we have any 256MB devices with 720p targets, so this should not be a release blocker. NI Sri from product to verify that is the case

Comment 22

[Jason Smith [:jsmith]]

(In reply to Hema Koka [:hema] from comment #21)
> Based on camera tests run by Mike Habicher on JB based Flame, the results
> showed:
> 
>     a mem limit of 319MB for recording 720p
> 
>     a mem limit of 345MB for taking HDR photos (though we artificially limit
> this to 512MB)
> 
> mem limits for 480p recording:
> 
>     to somewhere between 273MB and 309MB for a minimum-viable threshold
> 
>     to somewhere between 273MB and 319MB to avoid basic background process
> kills
> 
> Is the lag seen only when recording 720p video for email attachment? From
> comment 5, Mike says he is not able to reproduce it. Is this happening on
> Open 2?

I don't think Open II is comparable here, since Open II uses a different recording profile then what is being tested here (720p).

> 
> For 2.0, I believe CAF is testing with 480p and I don't think we have any
> 256MB devices with 720p targets, so this should not be a release blocker. NI
> Sri from product to verify that is the case

I think this breaks the requirement we placed on the minimal requirements for camera recording, since we stated up front that 720p needs to work on 319 MB Flame as the bare minimum. Not fixing this means we're no longer meeting this requirement, so we either need to change the minimal requirements or fix this to maintain hitting the minimal requirements here.

Comment 23

[Jason Smith [:jsmith]]

Hema & I discussed this in person a bit more. My understanding based on the in person discussion is that:

* 720p requires a 512 MB Flame device as a minimum
* Initially, we thought 319 MB was enough for the Flame, but this bug revealed that might not be true
* QRD reference setup is 480p w/256 MB

What we should do here is:

* Drop this from the blocking list, as this works fine under the minimal requirements for 720p in production devices (512 MB)
* Check if this happens with 286 MB Flame w/480p recording
* Check if this happens with Open II

I've asked Mike offline if he spin a github branch with the config change to have 480p enabled on Flame, so once we have that, then we'll be able to do the 480p check on 286 MB Flame. We should be able to do the Open II check now though.

Comment 24

[No-Jun Park [:njpark]]

Just verified with 319MB Flame device with camera set to 480p, and the issue does not reproduce on 2.0

Comment 25

[No-Jun Park [:njpark]]

with 286MB Flame (Base Image v123) w/480p recording, the camera app freezes upon startup (a black screen appears- no preview) on 2.0 Build

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

Comment 26

[No-Jun Park [:njpark]]

Actually, on 2nd try, it worked, and it did not show the stuttering issue either.  I can't seem to reproduce the black screen issue i saw from above comment after rebooting the phone.  Perhaps I needed to restart the phone after loading gaia.  will check for more info.

Comment 27

[No-Jun Park [:njpark]]

Sorry for keep providing incomplete info.  in Comment 26, only then camera app was started.  When camera app was triggered from email attachment menu, once switched to video mode, it OOMed and exited to the email app.

Comment 28

[No-Jun Park [:njpark]]

Summary:
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

Comment 29

[Jason Smith [:jsmith]]

(In reply to No-Jun Park [:njpark] from comment #28)
> Summary:
> 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

So what I think that implies is that 286 MB Flame w/480p also has this bug reproduce.

Mike - Should we reconsider how much memory we need by default then for 480p & 720p? Or should we keep the same memory and look into figuring out why we have insufficient memory to record a video via an email attachment?

Comment 30

[Mike Habicher [:mikeh] (high bugzilla latency)]

With Flame/KK/286, recording a 480p video, when I stop recording, I see:

# adb shell dmesg | grep sigkill
<6>[ 2766.226964] send sigkill to 946 (Homescreen), adj 534, size 1150
<6>[ 2766.766611] send sigkill to 3805 (E-Mail), adj 134, size 2427

- gonk:  v162-3
- gecko: master:a7cf4142b4a5c50e95b6929de4141ca55b135d33
- gaia:  master:c97d1b6c3094e854377b6affa5f46b8d4b7316ce

Comment 31

[Jason Smith [:jsmith]]

(In reply to No-Jun Park [:njpark] from comment #28)
> Summary:
> 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

No-Jun - Can you try testing this with 286 MB Flame v123 w/480p on 1.4?

Comment 32

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #31)
> (In reply to No-Jun Park [:njpark] from comment #28)
> > Summary:
> > 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
> 
> No-Jun - Can you try testing this with 286 MB Flame v123 w/480p on 1.4?

Just trying to understand if the 286 MB behavior we are seeing is a regression or not.

Comment 33

[No-Jun Park [:njpark]]

With 1.4:
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.

480p was achieved by disabling 720p in settings.js in 1.4 code.

Comment 34

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to No-Jun Park [:njpark] from comment #33)

> 286MB Flame v123 w/ 480p launching Camera app from email app: initially
> there is stutter, but that goes away and records normally.

Curious: when there is stuttering, does 'adb shell dmesg | grep sigkill' (before and after the test) show that any processes were killed?

Comment 35

[No-Jun Park [:njpark]]

(In reply to Mike Habicher [:mikeh] from comment #34)
> (In reply to No-Jun Park [:njpark] from comment #33)
> 
> > 286MB Flame v123 w/ 480p launching Camera app from email app: initially
> > there is stutter, but that goes away and records normally.
> 
> Curious: when there is stuttering, does 'adb shell dmesg | grep sigkill'
> (before and after the test) show that any processes were killed?

So this is in 1.4:
before the test, the command returns this:
<6>[  127.815080] send sigkill to 1114 ((Preallocated a), adj 667, size 1797

after the test, the command shows this:
<6>[  127.815080] send sigkill to 1114 ((Preallocated a), adj 667, size 1797
<6>[  257.093548] send sigkill to 1910 ((Preallocated a), adj 667, size 2509
<6>[  261.755490] send sigkill to 1222 (Homescreen), adj 534, size 1469

Comment 36

[Mike Habicher [:mikeh] (high bugzilla latency)]

Thanks--the stuttering you're seeing then is due to the low-memory condition.

Comment 37

[Jason Smith [:jsmith]]

To simplify tracking - I think I'm going to suggest that we keep this bug open for tracking the memory increase for 720p & open a separate bug for the 480p behavior.

No-Jun - Can you open a separate bug for the 480p behavior (the regression of stutter to OOM from 1.4 --> 2.0) on 286 MB?

Comment 38

[No-Jun Park [:njpark]]

(In reply to Jason Smith [:jsmith] from comment #37)
> To simplify tracking - I think I'm going to suggest that we keep this bug
> open for tracking the memory increase for 720p & open a separate bug for the
> 480p behavior.
> 
> No-Jun - Can you open a separate bug for the 480p behavior (the regression
> of stutter to OOM from 1.4 --> 2.0) on 286 MB?

Bug 1053781 is created.

Comment 39

[BMO Automation]

Firefox OS is not being worked on