[Gstreamer-openmax] [PATCH 1/8] core: call OMX_GetHandle in g_omx_core_new
Clark, Rob
rob at ti.com
Tue Mar 23 15:36:58 PDT 2010
On Mar 23, 2010, at 5:25 PM, Felipe Contreras wrote:
> On Thu, Mar 18, 2010 at 1:58 AM, Rob Clark <rob at ti.com> wrote:
>> This way omx_handle is always valid, and can be used in get/set_property
>> methods.
>> ---
>
>> @@ -282,12 +285,22 @@ g_omx_core_new (void *object)
>>
>> core->omx_state = OMX_StateInvalid;
>>
>> + /* it is a bit awkward to have to pass the element's g_class to
>> + * g_omx_core_new(), but since this is called from type_inistance_init
>> + * function, we can't rely on G_OBJECT_TYPE()..
>> + */
>> + gstomx_get_component_info (core, G_TYPE_FROM_CLASS (g_class));
>
> I don't like this. It would be better to pass the GType directly.
>
> But also, it's messing up g_omx and gstomx_ functions... Can you move
> g_omx_core_new to gstomx.c and make it gstomx_core_new() or something
> like that?
I could do that for now.
But actually I would like to change the g_omx_ stuff to gstomx_.. I think there are some parts of logic, such as handling the share_buffer vs !share_buffer cases, which could be consolidated in GOmxPort (or GstOmxPort). Similar for handling of EOS.
And for upstream caps negotiation to work properly, we need to do a pad_alloc() before SendCommand(SetState, Idle) or SendCommand(EnablePort).. which could be more easily done in one place in GOmxPort.
This is probably the subject for another patch(set).. but I thought maybe now would be a good time to bring up the idea and see if anyone had any issue with it.
BR,
-R
>
> Cheers.
>
> --
> Felipe Contreras
More information about the Gstreamer-openmax
mailing list