support mesa/gallium

[CapOM]

Hi,

Currently mesa provides omx backend using bellagio: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/omx/vid_dec.h
You can see it includes some bellagio-omx headers. And inherits classes from the base object it provides.

I am interested porting this to tizonia. Where should I look in tizonia-openmax-il repo for equivalent base class ?

The target for now is a simple PC x86 on a 4.2 linux kernel.
Thx

[juanrubio]

That sounds really cool.

First thing to note is that Tizonia is currently aligned to the IL 1.2 spec, which is not 100% backward compatible with 1.1.2, which is what Bellagio (and surely Mesa) are currently aligned with. The differences between specs are relatively minor, especially in base profile, and I've got in my TODO list to add a 1.1.2 compatibility mode (see #108). I definitely have plans to get this done, but it is just not there at the moment.

Regarding your question, Tizonia's approach to creating components is a bit different to Bellagio's. Instead of deriving from a base component class for the various domains, Tizonia components are created by registering "roles" with a common component infrastructure. Each role contains one or more specialised "ports" and a specialised "processor". There are a number of port classes in libtizonia that can either be used directly or inherited to create new ones. The ports, are of 5 main categories:

• Audio, Video, Image, Other, (like in the spec) and
• A "config" port, which is a special pseudo-port class that has as its only purpose to encapsulate any externally accessible component configuration that is not linked to an actual port, e.g. OMX_PARAM_CONTENTURITYPE.

And finally, the "processor" class, which is always derived in every component to include the buffer processing logic. This class contains "signal" handlers for various events that may occur in the component, like the transition to the various OMX states, port enable/disable events, buffer arrivals on any of the component ports, timer events, io events, etc.

So in summary, you create a component by registering one or more roles with the common common infrastructure, and each role contains the "factory" functions that create the following things:

• a config port
• one or more "domain" ports
• a processor

You can look into any of the components under "plugins", e.g. an mo3 decoder:
https://github.com/tizonia/tizonia-openmax-il/blob/master/plugins/mp3_decoder/src/mp3d.c

this component re-uses the stock config port, the stock mp3 port, and the stock pcm port, and registers its own "processor" class. See the entry point "OMX_ComponentInit" at the bottom of that file.

Note that any changes done to support #108 should not affect existing plugins, as this mode switch would be implemented in the common component infrastructure (libtizonia). So the plugins should be able to operate in one 1.1.2 or 1.2 modes by just recompiling (mode chosen at configuration time).

I hope this helps ! :-)

[CapOM]

Hi. Thx for the details it will be very helpful. I will have a try at some point in the next few weeks.

Question, does Tizonia support OMX_UseEGLImage ? I see tiz_api_UseEGLImage but I also see OMX_ErrorNotImplemented. I guess this is the default behavior if an element does not override it ?
Because I am really interested in this feature.
Thx

[tizonia]

Yes, you are totally right. That API is optional in the spec and I didn't have a need for it yet, so there is a bit infrastructure that is currently missing in libtizonia to enable components that could use it.

I've created #118 for this. I'll have a look next, I believe there is not a lot of work in it.

BR,
Juan

[CapOM]

There is a GSoC in progress:
Weekly progress: https://singhcodes.wordpress.com/
Official description: https://summerofcode.withgoogle.com/projects/#4737166321123328