Closed
Bug 798202
Opened 12 years ago
Closed 12 years ago
Use OmxClient in OmxDecoder
Categories
(Core :: Audio/Video, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 803471
People
(Reporter: sotaro, Unassigned)
References
Details
Attachments
(1 file, 3 obsolete files)
3.96 KB,
patch
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4 Steps to reproduce: In current implementation, OMX(hw codec) instance is created within WebApp's process, because OmxDecoder class create OMX instance. It request high privilege to WebApp's process. Bug 791164 If OMX instance moves back to mediaserver process like in android. The process do not need such privilege privilege.
Reporter | ||
Updated•12 years ago
|
OS: Windows 7 → Gonk
Hardware: x86_64 → ARM
Reporter | ||
Comment 1•12 years ago
|
||
By the patch, OMX is instantiated within mediaserver process by MediaPlayerService and OMXCodec use it. And enable ThreadPool for Binder ipc. It is necessary to receive Binder ipc from mediaserver process. As a prerequisite, MediaPlayerService need to be present in mediaserver process. I do not have access to otoro device. From source code for otoro, it seems that MediaPlayerService is still present. Firefox OS already use Binder ipc to communicate with AudioFliner. But Binder ipc happens always from b2g to AudioFlinger synchronously. Binder ThreadPool is not necessary in this case. But b2g could not receive Binder Died event from AudioFlinger if the ThreadPool is not present.
Reporter | ||
Comment 2•12 years ago
|
||
attachment 668315 [details] [diff] [review] is not a ideal solution. But imho, it is better than requesting high privilege to WebApp's process. bug 793034 is for ideal solution.
Reporter | ||
Comment 4•12 years ago
|
||
just nits (NULL -> nullptr)
Attachment #668315 -
Attachment is obsolete: true
Reporter | ||
Comment 5•12 years ago
|
||
(In reply to Chris Double (:doublec) from comment #3) > If we do this can't we just use OMXClient like we do on Android? Yes, we can use OMXClient in gonk, I think. I am going to confirm it today.
Comment 6•12 years ago
|
||
This approach would also avoid the need for the video recording code to instantiate its own OMX instance. It could use OMXClient as well.
Reporter | ||
Comment 7•12 years ago
|
||
change to use OMXClient. Then OMX instance is correctly reference counted. confirmed it works on my hardware(ics qualcomm). doublec, thanks for comment!
Attachment #668324 -
Attachment is obsolete: true
Reporter | ||
Updated•12 years ago
|
Attachment #668315 -
Attachment is obsolete: false
Reporter | ||
Updated•12 years ago
|
Attachment #668348 -
Attachment is patch: true
Reporter | ||
Updated•12 years ago
|
Attachment #668315 -
Attachment is obsolete: true
Comment 8•12 years ago
|
||
btw, Stagefright's software decoders run within the client process, so we would not need OMXClient when we are requesting a software decoder. However, using the same code path for both hardware and software decoders is probably a good idea.
Reporter | ||
Comment 9•12 years ago
|
||
I want to use same code path. but current source code is not efficient enough. We could create OMXClient in a stack like android is doing.
> OMXClient client;
> if (client.connect() != OK) {
> LOG("OMXClient failed to connect");
> sp<IOMX> omx = client.interface();
Reporter | ||
Updated•12 years ago
|
Summary: move back OMX instance to mediaserver process → Use OmxClient in OmxDecoder
Reporter | ||
Comment 10•12 years ago
|
||
changed to allocate OMXClient on a stack. It is not necessary OMXClient to be as a class member.
Attachment #668348 -
Attachment is obsolete: true
Reporter | ||
Updated•12 years ago
|
Attachment #675421 -
Attachment is patch: true
Reporter | ||
Updated•12 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•