Closed Bug 798202 Opened 7 years ago Closed 7 years ago

Use OmxClient in OmxDecoder

Categories

(Core :: Audio/Video, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 803471

People

(Reporter: sotaro, Unassigned)

References

Details

Attachments

(1 file, 3 obsolete files)

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.
OS: Windows 7 → Gonk
Hardware: x86_64 → ARM
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.
Depends on: 759506
Depends on: 791164
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.
If we do this can't we just use OMXClient like we do on Android?
just nits (NULL -> nullptr)
Attachment #668315 - Attachment is obsolete: true
(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.
This approach would also avoid the need for the video recording code to instantiate its own OMX instance. It could use OMXClient as well.
Attached patch change to use OmxClient (obsolete) — Splinter Review
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
Attachment #668315 - Attachment is obsolete: false
Attachment #668348 - Attachment is patch: true
Attachment #668315 - Attachment is obsolete: true
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.
Blocks: 798773
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();
Blocks: 803471
Summary: move back OMX instance to mediaserver process → Use OmxClient in OmxDecoder
changed to allocate OMXClient on a stack. It is not necessary OMXClient to be as a class member.
Attachment #668348 - Attachment is obsolete: true
Attachment #675421 - Attachment is patch: true
Depends on: 808907
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 803471
No longer blocks: 803471
You need to log in before you can comment on or make changes to this bug.