Closed Bug 1071205 Opened 10 years ago Closed 10 years ago

android::SoftAVCEncoder crashes while recording video in Firefox OS v2.1 Camera app

Categories

(Firefox OS Graveyard :: GonkIntegration, defect)

Product:
Firefox OS Graveyard
Component:
GonkIntegration
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
2.1 S9 (21Nov)

People

(Reporter: diego, Assigned: sotaro)

References

Details

(Keywords: crash, Whiteboard: [b2g-crash][caf-crash 363][caf priority: p3][CR 727232][POVB])

Attachments

(3 files)

Crash stack
(deleted), text/plain
Details
Extra file with log
(deleted), text/plain
Details
patch - Change Video encode to HardwareCodecsOnly
(deleted), patch
mikeh
: review+
diego
: feedback+
Details | Diff | Splinter Review 
      No description provided.
Summary: android::SoftAVCEncoder crashes while recording video in Firefox OS v2.1 Camera pp → android::SoftAVCEncoder crashes while recording video in Firefox OS v2.1 Camera app
move to FireFox OS :General because cmaera app still use the mozCamera API, not MediaRecorder.
Component: Video/Audio: Recording → GonkIntegration
Product: Core → Firefox OS
Whiteboard: [CR 727232]
Whiteboard: [CR 727232] → [caf priority: p1][CR 727232]
Whiteboard: [caf priority: p1][CR 727232] → [b2g-crash][caf-crash 363][caf priority: p1][CR 727232]
Keywords: crash
Marking [POVB] as it looks like a vendor issue for now.
Whiteboard: [b2g-crash][caf-crash 363][caf priority: p1][CR 727232] → [b2g-crash][caf-crash 363][caf priority: p1][CR 727232][POVB]
Whiteboard: [b2g-crash][caf-crash 363][caf priority: p1][CR 727232][POVB] → [b2g-crash][caf-crash 363][caf priority: p3][CR 727232][POVB]
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Observed on: 

Device: msm8226
Gonk Version: AU_LINUX_GECKO_B2G_KK_2.0.01.04.00.114.127
Moz BuildID: 20141029001202
B2G Version: ---
Gecko Version: 34.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=eb0aab0f13c78c7ac378ad860e865c4b6eaf669f
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=e16ae12c5ab365be13fb2c98d3811b93b25ded6d
Patches: bug 1070431, bug 1083449
As comment 4 notes this crash happened again in a recent v2.1 build. I'm reopening and will add crash details shortly.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached file Crash stack (deleted) — 
Add crash stack
The crash was due to a null check on the init params during in software encoder initialization [1].

Looks like the init params are only set to null on destruction [2], so most likely the problem is that the software encoder received buffers after it was destroyed.

[1] https://www.codeaurora.org/cgit/quic/la/platform/frameworks/av/tree/media/libstagefright/codecs/avc/enc/SoftAVCEncoder.cpp?id=AU_LINUX_GECKO_B2G_KK_2.0.01.04.00.114.121#n219

[2] https://www.codeaurora.org/cgit/quic/la/platform/frameworks/av/tree/media/libstagefright/codecs/avc/enc/SoftAVCEncoder.cpp?id=AU_LINUX_GECKO_B2G_KK_2.0.01.04.00.114.121#n352
Hi Sotaro,

There may be some stale buffers reaching the software encoder after destruction. Any idea who can help us here?
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(sotaro.ikeda.g)
SoftAVCEncoder seems a big problem here. During camera recording hw decoder should be used.
Flags: needinfo?(sotaro.ikeda.g)
diego, can you provide the STR of the crash?
Flags: needinfo?(dwilson)
(In reply to Sotaro Ikeda [:sotaro] from comment #10)
> diego, can you provide the STR of the crash?

And can you also provide the logcat log? Thanks.
In current gecko, OMX hw encoder resource is not managed/controlled on gonk. Therefore, if hw encoder resource allocation contention happens, the phone could just failed to allocate hw encoder and might fallback to sw encoder.
Attached file Extra file with log (deleted) — 
Here is the extra file with log included.

Unfortunately I don't have STR. This happened during automated stability camera testing.
Flags: needinfo?(dwilson)
Hmm, attachment 8518297 [details] seems not include necessary information.
Sorry, the full logs are too large to add as an attachment. You can download the zip from here:

https://www.dropbox.com/s/d8xbiymb5jofrsy/bug-1071205-logs.zip?dl=0
Flags: needinfo?(sotaro.ikeda.g)
Thanks for the log. From the log, hw encoder seems to emitting error. The following is related part.

> 11-04 16:13:06.594   300  7543 E mm-camera: stats_port_event: Failure posting to the bus!
> 11-04 16:13:06.594   202  7554 D QCamera2HWI: static void qcamera::QCamera2HardwareInterface::metadata_stream_cb_routine(mm_camera_super_buf_t*, qcamera::QCameraStream*, void*): hdr_scene_data: 1 0 0.000000
> 11-04 16:13:06.594   202  7554 E QCamera2HWI: int32_t qcamera::QCamera2HardwareInterface::processHDRData(cam_asd_hdr_scene_data_t) : hdr_scene_data: processHDRData: 0 0.000000
> 11-04 16:13:06.594  2968  3270 D GonkNativeWindow: GonkNativeWindow::returnBuffer
> 11-04 16:13:06.604   202  7555 D QCamera2HWI: [KPI Perf] static void qcamera::QCamera2HardwareInterface::preview_stream_cb_routine(mm_camera_super_buf_t*, qcamera::QCameraStream*, void*) : END
> 11-04 16:13:06.604   202  7583 E OMX-VENC-720p: HW Error recieved
> 11-04 16:13:06.604   202  7583 E OMX-VENC-720p: ERROR: async_msg_process() - Error statuscode = 1
> 11-04 16:13:06.614   300  7475 E mm-camera: cpp_hardware_process_frame:855] stream_status:0xb88e82f4, iden:0x10008, cur_frame_id:50
> 11-04 16:13:06.614   300  7543 E mm-camera: msg_bus_post_msg: bus_msg type is not valid
> 11-04 16:13:06.614   300  7543 E mm-camera: stats_port_event: Failure posting to the bus!
> 11-04 16:13:06.614   300  7543 E mm-camera: msg_bus_post_msg: bus_msg type is not valid
> 11-04 16:13:06.614   300  7543 E mm-camera: stats_port_event: Failure posting to the bus!
> 11-04 16:13:06.614   300  7543 E mm-camera: msg_bus_post_msg: bus_msg type is not valid
> 11-04 16:13:06.614   300  7543 E mm-camera: stats_port_event: Failure posting to the bus!
> 11-04 16:13:06.614  2968  2974 E OMXCodec: [OMX.qcom.video.encoder.avc] ERROR(0x80001009, 0)
Flags: needinfo?(sotaro.ikeda.g)
attachment 8518535 [details] [diff] [review] restricts to use only hw encoder for video encoding. It seems to prevent fallback to software video encoder. But it does not address hw video encoder's error.
software video encoder can not be used for the product. Therefore this restriction seems ok. And it could prevent SoftAVCEncoder crashes.
Attachment #8518535 - Flags: feedback?(dwilson)
diego, how do you think about attachment 8518535 [details] [diff] [review]?
Comment on attachment 8518535 [details] [diff] [review]
patch - Change Video encode to HardwareCodecsOnly

Review of attachment 8518535 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM. I don't know what's the general opinion in the media team here, though.
Attachment #8518535 - Flags: feedback?(dwilson) → feedback+
ICS already limit video encoder only to Hw video encoder. Therefore the change seems OK.
Comment on attachment 8518535 [details] [diff] [review]
patch - Change Video encode to HardwareCodecsOnly

mikeh, can you review the patch?
Attachment #8518535 - Flags: review?(mhabicher)
Comment on attachment 8518535 [details] [diff] [review]
patch - Change Video encode to HardwareCodecsOnly

Review of attachment 8518535 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me.

One suggestion, but I don't feel particularly strongly about it.

::: dom/camera/GonkRecorder.cpp
@@ +1268,5 @@
>      // CHECK_EQ causes an abort if the given condition fails.
>      CHECK_EQ(client.connect(), (status_t)OK);
>  
>      uint32_t encoder_flags = 0;
> +    encoder_flags |= OMXCodec::kHardwareCodecsOnly;

uint32_t encoder = OMXCodec::kHardwareCodecsOnly; ?
Attachment #8518535 - Flags: review?(mhabicher) → review+
(In reply to Mike Habicher [:mikeh] from comment #25)
> 
> ::: dom/camera/GonkRecorder.cpp
> @@ +1268,5 @@
> >      // CHECK_EQ causes an abort if the given condition fails.
> >      CHECK_EQ(client.connect(), (status_t)OK);
> >  
> >      uint32_t encoder_flags = 0;
> > +    encoder_flags |= OMXCodec::kHardwareCodecsOnly;
> 
> uint32_t encoder = OMXCodec::kHardwareCodecsOnly; ?

Yhea, it is simpler.
Assignee: nobody → sotaro.ikeda.g
https://hg.mozilla.org/mozilla-central/rev/badfce143136
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S9 (21Nov)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: