[Gstreamer-openmax] Support for hardware codecs

Felipe Contreras felipe.contreras at gmail.com
Wed Feb 24 04:41:17 PST 2010


On Tue, Feb 23, 2010 at 4:42 AM, Clark, Rob <rob at ti.com> wrote:
> Ok, attached is a work-in-progress for what I'm thinking.. the basic idea is that the config file is just a list of GstStructure's, so no parser needed, just gst_structure_from_string().  These get stored within a parent GstStructure (so could be cached w/ gst_plugin_{get,set}_cache_data(), although that is not implemented yet.  The config file looks like:
>
> -----8<----------8<-----
> omx_mp3dec, library-name=libOMX_Core.so, component-name=OMX.TI.AUDIO.DECODE, component-role=audio_decode.dsp.mp3, rank=256;
> omx_aacdec, library-name=libOMX_Core.so, component-name=OMX.TI.AUDIO.DECODE, component-role=audio_decode.dsp.aac, rank=256;
> omx_volume, library-name=libomxil-bellagio.so.0, component-name=OMX.st.volume.component, rank=0;
> ...
> ----->8---------->8-----

We most probably will add more stuff so I think each element should
span more than one line.

> (the component-role field is optional, others are mandatory)

I think rank should also be optional.

> I left for now the library-name/component-name/component-role properties in the base src/filter/sink elements.  But now they are just read-only properties, showing what is configured via the config file.  I think this is useful to see in output of gst-inspect, diagrams generated from .dot files of the pipeline, etc.
>
> Right now I have a small default config, in case no config file is found.. but I could go either way on this, either making it complete or removing it altogether.  Anyone have any preference about whether the config file should just override a complete default table, or whether the config file should be mandatory?
>
> The patch won't apply as-is on the gst-openmax tree from freedesktop.org (in our tree we've added component-role and some other stuff), but I'm just sending it as an RFC.  If people like the idea, I'll rebase it on current master from fd.o (after cleaning up a couple of quick-n-dirty aspects of the patch).
>
> I've pushed the patch here, if this is an easier way for you to review:
>
>  http://gitorious.org/robclark-gstreamer/gst-openmax/commit/4a8e4064c9b698d03ffce735257758cd0b8999f1
>
> and since the patch seems to be too big and caused my original email to bounce, here it the link to the patch:

You didn't give me enough time to moderate it :) The patch doesn't
look too big, I wonder why it was deferred.

Anyway, the only important comment I have for now is that I think the
type should also be configurable (you can use g_type_from_name())

I'm thinking something like:

---
omx_mp3dec_ti:
	type: GstOmxMp3Dec
	library-name: libOMX_Core.so.0
	component-name: OMX.TI.AUDIO.DECODE
	component-role: audio_decode.dsp.mp3
	rank: 256

omx_mp3dec_nokia:
	type: GstOmxMp3Dec
	library-name: libomxil_bellagio.so.0
	component-name: OMX.nokia.audio_decode.mp3
	rank: 128
---

Oh, and I think the default configuration should be in a separate file.

Cheers.

-- 
Felipe Contreras




More information about the Gstreamer-openmax mailing list