Re: [Gstreamer-openmax] [PATCH 2/2] add gst-openmax registry (config file)

[Rob C. <ro...@ti...>]

On Feb 26, 2010, at 4:20 PM, Felipe Contreras wrote:

> On Sat, Feb 27, 2010 at 12:03 AM, Clark, Rob <ro...@ti...> wrote:
>> so something like:
>> 
>> -----
>> omx_dummy,
>>  type=GstOmxDummy,
>>  derived-type=GstOmxDummyOne,
>>  library-name=libomxil-bellagio.so,
>>  component-name=OMX.st.dummy,
>>  rank=0;
>> 
>> omx_dummy_2,
>>  type=GstOmxDummy,
>>  derived-type=GstOmxDummyTwo,
>>  library-name=libomxil-bellagio.so,
>>  component-name=OMX.bellagio.dummy,
>>  rank=256;
>> -----
> 
> Yeah, but type => parent, derived-type = type.
> 
>> it does make the config file more complex (one more thing to misconfigure), and then we need a bit more error handling, in case user specifies a type name that already exists..  so I'm not super-excited about that.
> 
> I don't think we need to spend so much code to check for duplicated
> types, the type register would fail. Besides, what happens if you
> derive from a class that's not GstOmx; I don't think the proneness to
> errors is increasing that much by adding one field more.
> 
>> Also, then we need an additional hash-table to map back to element name (or something like g_type_set_qdata())..  both is possible, but it makes the code slightly less simple.
> 
> Why do we need to map back to element names? As you said; the user can
> select any name anyways. (We are using g_type_set_qdata() already)
> 
>> using the element name as the type name seems a simple solution to both.
> 
> Yeah, it's simple but doesn't feel right to me. I am picturing myself
> reading some debug log, scratching my head and then saying: ohh,
> omx_dummy was the _class_ name!


ok, I thought about this for a bit, and think I came up with a reasonable compromise between avoiding too much complexity in the conf file in the simple case (one OMX component for one gst-openmax class), but enough flexibility to still handle the advanced case (multiple different OMX components using same gst-openmax class):

In the simple case, where there is only one OMX component for a particular gst-openmax class, you simply specify 'type', and no dynamic subclass is created:

-----
omx_mpeg4dec,
  type=GstOmxMpeg4Dec,
  library-name=libomxil-bellagio.so.0,
  component-name=OMX.st.video_decoder.mpeg4,
  rank=256;
-----

in this case, GstOmxMpeg4Dec is used directly with no dynamic subclass created.

But in the advanced case, if you want multiple different gst elements of different OMX component but same gst-openmax class, you specify the 'parent-type' (which is the real gst-openmax class), and 'type' (which is the dynamically generated child class):

-----
omx_dummy,
  parent-type=GstOmxDummy,
  type=GstOmxDummyOne,
  library-name=libomxil-bellagio.so.0,
  component-name=OMX.bellagio.dummy,
  rank=0;
omx_dummy_2,
  parent-type=GstOmxDummy,
  type=GstOmxDummyTwo,
  library-name=libomxil-bellagio.so.0,
  component-name=OMX.st.dummy2,
  rank=256;
-----

in this case 'GstOmxDummy' is the real class, and 'GstOmxDummyOne' and 'GstOmxDummyTwo' are both dynamically generated subclasses.

I will send a patch with this solution in a few minutes.  Let me know what you think.

BR,
-R


> 
> Cheers.
> 
> -- 
> Felipe Contreras