990366 - [tarako] should save video captured when MT call screen appears

Status: RESOLVED WONTFIX

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

Description

[Peipei Cheng (needinfo if you need my action)]

Reproduce steps:
-----------------------------------------------------------------------
1. Launch Camera
2. Switch to Video mode and start taking a video
3. Make a MT call to test device
4. Answer/Reject the call
   --> Camera was killed.

[expected] we should not kill Camera and we need save the video already captured. After user end the call, they should be able to go back to Camera and find the video already took.

Comment 1

[bhavana bajaj [:bajaj]]

NI :jammink to see how this behaves in 1.3

JOe, given this a different hardware spec we may need to check or get input the gaia:video team on the behavior here. NI :Cj already.

Comment 2

[John Hammink]

Here is the behavior on 1.3:

After incoming call is accepted, recording stops and video is saved.

After incoming call is rejected, recording stops and video is saved.

Gaia      c5cd3a11e91339163b351d50769eaca0067da860
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/5045a67b47ed
BuildID   20140401164001
Version   28.0
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013

Comment 3

[u459114]

Ben, please help to check whether camera be terminate by OOM killer before clip saved

Comment 4

[Ben Tian (inactive)]

(In reply to C.J. Ku[:CJKu] from comment #3)
> Ben, please help to check whether camera be terminate by OOM killer before
> clip saved
Camera app is terminated by OOM killer as CJ mentioned. This bug can be reproduced by simply going back to HOME screen during recording, and camera app doesn't appear in card view afterwards.

We think this bug results from the same cause as another OOM bug 988164. Per offline discussion with Taipei perf' team, we don't have a feasible solution right now.

Comment 5

[Ting-Yu Chou [:ting] (away)]

Current min_free of background application (oom_adj 10) is 24MB, I revert it to 20MB but still the Camera is killed when back to homescreen.

Comment 6

[Joe Cheng [:jcheng] (please needinfo)]

this is not going to be done in tarako frame, 1.5?

Comment 7

[John Hammink]

Hi Peter, could we get some traction on this from the team?

Comment 8

[Peter Bylenga [:PBylenga]]

Discussed with John offline and since this is no longer for 1.3T no need for further exploration.

Comment 9

[Hema Koka [:hema]]

Lets try to get this in 2.0 timeframe. Putting it in priority list of bugs

Thanks
Hema

Comment 10

[David Flanagan [:djf]]

I'm not sure there is much we can do here: on a low memory device we might just die without warning if an incoming call causes an OOM.  

Mike: is there any kind of on exit hook we can use in gecko to ensure that a valid video file is written in the case of an OOM during video recording? (Is this just a matter of ensuring that buffers are flushed, or is there also metadata that needs to be written to the file when recording ends?) Is there anything we can do in gecko to reduce memory overhead while recording a video?

Note that there is also a 1.3+ bug currently that says that when there is an incoming call we have to stop video recording before the ringer sounds so that we don't capture the sound of the incoming call in the recording. But that is a different issue than this one.

Comment 11

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

It's not just a matter of flushing buffers: a chunk of metadata gets written the video file header when it's closed properly.

Fabrice, any chance there's a pre-OOM-kill message we could listen for to cleanly wrap up video recording before the Camera app gets killed?

Comment 12

[[:fabrice] Fabrice Desré]

No we can't send a pre-OOM-kill message. At the gecko level you could hook up to the memory-pressure observer notifications. Would that work for you?

Comment 13

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

According to fabrice, there is a "memory-pressure" event we can listen for, but there doesn't seem to be a way to make it useful. The event gets fired whenever there is any memory pressure and not (just) when we're about to get killed. Since the MPEG4Writer has to commit a chunk of final metadata (not just flush its buffers) to make a video file valid, intermittent or periodic messages are not useful.

Fixing this problem is going to require a significant change to how the video recorder is implemented.

One solution might be to run the MPEG4Writer in a worker process that can detect when the Camera app dies, and commit the metadata at that time.

Comment 14

[Justin D'Arcangelo [:justindarc]]

un-assigning -- this seems to need to be resolved from Gecko

Comment 15

[BMO Automation]

Firefox OS is not being worked on