To elaborate on Greg's point, the Video MIO (android_surface_output.cpp) is a passive node and the Audio MIO (android_audio_output.cpp) is an active node.
On Dec 16, 6:27 am, GregS <[email protected]> wrote: > 1) The media output node can handle media synchronization for passive > MIO components (see the MIO document in the opencore git repository > for more details). > 2) I guess it depends on the scope of the additions, but It may be > best to organize the additional components in a separate OMX core for > cleaner organization. > > On Dec 16, 7:54 am, Sachin <[email protected]> wrote: > > > Thanks Dave for the detailed explanation :) > > > Staying on similar lines: > > 1) I guess PV framework will handle the media sync in this (OMX > > adapter) case. please correct me. > > 2) Currently there are 2 cores available in the PV framework. For > > implementing OMX extensions, should we use PV OMX core or is vendor > > specific core recommended? > > > Thanks, > > Sachin > > > On Dec 12, 12:16 am, Dave Sparks <[email protected]> wrote: > > > > You could write an OMX source/sink adapter MIO. This is how the OMX > > > decoders are integrated into OpenCore. > > > > Data tunneling is achieved using an opaque pointer (I think it's > > > called "private_platform" that is passed between the decoder and MIO > > > by the framework. You'll see evidence of this in > > > android_surface_output.cpp where some of the hardware specific code > > > from the G1 leaked into the plaform code. In the future, we plan to > > > have a better abstraction layer for this. > > > > The recommended way to handle this is using a pmem or ashmem heap > > > instead of passing our physical addresses. For example, the decoder > > > may require physical memory addresses. Those addresses are allocated > > > in the pmem driver and mapped to virtual addresses in the application > > > processor. When the MIO gets the pmem heap, it can pass the fd and > > > offset into the video display driver where the physical memory address > > > can be retrieved. > > > > On Dec 11, 3:39 am, Sachin <[email protected]> wrote: > > > > > Hi, > > > > i have 2 queries about Android framework. > > > > > 1) Can we use OMX source and sink components instead of MIO components > > > > for capturing / rendering ? > > > > Does it have any impact on performance or conformance? > > > > > 2) Is it feasible to achieve the "data tunneling" in Android framework > > > > as supported by standard OMX components? > > > > If yes can this tunnel include source/sink, processing components to > > > > directly capture / render data ? > > > > If this is not directly supported in the current framework, how can > > > > this be achieved ? > > > > > thanks a lot, > > > > Sachin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
