Closed
Bug 1081270
Opened 10 years ago
Closed 10 years ago
[Flame][Camera] Face tracking circle stops tracking once recording starts
Categories
(Firefox OS Graveyard :: Gaia::Camera, defect)
Tracking
(blocking-b2g:2.1+, b2g-v2.1 verified, b2g-v2.2 verified)
People
(Reporter: njpark, Assigned: dmarcos)
References
Details
Attachments
(3 files)
STR: Open camera app, point to a face, verify the face-tracking circle appears Change to video mode, and start video recording. Expected: During the video recording, face is continuously tracked Actual: The face tracking circle location does not get updated w.r.t face movement (This happens in both 2.1 and 2.2) Version info: Gaia-Rev 7ef2e1e59637a34ca4489c329b3bdee93df3ac6c Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/e3d495eb85c6 Build-ID 20141010001201 Version 34.0a2 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141010.070448 FW-Date Fri Oct 10 07:04:59 EDT 2014 Bootloader L1TC00011840
Reporter | ||
Comment 1•10 years ago
|
||
[Blocking Requested - why for this release]: The face tracking circle remains static in the viewfinder during the entire duration of recording, bad UI experience
Comment 3•10 years ago
|
||
Blocking Reason: The circles need to be erased if we dont support continuous face tracking in the video recording mode. Very poor user experience and interrupts the view. Diego, please take this.
Assignee: nobody → dmarcos
blocking-b2g: 2.1? → 2.1+
Assignee | ||
Comment 4•10 years ago
|
||
This PR hides faces after 250ms. If the camera stops reporting faces we just hide the rendered circles
Flags: needinfo?(dmarcos)
Assignee | ||
Updated•10 years ago
|
Attachment #8505283 -
Flags: feedback?(jdarcangelo)
Assignee | ||
Comment 5•10 years ago
|
||
This PR just reset the faces when recording starts
Attachment #8505284 -
Flags: feedback?(jdarcangelo)
Comment 6•10 years ago
|
||
(In reply to Diego Marcos [:dmarcos] from comment #5) > Created attachment 8505284 [details] [review] > Pull Request Option B > > This PR just reset the faces when recording starts I prefer option B over A, because once we add a fixed timer to clear the faces, somebody will switch from a 100ms update interval to 300ms in the driver :). Some things to consider: 1) If face detection doesn't work when recording videos, is it strange to leave face detection enabled in the recording preview in the first place? 2) If face detection works while recording on other devices, just not flame at present, then perhaps we should consider fixing this in gecko instead as it is a driver / platform quirk. Either by generating an empty faces event when a recording starts or additionally implicitly stopping/restarting face detection if enabled when recording starts.
Comment 7•10 years ago
|
||
I also prefer Option B for the same reasons as Andrew stated in Comment 6. However, I also agree with him about it being strange to have the face detection on in recording mode in the first place. Couldn't we just move the call to `self.focus.clearFaceDetection()` inside `Camera.prototype.setMode()` instead?
Comment 8•10 years ago
|
||
(In reply to Justin D'Arcangelo [:justindarc] from comment #7) > I also prefer Option B for the same reasons as Andrew stated in Comment 6. > However, I also agree with him about it being strange to have the face > detection on in recording mode in the first place. Couldn't we just move the > call to `self.focus.clearFaceDetection()` inside > `Camera.prototype.setMode()` instead? Er, I guess we'd need to actually call `startFaceDetection()` and `stopFaceDetection()` accordingly.
Assignee | ||
Comment 9•10 years ago
|
||
I still have to fix unit tests
Attachment #8505852 -
Flags: review?(jdarcangelo)
Comment 10•10 years ago
|
||
Comment on attachment 8505852 [details] [review] Pull Request Tested on Flame-KK v184. LGTM.
Attachment #8505852 -
Flags: review?(jdarcangelo) → review+
Assignee | ||
Comment 11•10 years ago
|
||
Landed on master: https://github.com/mozilla-b2g/gaia/commit/f05e4482a7cac32a8ade973e859bc64f547513ec
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 12•10 years ago
|
||
Please nominate this patch for Gaia v2.1 approval when you get a chance.
Assignee | ||
Comment 13•10 years ago
|
||
Comment on attachment 8505852 [details] [review] Pull Request [User impact] The faces detected before a video session remain on screen after pressing recording and their position does not get updated since video does not do face detection. This patch disables face detection and hide any previously detected faces when camera switches to video mode.
Flags: needinfo?(dmarcos)
Attachment #8505852 -
Flags: approval-gaia-v2.1?(fabrice)
Updated•10 years ago
|
Attachment #8505852 -
Flags: approval-gaia-v2.1?(fabrice) → approval-gaia-v2.1+
Updated•10 years ago
|
Attachment #8505283 -
Flags: feedback?(jdarcangelo)
Updated•10 years ago
|
Attachment #8505284 -
Flags: feedback?(jdarcangelo)
Comment 14•10 years ago
|
||
As per comment 13, the bug is fixed on 2.2 Master build. The face tracking circle is removed during recording Flame 2.2 KK (319mb Full Flash) Device: Flame 2.2 Master BuildID: 20141022040201 Gaia: 27a1d1baaa8e375b70e043efee67d5f2206c330b Gecko: ae4d9b4ff2ee Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d Version: 36.0a1 (2.2 Master) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Adding verifyme for 2.1 verification once the patch has been uplifted.
Comment 15•10 years ago
|
||
v2.1: https://github.com/mozilla-b2g/gaia/commit/b6bd5bb635c0663414b07bf9b120a74cf19faf77
Comment 16•10 years ago
|
||
This issue is verified on Flame 2.1. Result: Face detection circle does not appear during video recording. Flame 2.1 Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash) BuildID: 20141023001201 Gaia: 1e48e3e40e0780c0cd07a3457e5fe2efeeb542d1 Gecko: 09fb60a37850 Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d Version: 34.0 (2.1) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Keywords: verifyme
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in
before you can comment on or make changes to this bug.
Description
•