[Gstreamer-openmax] Support for hardware codecs

[Rob Clark]

On Feb 24, 2010, at 6:41 AM, Felipe Contreras wrote:

> 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.

ok, should default rank=GST_RANK_NONE?

> 
>> 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.


sorry, I think it was just over the threshold.. 

I'll be more patient next time ;-)


> 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
> ---


ok, that seems reasonable..  are you ok w/ basically same thing in GstStructure syntax:

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;

note, w/ GstStructure, we can easily add parameters later if we want:

omx_h264dec_ti,
	type=GstOmxH264Dec,
	library-name=libOMX_Core.so,
	component-name=OMX.TI.DUCATI1.VIDEO.H264D,
	src-formats=(fourcc){NV12,YUYV},
	rank=256;


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


ok, I'll do that..  expect an updated patch, rebased on latest gst-openmax master so you can more easily apply the patch and try it out


BR,
-R