+++ This bug was initially created as a clone of Bug #864230 +++ In Bug 863441, we found that gecko need to hold 4 buffers during playback(video queue size (3) + one rendered buffer). Ideally video codec should provide 4 video out buffers to gecko. In android, "undequeued buffer count = 2" is used for video playback use case. So some devices do not support "undequeued buffer count = 4". Actually all current v1.0.1 devices do not work in the setting. Bug 864230 comment #45 and Bug 864230 comment #41.

It seems that supporting "undequeued buffer count = 4" needs modification of qcom dependent or vender dependent code.

Could you share the logcat of the issues you're seeing? I can't reproduce them on my reference device.

moved from Bug 864230

Do you have any idea why these crashes are happen? I have two issues that have similar logs. rameworks/base/media/libstagefright/OMXCodec.cpp:3743 CHECK_EQ( countBuffersWeOwn(mPortBuffers[kPortIndexOutput]),mPortBuffers[kPortIndexOutput].size()) failed: 10 vs. 14 I cannot report them in bugziila becuase I cannot reproduce them. (Detected by tester, two times) Both of them occur at the end of thumbnail retrieving by video application. Build ID : 20130421070203 Gaia : 5cbb19e4bb78a7ad879fbe4b9a841e1c35714f5c Gecko : 950b402b6188bb2f3ce3176e620ed5249719d720 So it's before Bug 863441 and Bug 864230.

This log message is a good clue: "ADSP_RTOS_SVC: adsp: adsp_send_command failed (Invalid argument)" After the buffers are allocated, OMXCodec registers all buffers with the hardware decoder. I suspect this registration fails (without an error code) if you increase the number of buffers. Later the hardware decoder hangs when OMXCodec feeds one of these badly registered buffers.

Did you mean..useBuffer() is failed without error? And OMXCodec waits for buffers as many as previously failed?

(In reply to leo.bugzilla.gecko from comment #8) > Did you mean..useBuffer() is failed without error? > > And OMXCodec waits for buffers as many as previously failed? Yes

Sotaro, I inspected video playback on Android. In the same reference device I use for FFOS testing it actually uses 2 undequeued buffers for playback. So I'm not so convinced anymore that we need to increase it. Maybe we can withdraw this bug until we can confirm it's an issue?

Oh duh, you mentioned this already in the description. Still, given this doesn't seem to be an issue anymore I still think we can withdraw it until it comes up again.

set RESOLVED until this becomes a problem.