869443 - change undequeued buffer count of GonkNativeWindow to 4

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: General, defect)

Description

[Sotaro Ikeda [:sotaro]]

+++ 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.

Comment 1

[Sotaro Ikeda [:sotaro]]

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

Comment 2

[Diego Wilson [:diego]]

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

Comment 3

[Sotaro Ikeda [:sotaro]]

Attachment: patch - increment undequeued buffer count to 4 for OMXCodec

moved from Bug 864230

Comment 4

[Sotaro Ikeda [:sotaro]]

Attachment: logcat of a crash during thumbnail generation at video app by applying attachment 746517 on buri

Comment 5

[Sotaro Ikeda [:sotaro]]

Attachment: logcat of a crash during thumbnail generation at video app by applying attachment 746517 on Inari

Comment 6

[leo.bugzilla.gecko]

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.

Comment 7

[Diego Wilson [:diego]]

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.

Comment 8

[leo.bugzilla.gecko]

Did you mean..useBuffer() is failed without error?

And OMXCodec waits for buffers as many as previously failed?

Comment 9

[Diego Wilson [:diego]]

(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

Comment 10

[Diego Wilson [:diego]]

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?

Comment 11

[Diego Wilson [:diego]]

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.

Comment 12

[Sotaro Ikeda [:sotaro]]

set RESOLVED until this becomes a problem.