Since the bug 1005852 is resolved, I met this new issue. STR: 1. Launch Camera app and switches to video mode. 2. Camera app crashes after start recording. FR: 100%

From the log tracking, it seems some libraries missing when start recording. I/SPRDAVCEncoder( 103): Construct SPRDAVCEncoder, this: b7aa69f8 I/SPRDAVCEncoder( 103): openEncoder, lib: libomx_avcenc_hw_sprd.so E/SPRDAVCEncoder( 103): Can't find H264EncGetCodecCapability in libomx_avcenc_hw_sprd.so F/SPRDAVCEncoder( 103): vendor/sprd/open-source/libs/omx_components/video/avc_sprd/sc8830/enc/SPRDAVCEncoder.cpp:312 CHECK_EQ( openEncoder("libomx_avcenc_hw_sprd.so"),true) failed: 0 vs. 1 Sam, can someone in your side also look into this issue? Thanks.

Correct the component to Firefox general.

our test team will reproduce it.

Hi Sam, Please help to find out the answer for the question in comment 1. It seems the issue is about the missing library.

fixed in latest version.

Closing per comment 5.

Doesn't work for me. I'm looking at B2G/vendor/sprd/proprietaries where the last commit is from May 15th. Sam, could you shed some light on where this bug was fixed or when the fix will be available? Thanks.

Andreas, can you apply this patch locally and try again? https://bug988291.bugzilla.mozilla.org/attachment.cgi?id=8423688 I am not sure if it is related, but I have this patch in my local and camera recording does work properly.

I have that one, doesn't seem to help.

From today's sync, I can still see the error message in Comment 1. H264EncGetCodecCapability() contains in libomx_avcenc_hw_sprd.so, and there is no source code to look into. Reopen this bug for tracking.

Sam, do update the vendor/sprd/proprietories for mozilla?

It's video issue now, Sam, please ask Alan and Ming fix this issue quickly.

(In reply to James Zhang from comment #12) > It's video issue now, Sam, please ask Alan and Ming fix this issue quickly. Since bug 1016805 has worked out a patch to fix video crash, I can still reproduce this issue. The message just like Comment 1 said. I think your should look into it for the next move.

Ming, please comment here, Thanks.

And I don't think it's POVB issue. After remove Sotaro's bug 984434 patch, it's OK.

yes , after we apply the follow mozilla patch , this issue is gone. https://bug1016805.bugzilla.mozilla.org/attachment.cgi?id=8431159.

I just pulled the latest code, did a complete rebuild, full flash, and still get the error in comment 1, namely: F/SPRDAVCEncoder( 103): vendor/sprd/open-source/libs/omx_components/video/avc_sprd/sc8830/enc/SPRDAVCEncoder.cpp:336 CHECK_EQ( openEncoder("libomx_avcenc_hw_sprd.so"),true) failed: 0 vs. 1 To me this looks like a shared library (from your vendor/sprd/proprietaries repo) failing to load. I don't see how that can be affected by the code in bug 984434 and bug 1016805. Are you sure that we are looking at the same issue here?

(In reply to Ming from comment #17) > yes , after we apply the follow mozilla patch , this issue is gone. > https://bug1016805.bugzilla.mozilla.org/attachment.cgi?id=8431159. Ming, After apply this patch, camera recording still do not work and camera App will crash when recording is started. I think camera recording is a different issue and different cause.

Sorry, it can be loaded, but then SPRDAVCEncoder::openEncoder looks for the symbol H264EncGetCodecCapability, which doesn't exist. I checked for symbols containing "H264" in libomx_avcenc_hw_sprd.so and found these: $> ~/B2G/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/arm-linux-androideabi-readelf -a libomx_avcenc_hw_sprd.so | grep H264 6: 00000f6c 128 FUNC GLOBAL DEFAULT 8 H264Enc_OutputBits 7: 00000fec 64 FUNC GLOBAL DEFAULT 8 H264Enc_ByteAlign 8: 0000102c 36 FUNC GLOBAL DEFAULT 8 H264Enc_rbsp_trailing 9: 00001050 40 FUNC GLOBAL DEFAULT 8 H264Enc_write_nal_start_c 13: 000010a0 2192 FUNC GLOBAL DEFAULT 8 H264EncInit 16: 00002130 176 FUNC GLOBAL DEFAULT 8 H264Enc_InitMem 18: 000021e0 156 FUNC GLOBAL DEFAULT 8 H264Enc_MemAlloc 20: 0000227c 92 FUNC GLOBAL DEFAULT 8 H264Enc_ExtraMem_V2P 24: 00001930 152 FUNC GLOBAL DEFAULT 8 H264EncSetConf 25: 000019c8 56 FUNC GLOBAL DEFAULT 8 H264EncGetConf 26: 00001a00 28 FUNC GLOBAL DEFAULT 8 H264EncRelease 29: 00001a1c 176 FUNC GLOBAL DEFAULT 8 H264Enc_FakeNALU 30: 00001acc 1128 FUNC GLOBAL DEFAULT 8 H264EncStrmEncode 32: 000029c0 948 FUNC GLOBAL DEFAULT 8 H264Enc_InitVSP 34: 00002d74 116 FUNC GLOBAL DEFAULT 8 H264Enc_InitBSM 40: 00001f34 508 FUNC GLOBAL DEFAULT 8 H264EncGenHeader I can also note that from the other symbols SPRDAVCEncoder::openEncoder tries to load (these: H264EncPreInit H264EncInit H264EncSetConf H264EncGetConf H264EncStrmEncode H264EncGenHeader H264EncRelease ), H264EncPreInit also does not exist in libomx_avcenc_hw_sprd.so. Finally, my proprietaries repo (sprd-aosp/sprdb2g_gonk4.4) points to revision e67868cbd11f02583dea849b2049773edd177fe8 ("Bug #312855 add proprietories lib for partner"). Thanks, I hope the issue should be clearer now.

I think we should update proprietories libs.

(In reply to James Zhang from comment #21) > I think we should update proprietories libs. done! already updated.

Ming, after update the latest libs, video recording doesn't crash but it doesn't work properly. Can you try if you can reproduce the same result.

I also got the same issue kai-Zhen mentioned. From looking into code in gaia (camera/js/lib/camera.js), dolphin consumed too much time to check free storage space. 06-04 03:22:01.736 666 666 E GeckoConsole: Content JS LOG at app://camera.gaiamobile.org/js/main.js:3612 in Camera.prototype.startRecording: getFreeVideoStorageSpace 06-04 03:22:26.260 666 666 E GeckoConsole: Content JS LOG at app://camera.gaiamobile.org/js/main.js:3616 in gotStorageSpace: gotStorageSpace

dafeng plz

I also encounter the same problem with comment 23 and comment 24. 1. It took long time (10s) to take a second picture 2. The video recording time does not show correctly. 3. Video recoding cannot be stopped/saved 4. The device performance is very bad after start camera.

Peipei - I need a crash stack here. Can you get a crash report URL this bug? https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Getting_crashes_off_the_Device

The above comments imply this is a regression from bug 984434, which makes this is a gfx problem.

I also don't think this is a vendor bug. The vendor's analysis above is strongly concluding this is a bug in gfx.

(In reply to Jason Smith [:jsmith] from comment #29) > I also don't think this is a vendor bug. The vendor's analysis above is > strongly concluding this is a bug in gfx. Sotaro - Do you agree or disagree?

What is the description for this bug? Comment 23 suggests the original issue (which, we had some indication, was caused by the fix to bug 984434) is gone, and comment 26 is suggesting a different issue. Which one is it?

(In reply to Jason Smith [:jsmith] from comment #30) > (In reply to Jason Smith [:jsmith] from comment #29) > > I also don't think this is a vendor bug. The vendor's analysis above is > > strongly concluding this is a bug in gfx. > > Sotaro - Do you agree or disagree? gecko side seems suspicious for the time being. By the recent commit and uplift to b2g v1.4, there are similar problem like Bug 1016805, Bug 1020003 and Bug 1019877. It might be better to recheck after all problem is fixed.

(In reply to Milan Sreckovic [:milan] from comment #31) > What is the description for this bug? Comment 23 suggests the original > issue (which, we had some indication, was caused by the fix to bug 984434) > is gone, and comment 26 is suggesting a different issue. Which one is it? I believe the issue kai-Zhen, Peipei and I comment are the same after updating vendor libs. As I know, the fix of bug 984434 solved the video crash issue reported in Bug 1016805. After that, I could still reproduce video recording crash. The reason for this video recording crash can refers to Comment 20 in this bug to know the detail. From the lib update from partner (please see Comment 22), video recording crash never happens. After that, the new issue currently we see just like Peipei said in Comment 26.

06-05 22:58:03.324 I/GeckoDump( 636): DEBUG startRecording 06-05 22:58:03.424 I/GeckoDump( 636): DEBUG gotStorageSpace start 06-05 22:58:15.296 I/GeckoDump( 636): DEBUG gotStorageSpace callback 06-05 22:58:15.296 I/GeckoDump( 636): DEBUG createVideoFilepath start 06-05 22:58:40.741 I/GeckoDump( 636): DEBUG createVideoFilepath callback 06-05 22:58:40.741 I/DEBUG ( 636): nsDOMCameraControl::StartRecording Add some debug message, it looks like spend 12 sec in gotStorageSpace & 25 sec in createVideoFilepath

Also I applied the latest pac from spreadtrum (https://www.dropbox.com/s/89bj74qcp0v5x05/sp7715ga_gonk4.4.pac.gz), and run the test. This crash happens again. STR: Launch Camera -> Switch to Video mode -> start take video -> stop taking video It seems the problem happens when saving video. Here is the crash report I get. https://crash-stats.mozilla.com/report/index/b2963495-a0cf-4b2c-a78c-747862140606

From log, nsDOMDeviceStorage.cpp finished NS_DispatchToCurrentThread in nsDOMDeviceStorage::GetInternal at "16:37:17.940", however DeviceStorageRequestChild has action after 5 sec. I'm not sure what's going on in this place? Need other expert to help. 06-09 16:37:17.880 I/GeckoDump( 991): DEBUG gotStorageSpace callback 06-09 16:37:17.900 I/GeckoDump( 991): DEBUG createVideoFilepath start 06-09 16:37:17.900 I/GeckoDump( 991): DEBUG createFilename start 06-09 16:37:17.900 I/GeckoDump( 991): DEBUG createDCFFilename storage get filepath start 06-09 16:37:17.920 I/DEBUG ( 991): already_AddRefed<mozilla::dom::DOMRequest> nsDOMDeviceStorage::GetInternal(const nsAString_internal&, bool, nsDOMDeviceStorage::ErrorResult&):3535 06-09 16:37:17.920 I/DEBUG ( 991): already_AddRefed<mozilla::dom::DOMRequest> nsDOMDeviceStorage::GetInternal(const nsAString_internal&, bool, nsDOMDeviceStorage::ErrorResult&):3562 GetInternal start 06-09 16:37:17.930 I/DEBUG ( 991): void nsDOMDeviceStorage::GetInternal(nsPIDOMWindow*, const nsAString_internal&, nsDOMDeviceStorage::DOMRequest*, bool):3575 06-09 16:37:17.930 I/DEBUG ( 991): void nsDOMDeviceStorage::GetInternal(nsPIDOMWindow*, const nsAString_internal&, nsDOMDeviceStorage::DOMRequest*, bool):3580 dsf->SetEditable start 06-09 16:37:17.940 I/DEBUG ( 991): void nsDOMDeviceStorage::GetInternal(nsPIDOMWindow*, const nsAString_internal&, nsDOMDeviceStorage::DOMRequest*, bool):3582 dsf->SetEditable finish 06-09 16:37:17.940 I/DEBUG ( 991): [DeviceStorageRequest]void nsDOMDeviceStorage::GetInternal(nsPIDOMWindow*, const nsAString_internal&, nsDOMDeviceStorage::DOMRequest*, bool):3589 06-09 16:37:17.940 I/DEBUG ( 991): already_AddRefed<mozilla::dom::DOMRequest> nsDOMDeviceStorage::GetInternal(const nsAString_internal&, bool, nsDOMDeviceStorage::ErrorResult&):3564 GetInternal finish 06-09 16:37:22.224 I/DEBUG ( 991): mozilla::dom::devicestorage::DeviceStorageRequestChild::DeviceStorageRequestChild(mozilla::dom::DOMRequest*, DeviceStorageFile*):35 06-09 16:37:22.224 I/DEBUG ( 884): bool mozilla::dom::devicestorage::DeviceStorageRequestParent::EnsureRequiredPermissions(mozilla::dom::ContentParent*):256 3 06-09 16:37:22.224 I/DEBUG ( 884): bool mozilla::dom::devicestorage::DeviceStorageRequestParent::EnsureRequiredPermissions(mozilla::dom::ContentParent*):280 3 06-09 16:37:22.234 I/DEBUG ( 884): void mozilla::dom::devicestorage::DeviceStorageRequestParent::Dispatch():41 3 06-09 16:37:22.234 I/DEBUG ( 884): void mozilla::dom::devicestorage::DeviceStorageRequestParent::Dispatch():89 3 06-09 16:37:23.065 I/DEBUG ( 991): virtual bool mozilla::dom::devicestorage::DeviceStorageRequestChild::Recv__delete__(const DeviceStorageResponseValue&):67 :1 06-09 16:37:23.065 I/DEBUG ( 991): virtual bool mozilla::dom::devicestorage::DeviceStorageRequestChild::Recv__delete__(const DeviceStorageResponseValue&):73 :1

When the camera finishes recording a video, it then needs to decode the video stream in order to create a thumbnail. If you have a DeviceStorageFile object, you can call the Dump method and it will print its name to logcat. That might help decipher which device storage objects you're dealing with. Or maybe even just add a call to Dump() at the end of DeviceStorageFile::Init()

Ming: there has been no update to this for over a week. If you're not the right person here, can you reassign it to someone else please?

(In reply to Faramarz [:faramarz] from comment #38) > Ming: there has been no update to this for over a week. If you're not the > right person here, can you reassign it to someone else please? Sorry. It seems i'm not the right person here now. NI dafeng &james

I cannot reproduce the crash on latest build. But the saving video performance issue still exist. I would like to close this issue and file a new one for the performance issue.

We can't meet this issue now, WORKSFORME.

I think bug 984434 also fix this bug.

(In reply to Dave Hylands [:dhylands] from comment #37) > When the camera finishes recording a video, it then needs to decode the > video stream in order to create a thumbnail. > > If you have a DeviceStorageFile object, you can call the Dump method and it > will print its name to logcat. That might help decipher which device storage > objects you're dealing with. > > Or maybe even just add a call to Dump() at the end of > DeviceStorageFile::Init() Dafeng, please verify it on my side.