Closed Bug 1007973 Opened 6 years ago Closed 6 years ago

[B2G][Flame][Camera] Temporarily stuck in preview mode when taking HDR pictures

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:1.4+, b2g-v1.4 fixed, b2g-v2.0 fixed)

RESOLVED FIXED
blocking-b2g 1.4+
Tracking Status
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: marcia, Unassigned)

References

Details

Attachments

(1 file)

Attached file flamecamera.txt
Flame device, while running on master

Gaia   1e0574b8f6b8a2a8d9d468878ce2b4c283fc9a84
SourceStamp 2a03b34c8953
BuildID 20140508040203
Version 32.0a1
Firmware Version: v10e
Memory throttled to 512

STR:
1. Turn on HDR mode.
2. Take picture
3. Observe that the picture that you just took still lingers in the viewfinder.

Logcat attached. Will also attach a video next.
It is typically taking 5 seconds for the preview to clear so I can see "live" again instead of the last picture I took.
We should check to see if this is happening on a 1.4 Flame build.
Keywords: qawanted
This DOES reproduce on the 1.4 Flame - typically the preview will stay up for 4-5 seconds before returning to the live view.

1.4 Environmental Variables:
Device: Flame 1.4 MOZ
BuildID: 20140508000201
Gaia: 4ce973ef0732b0d52cb043210db598aa176b2ce9
Gecko: 16ab7f6b18f8
Version: 30.0
Firmware Version: v10E

Notes: I'm finding that when I launch the camera with the HDR turned off, turn the HDR on and then take a picture, the preview shot stays up for an excessively (forever) long time. Selecting the picture preview icon to the left of the shutter-button brings up the preview and then backing out of it will return the user to a black screen with the camera icons and buttons but without the ability to take additional pictures. Because the camera app launches with the HDR defaulted to ON you must launch the camera app, turn HDR to off, tap the home button, hold the home button and kill the Camera app, re-launch the app, turn HDR on and take a picture.
Keywords: qawanted
This is because HDR pictures take a long time to capture: part of the time is in capturing multiple photos, the rest goes into post-processing.

Justin, we may want to throw up the "I'm busy" spinner here to let the user know the pause is intentional.
Flags: needinfo?(jdarcangelo)
Flagging UX for input on this. Should we reuse the same loading spinner or some other visual cue?
Flags: needinfo?(tshakespeare)
Flags: needinfo?(amlee)
(In reply to Justin D'Arcangelo [:justindarc] from comment #5)
> Flagging UX for input on this. Should we reuse the same loading spinner or
> some other visual cue?

Hi Justin, 

Can you provide a video of what you are experiencing? I don't think happens on the Nexus 4.
Flags: needinfo?(amlee)
Rob has a flame that he can try out. 

I think if the delay is really bad we should consider removing the feature if there is no other way to optimize and decrease the delay.
Flags: needinfo?(rmacdonald)
Recreated. I can confirm that the camera is frozen until we get the 'success' callback from `mozCamera.takePicture()`. In very few cases the camera never recovered.
I've tried it a few times on my flame and it's hanging indefinitely. I stopped timing it after about 5 mins. It renders the camera unusable so it's definitely a blocker.
Flags: needinfo?(rmacdonald)
Same here -- it was just hanging with the green ring showing indefinitely...but when i did the following right after

- clicked home button
- relaunched camera
- went back into settings 
- made sure HDR is on 
- took a picture 

I am able to take pictures with HDR on and no significant delays from preview to capture. So, I am not sure if it is a HDR issue on flame -- something else is going on. 

I am able to reproduce the preview hanging issue with HDR on consistently but only when I first switch to video mode and take a few mins of video and then switch back to camera with HDR on.

Thanks
Hema
blocking-b2g: --- → 1.4+
FYI - I just tried it again after launching a bunch of apps, including settings, calendar, browser, FM radio and the delay was reduced to about 4 seconds. Still long but there may be ways to mitigate it.
Can we get some testing from QA and to figure out when this consistently hangs and when it is actually not bad?

I don't want to make the recommendation to pull the feature if there are ways to mitigate it. Thanks!
Whiteboard: qawanted
There seems to be issues with things at the driver level for the camera on Flame. This may be part of what's causing this delay. I think there's also another issue with taking pictures following recording a video. They may all be related.
Keywords: qawanted
Whiteboard: qawanted
QA Contact: jmitchell
(In reply to Tiffanie Shakespeare from comment #12)
> Can we get some testing from QA and to figure out when this consistently
> hangs and when it is actually not bad?



It seems there are 3 main issues we are seeing here:
1) Delay of 4-5 seconds on the preview when taking a HDR picture
2) Unresponsive / freezing camera when taking a picture after taking a video
3) Unresponsive / freezing camera when switching HDR ON and taking a picture


1) Delay of 4-5 seconds on the preview when taking a HDR picture:
This issue is the most straightforward and repros anytime you enter the camera app and take a picture with HDR set to On (provided you do not repro the other 2 issues). When taking a picture the ring will appear, shrink down and turn green, the screen will quickly flash and then the viewfinder will "freeze" for 4-5 seconds on the still image of the picture just taken.
This reproduces 100% on a recent build.

2) Unresponsive / freezing camera after taking video:
This issue involves freezing on the ring and the picture not being taken. The steps to reproduce this are to Record a video (any length of time) and then to switch back to the camera mode and take a picture (HDR or non-HDR). The ring will appear (Green for HDR, Red for non-HDR) and shrink down but then will freeze and stay on the screen while the view stays live. At this point you can not switch back to video, can't select the preview thumbnail (from the video recorded) or change any settings. At this point you can go to the homescreen and back OR close the app and re-enter it and everything will be "back to normal". 
This issue repro's 100% 

There are at least two bugs in on this issue already:

https://bugzilla.mozilla.org/show_bug.cgi?id=1010378 -  [B2G][Camera][Flame] Camera often freezes with red focus ring when switching back and forth between video and camera

https://bugzilla.mozilla.org/show_bug.cgi?id=1007832 - App freezes when taking picture after taking video


3) Unresponsive / freezing camera when switching HDR ON and taking a picture
This issue involves starting the camera app with the HDR set to off, setting it to ON and then taking a picture. Like the 1st issue the ring will appear, turn green and shrink down, then the screen will quickly flash, then viewfinder will "freeze" indefinately on the still image of the picture just taken. After 4 or 5 seconds the preview thumbnail will appear to the left of the shutter button. You will still be able to access the settings, switch the camera to video, or access the preview thumbnail. Accessing the preview thumbnail will take you to the picture just taken but then returning to the camera via the back arrow in the upper left corner will return you to a black screen with all the camera icons and buttons. If instead you minimize the app and re-enter it or switch to video mode and back everything will operate normally. 
This also reproduces 100%


1.4 Environmental Variables:
Device: Open_C 
BuildID: 20140513000208
Gaia: b40103dec34a147c9018a1af76eb21c3184f2f93
Gecko: c140bcd02b9b
Version: 30.0
Firmware Version: P821A10V1.0.0B06_LOG_DL
Keywords: qawanted
Please re-test the cases after this bug fix is in https://bugzilla.mozilla.org/show_bug.cgi?id=1007832
Mark qawanted to do the re-test after the bug fix in bug 1007832.
Keywords: qawanted
(In reply to Hema Koka [:hema] from comment #10)
> I am able to reproduce the preview hanging issue with HDR on consistently
> but only when I first switch to video mode and take a few mins of video and
> then switch back to camera with HDR on.
I also did some tests. Looks like this issue can't be reproduced always. And, I start to wonder, do we really need to make this bug as a 1.4+ blocker?
blocking-b2g: 1.4+ → 1.4?
(In reply to Kevin Hu [:khu] from comment #17)
> (In reply to Hema Koka [:hema] from comment #10)
> > I am able to reproduce the preview hanging issue with HDR on consistently
> > but only when I first switch to video mode and take a few mins of video and
> > then switch back to camera with HDR on.
> I also did some tests. Looks like this issue can't be reproduced always.
> And, I start to wonder, do we really need to make this bug as a 1.4+ blocker?

Yes, for obvious reasons. This is a critical camera feature for 1.4 & getting freezes in an app in unacceptable. This showed up all over the place in the bug bash, so there's multiple people seeing this. Resetting the blocking flag - this is definitely a cut and dry blocker.

Clearing qawanted because the patch referenced here hasn't landed yet.
blocking-b2g: 1.4? → 1.4+
Depends on: 1007832
Keywords: qawanted
Depends on: 1013425
Adding qawanted to re-test the cases since dependencies landed. 

Thanks
Hema
Whiteboard: qawanted
I pulled the latest 1.4 build and Central build and I'm still seeing a 5-6 second delay after taking a HDR picture. I am not seeing the indefinite hang after taking video and then switching to camera or the one after turning HDR on and taking a picture; these still result in the 5-6 second delay but do successfully take the picture.

1.4 Environmental Variables:
Device: Flame 1.4
BuildID: 20140522063003
Gaia: 8990a6b8ee6a2c8f9668ef24e6d86e37aecad750
Gecko: 1d98f47152ef
Version: 30.0
Firmware Version: v10F-3

2.0 Environmental Variables:
Device: Flame 2.0
BuildID: 20140522073019
Gaia: 7db23414f2d632f4d00b5023ac1090b6045dc5fd
Gecko: 48ef1c52dece
Version: 32.0a1
Firmware Version: v10F-3
Whiteboard: qawanted
(In reply to Joshua Mitchell from comment #20)
>
> these still result in the 5-6 second delay but do
> successfully take the picture.

The delay is due to processing intrinsic to the camera library. Unfortunately there is nothing we can do about it. I suggest the UI throw up a spinner or something similar, possibly with a "Processing..." message while this is going on.
It seems like the infinite hang has been resolved, though we are still see a consistent 5-6 second delay. I think we should keep the feature because this is a reference phone and show a spinner as others have suggested.

I'm pretty sure it was Wilson who implemented a spinner for the camera startup on the Nexus? I think that same thing would be fine. Is that cool Amy?
Flags: needinfo?(wilsonpage)
Flags: needinfo?(tshakespeare)
Flags: needinfo?(amlee)
We could add a spinner as a workaround.

But it will help if vendor can investigate and help us in fixing this issue. Right now for HDR we only have Flame and Nexus4 to test with. 

Adding Francis for help here.
Flags: needinfo?(frlee)
Whiteboard: POVB
If the original bug as filed has been resolved, then this bug should be closed. Let's close this bug for fixing the issue with the hang & open a new bug for the delay.

Josh - Can you open a new bug for the delay & indicate on that bug reproducibility on Open C & Flame?
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(jmitchell)
Resolution: --- → FIXED
Whiteboard: POVB
I could implement a spinner if need be. As jsmith said, let's move discussions over to a new bug.
Flags: needinfo?(wilsonpage)
(In reply to Tiffanie Shakespeare from comment #22)
> It seems like the infinite hang has been resolved, though we are still see a
> consistent 5-6 second delay. I think we should keep the feature because this
> is a reference phone and show a spinner as others have suggested.
> 
> I'm pretty sure it was Wilson who implemented a spinner for the camera
> startup on the Nexus? I think that same thing would be fine. Is that cool
> Amy?

Yeah I think that makes sense.
Flags: needinfo?(amlee)
(In reply to Jason Smith [:jsmith] from comment #24)
> If the original bug as filed has been resolved, then this bug should be
> closed. Let's close this bug for fixing the issue with the hang & open a new
> bug for the delay.
> 
> Josh - Can you open a new bug for the delay & indicate on that bug
> reproducibility on Open C & Flame?


Certainly - A new bug has been opened for the implementation of a spinner during the processing delay.

https://bugzilla.mozilla.org/show_bug.cgi?id=1016492
Flags: needinfo?(jmitchell)
Flags: needinfo?(frlee)
Flags: needinfo?(jdarcangelo)
You need to log in before you can comment on or make changes to this bug.