Closed Bug 864181 Opened 9 years ago Closed 9 years ago

extend OMXCodec's kBufferFilledEventTimeOutNs of OMXCodec

Categories

(Core :: Audio/Video, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
blocking-b2g tef+
Tracking Status
b2g18 --- affected
b2g18-v1.0.1 --- unaffected

People

(Reporter: sotaro, Assigned: sotaro)

References

Details

(Whiteboard: c=)

+++ This bug was initially created as a clone of Bug #853977 +++

Create this bug from Bug 853977 comment #63.

Even when software codecs are loaded in applications process. There are cases that the timeout happened at OMXCodec::waitForBufferFilled_l(). Current value is "3 seconds". Need to extend it.
Blocks: 853977, 864180
Blocks: 863441
Sounds like bumping the timeout is a win for other blocking work, blocking here based on that assessment.
blocking-b2g: leo? → leo+
Moving this up to tef+ since it blocks bug 863441
blocking-b2g: leo+ → tef+
Hi, Sotaro, could you also help this bug? Or, should we find someone else to work on this one? Thank you.
Flags: needinfo?(sotaro.ikeda.g)
Assignee: nobody → sotaro.ikeda.g
I take this bug.
Flags: needinfo?(sotaro.ikeda.g)
Just extending the timeout does not solve bug 863441. The timeout value should be determined depend on bug 863441.
I am going to thinks that extending the timeout needs to be careful. If we extend the timeout too long, it makes worse the situation like Bug 864230.
(In reply to Sotaro Ikeda [:sotaro] from comment #4)
> I take this bug.

Thank you, Sotaro.
Whiteboard: c=performance
A temporary fix in Bug 863441 comment #67, fix the problem without extending the timeout. As in comment #6, extending the timeout could cause another drawbacks. It it better not to extend the timeout.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 863441
No longer blocks: 863441
Resolution: DUPLICATE → WORKSFORME
Whiteboard: c=performance → c=
You need to log in before you can comment on or make changes to this bug.