[Gstreamer-openmax] [PATCH 2/2] add gst-openmax registry (config file)
Rob Clark
rob at ti.com
Fri Feb 26 19:22:49 PST 2010
On Feb 26, 2010, at 4:20 PM, Felipe Contreras wrote:
> On Sat, Feb 27, 2010 at 12:03 AM, Clark, Rob <rob at ti.com> 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
More information about the Gstreamer-openmax
mailing list