|
From: Rob C. <ro...@ti...> - 2009-11-04 02:25:24
|
Signed-off-by: Rob Clark <ro...@ti...>
---
omx/gstomx_base_filter.c | 24 ++------
omx/gstomx_base_sink.c | 21 ++------
omx/gstomx_base_src.c | 22 ++------
omx/gstomx_util.c | 133 +++++++++++++++++++++++++++++++++++-----------
omx/gstomx_util.h | 12 +++--
5 files changed, 123 insertions(+), 89 deletions(-)
diff --git a/omx/gstomx_base_filter.c b/omx/gstomx_base_filter.c
index 287f50c..6b90673 100644
--- a/omx/gstomx_base_filter.c
+++ b/omx/gstomx_base_filter.c
@@ -66,14 +66,14 @@ setup_ports (GstOmxBaseFilter *self)
param.nPortIndex = 0;
OMX_GetParameter (core->omx_handle, OMX_IndexParamPortDefinition, ¶m);
- self->in_port = g_omx_core_setup_port (core, ¶m);
+ g_omx_port_setup (self->in_port, ¶m);
gst_pad_set_element_private (self->sinkpad, self->in_port);
/* Output port configuration. */
param.nPortIndex = 1;
OMX_GetParameter (core->omx_handle, OMX_IndexParamPortDefinition, ¶m);
- self->out_port = g_omx_core_setup_port (core, ¶m);
+ g_omx_port_setup (self->out_port, ¶m);
gst_pad_set_element_private (self->srcpad, self->out_port);
if (g_getenv ("OMX_ALLOCATE_ON"))
@@ -115,7 +115,7 @@ change_state (GstElement *element,
switch (transition)
{
case GST_STATE_CHANGE_NULL_TO_READY:
- g_omx_core_init (core, self->omx_library, self->omx_component);
+ g_omx_core_init (core);
if (core->omx_state != OMX_StateLoaded)
{
ret = GST_STATE_CHANGE_FAILURE;
@@ -898,11 +898,9 @@ type_instance_init (GTypeInstance *instance,
self->use_timestamps = TRUE;
/* GOmx */
- {
- GOmxCore *gomx;
- self->gomx = gomx = g_omx_core_new ();
- gomx->object = self;
- }
+ self->gomx = g_omx_core_new (self, g_class);
+ self->in_port = g_omx_core_get_port (self->gomx, 0);
+ self->out_port = g_omx_core_get_port (self->gomx, 1);
self->ready_lock = g_mutex_new ();
@@ -922,16 +920,6 @@ type_instance_init (GTypeInstance *instance,
gst_element_add_pad (GST_ELEMENT (self), self->sinkpad);
gst_element_add_pad (GST_ELEMENT (self), self->srcpad);
- {
- const char *tmp;
- tmp = g_type_get_qdata (G_OBJECT_CLASS_TYPE (g_class),
- g_quark_from_static_string ("library-name"));
- self->omx_library = g_strdup (tmp);
- tmp = g_type_get_qdata (G_OBJECT_CLASS_TYPE (g_class),
- g_quark_from_static_string ("component-name"));
- self->omx_component = g_strdup (tmp);
- }
-
GST_LOG_OBJECT (self, "end");
}
diff --git a/omx/gstomx_base_sink.c b/omx/gstomx_base_sink.c
index b50564d..1f2e271 100644
--- a/omx/gstomx_base_sink.c
+++ b/omx/gstomx_base_sink.c
@@ -58,7 +58,7 @@ setup_ports (GstOmxBaseSink *self)
param.nPortIndex = 0;
OMX_GetParameter (core->omx_handle, OMX_IndexParamPortDefinition, ¶m);
- self->in_port = g_omx_core_setup_port (core, ¶m);
+ g_omx_port_setup (self->in_port, ¶m);
gst_pad_set_element_private (self->sinkpad, self->in_port);
}
@@ -420,7 +420,7 @@ activate_push (GstPad *pad,
static inline gboolean
omx_init (GstOmxBaseSink *self)
{
- g_omx_core_init (self->gomx, self->omx_library, self->omx_component);
+ g_omx_core_init (self->gomx);
if (self->gomx->omx_error)
return FALSE;
@@ -461,21 +461,8 @@ type_instance_init (GTypeInstance *instance,
GST_LOG_OBJECT (self, "begin");
/* GOmx */
- {
- GOmxCore *gomx;
- self->gomx = gomx = g_omx_core_new ();
- gomx->object = self;
- }
-
- {
- const char *tmp;
- tmp = g_type_get_qdata (G_OBJECT_CLASS_TYPE (g_class),
- g_quark_from_static_string ("library-name"));
- self->omx_library = g_strdup (tmp);
- tmp = g_type_get_qdata (G_OBJECT_CLASS_TYPE (g_class),
- g_quark_from_static_string ("component-name"));
- self->omx_component = g_strdup (tmp);
- }
+ self->gomx = g_omx_core_new (self, g_class);
+ self->in_port = g_omx_core_get_port (self->gomx, 0);
{
GstPad *sinkpad;
diff --git a/omx/gstomx_base_src.c b/omx/gstomx_base_src.c
index 9b02b22..e8a1c95 100644
--- a/omx/gstomx_base_src.c
+++ b/omx/gstomx_base_src.c
@@ -50,7 +50,7 @@ setup_ports (GstOmxBaseSrc *self)
param.nPortIndex = 0;
OMX_GetParameter (core->omx_handle, OMX_IndexParamPortDefinition, ¶m);
- self->out_port = g_omx_core_setup_port (core, ¶m);
+ g_omx_port_setup (self->out_port, ¶m);
if (self->setup_ports)
{
@@ -67,7 +67,7 @@ start (GstBaseSrc *gst_base)
GST_LOG_OBJECT (self, "begin");
- g_omx_core_init (self->gomx, self->omx_library, self->omx_component);
+ g_omx_core_init (self->gomx);
if (self->gomx->omx_error)
return GST_STATE_CHANGE_FAILURE;
@@ -453,22 +453,8 @@ type_instance_init (GTypeInstance *instance,
GST_LOG_OBJECT (self, "begin");
/* GOmx */
- {
- GOmxCore *gomx;
- self->gomx = gomx = g_omx_core_new ();
- gomx->object = self;
- }
-
- {
- const char *tmp;
- tmp = g_type_get_qdata (G_OBJECT_CLASS_TYPE (g_class),
- g_quark_from_static_string ("library-name"));
- self->omx_library = g_strdup (tmp);
- tmp = g_type_get_qdata (G_OBJECT_CLASS_TYPE (g_class),
- g_quark_from_static_string ("component-name"));
- self->omx_component = g_strdup (tmp);
- }
-
+ self->gomx = g_omx_core_new (self, g_class);
+ self->out_port = g_omx_core_get_port (self->gomx, 0);
GST_LOG_OBJECT (self, "end");
}
diff --git a/omx/gstomx_util.c b/omx/gstomx_util.c
index 39d900b..1cd224f 100644
--- a/omx/gstomx_util.c
+++ b/omx/gstomx_util.c
@@ -22,6 +22,7 @@
#include "gstomx_util.h"
#include <dlfcn.h>
+#include <string.h>
#include "gstomx.h"
@@ -76,9 +77,7 @@ omx_state_to_str (OMX_STATETYPE omx_state);
static inline const char *
omx_error_to_str (OMX_ERRORTYPE omx_error);
-static inline GOmxPort *
-g_omx_core_get_port (GOmxCore *core,
- guint index);
+static inline GOmxPort *get_port (GOmxCore *core, guint index);
static inline void
port_free_buffers (GOmxPort *port);
@@ -133,7 +132,7 @@ core_for_each_port (GOmxCore *core,
{
GOmxPort *port;
- port = g_omx_core_get_port (core, index);
+ port = get_port (core, index);
if (port)
func (port);
@@ -159,6 +158,7 @@ imp_new (const gchar *name)
void *handle;
imp->dl_handle = handle = dlopen (name, RTLD_LAZY);
+ GST_DEBUG ("dlopen(%s) -> %p", name, handle);
if (!handle)
{
g_warning ("%s\n", dlerror ());
@@ -264,13 +264,22 @@ g_omx_deinit (void)
* Core
*/
+/**
+ * Construct new core
+ *
+ * @object: the GstOmx object (ie. GstOmxBaseFilter, GstOmxBaseSrc, or
+ * GstOmxBaseSink). The GstOmx object should have "component-name"
+ * and "library-name" properties.
+ */
GOmxCore *
-g_omx_core_new (void)
+g_omx_core_new (gpointer object, gpointer klass)
{
GOmxCore *core;
core = g_new0 (GOmxCore, 1);
+ core->object = object;
+
core->ports = g_ptr_array_new ();
core->omx_state_condition = g_cond_new ();
@@ -282,12 +291,33 @@ g_omx_core_new (void)
core->omx_state = OMX_StateInvalid;
+ {
+ gchar *library_name, *component_name, *component_role;
+
+ library_name = g_type_get_qdata (G_OBJECT_CLASS_TYPE (klass),
+ g_quark_from_static_string ("library-name"));
+
+ component_name = g_type_get_qdata (G_OBJECT_CLASS_TYPE (klass),
+ g_quark_from_static_string ("component-name"));
+
+ component_role = g_type_get_qdata (G_OBJECT_CLASS_TYPE (klass),
+ g_quark_from_static_string ("component-role"));
+
+ g_object_set (core->object,
+ "component-role", component_role,
+ "component-name", component_name,
+ "library-name", library_name,
+ NULL);
+ }
+
return core;
}
void
g_omx_core_free (GOmxCore *core)
{
+ g_omx_core_deinit (core); /* just in case we didn't have a READY->NULL.. mainly for gst-inspect */
+
g_sem_free (core->port_sem);
g_sem_free (core->flush_sem);
g_sem_free (core->done_sem);
@@ -301,10 +331,23 @@ g_omx_core_free (GOmxCore *core)
}
void
-g_omx_core_init (GOmxCore *core,
- const gchar *library_name,
- const gchar *component_name)
+g_omx_core_init (GOmxCore *core)
{
+ gchar *library_name=NULL, *component_name=NULL;
+
+ if (core->omx_handle)
+ return;
+
+ GST_DEBUG_OBJECT (core->object, "loading: %s (%s)", component_name, library_name);
+
+ g_object_get (core->object,
+ "component-name", &component_name,
+ "library-name", &library_name,
+ NULL);
+
+ g_return_if_fail (component_name);
+ g_return_if_fail (library_name);
+
core->imp = request_imp (library_name);
if (!core->imp)
@@ -314,8 +357,15 @@ g_omx_core_init (GOmxCore *core,
(char *) component_name,
core,
&callbacks);
+
+ GST_DEBUG_OBJECT (core->object, "OMX_GetHandle(&%p) -> %d",
+ core->omx_handle, core->omx_error);
+
if (!core->omx_error)
core->omx_state = OMX_StateLoaded;
+
+ g_free (component_name);
+ g_free (library_name);
}
void
@@ -328,7 +378,12 @@ g_omx_core_deinit (GOmxCore *core)
core->omx_state == OMX_StateInvalid)
{
if (core->omx_handle)
+ {
core->omx_error = core->imp->sym_table.free_handle (core->omx_handle);
+ GST_DEBUG_OBJECT (core->object, "OMX_FreeHandle(%p) -> %d",
+ core->omx_handle, core->omx_error);
+ core->omx_handle = NULL;
+ }
}
release_imp (core->imp);
@@ -394,37 +449,29 @@ g_omx_core_unload (GOmxCore *core)
g_ptr_array_clear (core->ports);
}
-GOmxPort *
-g_omx_core_setup_port (GOmxCore *core,
- OMX_PARAM_PORTDEFINITIONTYPE *omx_port)
+static inline GOmxPort *
+get_port (GOmxCore *core, guint index)
{
- GOmxPort *port;
- guint index;
-
- index = omx_port->nPortIndex;
- port = g_omx_core_get_port (core, index);
-
- if (!port)
+ if (G_LIKELY (index < core->ports->len))
{
- port = g_omx_port_new (core);
- g_ptr_array_insert (core->ports, index, port);
+ return g_ptr_array_index (core->ports, index);
}
- g_omx_port_setup (port, omx_port);
-
- return port;
+ return NULL;
}
-static inline GOmxPort *
-g_omx_core_get_port (GOmxCore *core,
- guint index)
+GOmxPort *
+g_omx_core_get_port (GOmxCore *core, guint index)
{
- if (G_LIKELY (index < core->ports->len))
+ GOmxPort *port = get_port (core, index);
+
+ if (!port)
{
- return g_ptr_array_index (core->ports, index);
+ port = g_omx_port_new (core, index);
+ g_ptr_array_insert (core->ports, index, port);
}
- return NULL;
+ return port;
}
void
@@ -452,17 +499,31 @@ g_omx_core_flush_stop (GOmxCore *core)
core_for_each_port (core, g_omx_port_resume);
}
+/**
+ * Accessor for OMX component handle. If the OMX component is not constructed
+ * yet, this will trigger it to be constructed (OMX_GetHandle()). This should
+ * at least be used in places where g_omx_core_init() might not have been
+ * called yet (such as setting/getting properties)
+ */
+OMX_HANDLETYPE
+g_omx_core_get_handle (GOmxCore *core)
+{
+ if (!core->omx_handle) g_omx_core_init (core);
+ return core->omx_handle;
+}
+
/*
* Port
*/
GOmxPort *
-g_omx_port_new (GOmxCore *core)
+g_omx_port_new (GOmxCore *core, guint index)
{
GOmxPort *port;
port = g_new0 (GOmxPort, 1);
port->core = core;
+ port->port_index = index;
port->num_buffers = 0;
port->buffer_size = 0;
port->buffers = NULL;
@@ -508,6 +569,10 @@ g_omx_port_setup (GOmxPort *port,
port->buffer_size = omx_port->nBufferSize;
port->port_index = omx_port->nPortIndex;
+ GST_DEBUG_OBJECT (port->core->object,
+ "type=%d, num_buffers=%d, buffer_size=%d, port_index=%d",
+ port->type, port->num_buffers, port->buffer_size, port->port_index);
+
g_free (port->buffers);
port->buffers = g_new0 (OMX_BUFFERHEADERTYPE *, port->num_buffers);
}
@@ -840,6 +905,8 @@ EventHandler (OMX_HANDLETYPE omx_handle,
cmd = (OMX_COMMANDTYPE) data_1;
+ GST_DEBUG_OBJECT (core->object, "OMX_EventCmdComplete: %d", cmd);
+
switch (cmd)
{
case OMX_CommandStateSet:
@@ -858,6 +925,7 @@ EventHandler (OMX_HANDLETYPE omx_handle,
}
case OMX_EventBufferFlag:
{
+ GST_DEBUG_OBJECT (core->object, "OMX_EventBufferFlag");
if (data_2 & OMX_BUFFERFLAG_EOS)
{
g_omx_core_set_done (core);
@@ -866,6 +934,7 @@ EventHandler (OMX_HANDLETYPE omx_handle,
}
case OMX_EventPortSettingsChanged:
{
+ GST_DEBUG_OBJECT (core->object, "OMX_EventPortSettingsChanged");
/** @todo only on the relevant port. */
if (core->settings_changed_cb)
{
@@ -902,7 +971,7 @@ EmptyBufferDone (OMX_HANDLETYPE omx_handle,
GOmxPort *port;
core = (GOmxCore*) app_data;
- port = g_omx_core_get_port (core, omx_buffer->nInputPortIndex);
+ port = get_port (core, omx_buffer->nInputPortIndex);
GST_CAT_LOG_OBJECT (gstomx_util_debug, core->object, "omx_buffer=%p", omx_buffer);
got_buffer (core, port, omx_buffer);
@@ -919,7 +988,7 @@ FillBufferDone (OMX_HANDLETYPE omx_handle,
GOmxPort *port;
core = (GOmxCore *) app_data;
- port = g_omx_core_get_port (core, omx_buffer->nOutputPortIndex);
+ port = get_port (core, omx_buffer->nOutputPortIndex);
GST_CAT_LOG_OBJECT (gstomx_util_debug, core->object, "omx_buffer=%p", omx_buffer);
got_buffer (core, port, omx_buffer);
diff --git a/omx/gstomx_util.h b/omx/gstomx_util.h
index f0cf045..4857265 100644
--- a/omx/gstomx_util.h
+++ b/omx/gstomx_util.h
@@ -114,9 +114,9 @@ struct GOmxPort
void g_omx_init (void);
void g_omx_deinit (void);
-GOmxCore *g_omx_core_new (void);
+GOmxCore *g_omx_core_new (gpointer object, gpointer klass);
void g_omx_core_free (GOmxCore *core);
-void g_omx_core_init (GOmxCore *core, const gchar *library_name, const gchar *component_name);
+void g_omx_core_init (GOmxCore *core);
void g_omx_core_deinit (GOmxCore *core);
void g_omx_core_prepare (GOmxCore *core);
void g_omx_core_start (GOmxCore *core);
@@ -127,9 +127,11 @@ void g_omx_core_set_done (GOmxCore *core);
void g_omx_core_wait_for_done (GOmxCore *core);
void g_omx_core_flush_start (GOmxCore *core);
void g_omx_core_flush_stop (GOmxCore *core);
-GOmxPort *g_omx_core_setup_port (GOmxCore *core, OMX_PARAM_PORTDEFINITIONTYPE *omx_port);
+OMX_HANDLETYPE g_omx_core_get_handle (GOmxCore *core);
+GOmxPort *g_omx_core_get_port (GOmxCore *core, guint index);
-GOmxPort *g_omx_port_new (GOmxCore *core);
+
+GOmxPort *g_omx_port_new (GOmxCore *core, guint index);
void g_omx_port_free (GOmxPort *port);
void g_omx_port_setup (GOmxPort *port, OMX_PARAM_PORTDEFINITIONTYPE *omx_port);
void g_omx_port_push_buffer (GOmxPort *port, OMX_BUFFERHEADERTYPE *omx_buffer);
@@ -142,4 +144,6 @@ void g_omx_port_enable (GOmxPort *port);
void g_omx_port_disable (GOmxPort *port);
void g_omx_port_finish (GOmxPort *port);
+
+
#endif /* GSTOMX_UTIL_H */
--
1.6.3.2
|
|
From: Felipe C. <fel...@gm...> - 2009-11-04 14:31:16
|
Hi,
The subject is too long. See the 'discussion' section in 'man git-commit'[1].
On Wed, Nov 4, 2009 at 4:25 AM, Rob Clark <ro...@ti...> wrote:
>
> Signed-off-by: Rob Clark <ro...@ti...>
> ---
> omx/gstomx_base_filter.c | 24 ++------
> omx/gstomx_base_sink.c | 21 ++------
> omx/gstomx_base_src.c | 22 ++------
> omx/gstomx_util.c | 133 +++++++++++++++++++++++++++++++++++-----------
> omx/gstomx_util.h | 12 +++--
> 5 files changed, 123 insertions(+), 89 deletions(-)
[...]
> diff --git a/omx/gstomx_util.c b/omx/gstomx_util.c
> index 39d900b..1cd224f 100644
> --- a/omx/gstomx_util.c
> +++ b/omx/gstomx_util.c
> @@ -22,6 +22,7 @@
>
> #include "gstomx_util.h"
> #include <dlfcn.h>
> +#include <string.h>
>
> #include "gstomx.h"
>
> @@ -76,9 +77,7 @@ omx_state_to_str (OMX_STATETYPE omx_state);
> static inline const char *
> omx_error_to_str (OMX_ERRORTYPE omx_error);
>
> -static inline GOmxPort *
> -g_omx_core_get_port (GOmxCore *core,
> - guint index);
> +static inline GOmxPort *get_port (GOmxCore *core, guint index);
This doesn't fit with $subject, seems to be a logically independent
trivial rename that's also changing code-style at the same time.
> static inline void
> port_free_buffers (GOmxPort *port);
> @@ -133,7 +132,7 @@ core_for_each_port (GOmxCore *core,
> {
> GOmxPort *port;
>
> - port = g_omx_core_get_port (core, index);
> + port = get_port (core, index);
ditto.
> if (port)
> func (port);
> @@ -159,6 +158,7 @@ imp_new (const gchar *name)
> void *handle;
>
> imp->dl_handle = handle = dlopen (name, RTLD_LAZY);
> + GST_DEBUG ("dlopen(%s) -> %p", name, handle);
Again, that's a logically separate change.
> if (!handle)
> {
> g_warning ("%s\n", dlerror ());
> @@ -264,13 +264,22 @@ g_omx_deinit (void)
> * Core
> */
>
> +/**
> + * Construct new core
> + *
> + * @object: the GstOmx object (ie. GstOmxBaseFilter, GstOmxBaseSrc, or
> + * GstOmxBaseSink). The GstOmx object should have "component-name"
> + * and "library-name" properties.
> + */
Also doing more than advertised.
> GOmxCore *
> -g_omx_core_new (void)
> +g_omx_core_new (gpointer object, gpointer klass)
I'm not sure about passing a GObjectClass to the _new function. A
separate function would make more sense.
> {
> GOmxCore *core;
>
> core = g_new0 (GOmxCore, 1);
>
> + core->object = object;
> +
> core->ports = g_ptr_array_new ();
>
> core->omx_state_condition = g_cond_new ();
> @@ -282,12 +291,33 @@ g_omx_core_new (void)
>
> core->omx_state = OMX_StateInvalid;
>
> + {
> + gchar *library_name, *component_name, *component_role;
> +
> + library_name = g_type_get_qdata (G_OBJECT_CLASS_TYPE (klass),
> + g_quark_from_static_string ("library-name"));
> +
> + component_name = g_type_get_qdata (G_OBJECT_CLASS_TYPE (klass),
> + g_quark_from_static_string ("component-name"));
> +
> + component_role = g_type_get_qdata (G_OBJECT_CLASS_TYPE (klass),
> + g_quark_from_static_string ("component-role"));
"component-role"? Again, that's a completely independent change.
> + g_object_set (core->object,
> + "component-role", component_role,
> + "component-name", component_name,
> + "library-name", library_name,
> + NULL);
> + }
> +
> return core;
> }
>
> void
> g_omx_core_free (GOmxCore *core)
> {
> + g_omx_core_deinit (core); /* just in case we didn't have a READY->NULL.. mainly for gst-inspect */
That comment seems unnecessary; if that's the way it is, then that's
the way it is. But I'm worried about what would happen with multiple
calls to core_deinit.
> g_sem_free (core->port_sem);
> g_sem_free (core->flush_sem);
> g_sem_free (core->done_sem);
> @@ -301,10 +331,23 @@ g_omx_core_free (GOmxCore *core)
> }
>
> void
> -g_omx_core_init (GOmxCore *core,
> - const gchar *library_name,
> - const gchar *component_name)
> +g_omx_core_init (GOmxCore *core)
> {
> + gchar *library_name=NULL, *component_name=NULL;
> +
> + if (core->omx_handle)
> + return;
> +
> + GST_DEBUG_OBJECT (core->object, "loading: %s (%s)", component_name, library_name);
Unrelated change.
> + g_object_get (core->object,
> + "component-name", &component_name,
> + "library-name", &library_name,
> + NULL);
> +
> + g_return_if_fail (component_name);
> + g_return_if_fail (library_name);
If one component_name is there but not library_name there would be a
memory leak, right?
> core->imp = request_imp (library_name);
>
> if (!core->imp)
> @@ -314,8 +357,15 @@ g_omx_core_init (GOmxCore *core,
> (char *) component_name,
> core,
> &callbacks);
> +
> + GST_DEBUG_OBJECT (core->object, "OMX_GetHandle(&%p) -> %d",
> + core->omx_handle, core->omx_error);
Unrelated.
> if (!core->omx_error)
> core->omx_state = OMX_StateLoaded;
> +
> + g_free (component_name);
> + g_free (library_name);
> }
>
> void
> @@ -328,7 +378,12 @@ g_omx_core_deinit (GOmxCore *core)
> core->omx_state == OMX_StateInvalid)
> {
> if (core->omx_handle)
> + {
> core->omx_error = core->imp->sym_table.free_handle (core->omx_handle);
> + GST_DEBUG_OBJECT (core->object, "OMX_FreeHandle(%p) -> %d",
> + core->omx_handle, core->omx_error);
Unrelated.
> + core->omx_handle = NULL;
This one seems to be a fix... still unrelated.
> + }
> }
>
> release_imp (core->imp);
> @@ -394,37 +449,29 @@ g_omx_core_unload (GOmxCore *core)
> g_ptr_array_clear (core->ports);
> }
>
> -GOmxPort *
> -g_omx_core_setup_port (GOmxCore *core,
> - OMX_PARAM_PORTDEFINITIONTYPE *omx_port)
> +static inline GOmxPort *
> +get_port (GOmxCore *core, guint index)
> {
> - GOmxPort *port;
> - guint index;
> -
> - index = omx_port->nPortIndex;
> - port = g_omx_core_get_port (core, index);
> -
> - if (!port)
> + if (G_LIKELY (index < core->ports->len))
> {
> - port = g_omx_port_new (core);
> - g_ptr_array_insert (core->ports, index, port);
> + return g_ptr_array_index (core->ports, index);
> }
>
> - g_omx_port_setup (port, omx_port);
> -
> - return port;
> + return NULL;
> }
>
> -static inline GOmxPort *
> -g_omx_core_get_port (GOmxCore *core,
> - guint index)
> +GOmxPort *
> +g_omx_core_get_port (GOmxCore *core, guint index)
> {
> - if (G_LIKELY (index < core->ports->len))
> + GOmxPort *port = get_port (core, index);
> +
> + if (!port)
> {
> - return g_ptr_array_index (core->ports, index);
> + port = g_omx_port_new (core, index);
> + g_ptr_array_insert (core->ports, index, port);
> }
>
> - return NULL;
> + return port;
> }
>
> void
> @@ -452,17 +499,31 @@ g_omx_core_flush_stop (GOmxCore *core)
> core_for_each_port (core, g_omx_port_resume);
> }
>
> +/**
> + * Accessor for OMX component handle. If the OMX component is not constructed
> + * yet, this will trigger it to be constructed (OMX_GetHandle()). This should
> + * at least be used in places where g_omx_core_init() might not have been
> + * called yet (such as setting/getting properties)
> + */
> +OMX_HANDLETYPE
> +g_omx_core_get_handle (GOmxCore *core)
> +{
> + if (!core->omx_handle) g_omx_core_init (core);
> + return core->omx_handle;
> +}
Why do we want to do this?
> /*
> * Port
> */
>
> GOmxPort *
> -g_omx_port_new (GOmxCore *core)
> +g_omx_port_new (GOmxCore *core, guint index)
> {
> GOmxPort *port;
> port = g_new0 (GOmxPort, 1);
>
> port->core = core;
> + port->port_index = index;
> port->num_buffers = 0;
> port->buffer_size = 0;
> port->buffers = NULL;
> @@ -508,6 +569,10 @@ g_omx_port_setup (GOmxPort *port,
> port->buffer_size = omx_port->nBufferSize;
> port->port_index = omx_port->nPortIndex;
>
> + GST_DEBUG_OBJECT (port->core->object,
> + "type=%d, num_buffers=%d, buffer_size=%d, port_index=%d",
> + port->type, port->num_buffers, port->buffer_size, port->port_index);
Unrelated.
> g_free (port->buffers);
> port->buffers = g_new0 (OMX_BUFFERHEADERTYPE *, port->num_buffers);
> }
> @@ -840,6 +905,8 @@ EventHandler (OMX_HANDLETYPE omx_handle,
>
> cmd = (OMX_COMMANDTYPE) data_1;
>
> + GST_DEBUG_OBJECT (core->object, "OMX_EventCmdComplete: %d", cmd);
Unrelated.
> switch (cmd)
> {
> case OMX_CommandStateSet:
> @@ -858,6 +925,7 @@ EventHandler (OMX_HANDLETYPE omx_handle,
> }
> case OMX_EventBufferFlag:
> {
> + GST_DEBUG_OBJECT (core->object, "OMX_EventBufferFlag");
I think you got the point.
> if (data_2 & OMX_BUFFERFLAG_EOS)
> {
> g_omx_core_set_done (core);
> @@ -866,6 +934,7 @@ EventHandler (OMX_HANDLETYPE omx_handle,
> }
> case OMX_EventPortSettingsChanged:
> {
> + GST_DEBUG_OBJECT (core->object, "OMX_EventPortSettingsChanged");
> /** @todo only on the relevant port. */
> if (core->settings_changed_cb)
> {
> @@ -902,7 +971,7 @@ EmptyBufferDone (OMX_HANDLETYPE omx_handle,
> GOmxPort *port;
>
> core = (GOmxCore*) app_data;
> - port = g_omx_core_get_port (core, omx_buffer->nInputPortIndex);
> + port = get_port (core, omx_buffer->nInputPortIndex);
>
> GST_CAT_LOG_OBJECT (gstomx_util_debug, core->object, "omx_buffer=%p", omx_buffer);
> got_buffer (core, port, omx_buffer);
> @@ -919,7 +988,7 @@ FillBufferDone (OMX_HANDLETYPE omx_handle,
> GOmxPort *port;
>
> core = (GOmxCore *) app_data;
> - port = g_omx_core_get_port (core, omx_buffer->nOutputPortIndex);
> + port = get_port (core, omx_buffer->nOutputPortIndex);
>
> GST_CAT_LOG_OBJECT (gstomx_util_debug, core->object, "omx_buffer=%p", omx_buffer);
> got_buffer (core, port, omx_buffer);
> diff --git a/omx/gstomx_util.h b/omx/gstomx_util.h
> index f0cf045..4857265 100644
> --- a/omx/gstomx_util.h
> +++ b/omx/gstomx_util.h
> @@ -114,9 +114,9 @@ struct GOmxPort
> void g_omx_init (void);
> void g_omx_deinit (void);
>
> -GOmxCore *g_omx_core_new (void);
> +GOmxCore *g_omx_core_new (gpointer object, gpointer klass);
> void g_omx_core_free (GOmxCore *core);
> -void g_omx_core_init (GOmxCore *core, const gchar *library_name, const gchar *component_name);
> +void g_omx_core_init (GOmxCore *core);
> void g_omx_core_deinit (GOmxCore *core);
> void g_omx_core_prepare (GOmxCore *core);
> void g_omx_core_start (GOmxCore *core);
> @@ -127,9 +127,11 @@ void g_omx_core_set_done (GOmxCore *core);
> void g_omx_core_wait_for_done (GOmxCore *core);
> void g_omx_core_flush_start (GOmxCore *core);
> void g_omx_core_flush_stop (GOmxCore *core);
> -GOmxPort *g_omx_core_setup_port (GOmxCore *core, OMX_PARAM_PORTDEFINITIONTYPE *omx_port);
> +OMX_HANDLETYPE g_omx_core_get_handle (GOmxCore *core);
> +GOmxPort *g_omx_core_get_port (GOmxCore *core, guint index);
>
> -GOmxPort *g_omx_port_new (GOmxCore *core);
> +
> +GOmxPort *g_omx_port_new (GOmxCore *core, guint index);
> void g_omx_port_free (GOmxPort *port);
> void g_omx_port_setup (GOmxPort *port, OMX_PARAM_PORTDEFINITIONTYPE *omx_port);
> void g_omx_port_push_buffer (GOmxPort *port, OMX_BUFFERHEADERTYPE *omx_buffer);
> @@ -142,4 +144,6 @@ void g_omx_port_enable (GOmxPort *port);
> void g_omx_port_disable (GOmxPort *port);
> void g_omx_port_finish (GOmxPort *port);
>
> +
> +
Definitely not needed.
> #endif /* GSTOMX_UTIL_H */
> --
> 1.6.3.2
I'm not completely against this patch, but it's difficult to review
with so many unrelated changes, and at the end of the day I still
wonder; What's the point of this patch? I'm sure the purpose would be
revealed in latter patches, but each individual patch must make sense
on it's own: explain in detail on the commit message.
In general I try to answer these questions:
* What does the patch do?
* Why do we want it?
* What is the impact?
[1] http://www.kernel.org/pub/software/scm/git/docs/git-commit.html
--
Felipe Contreras
|
|
From: Rob C. <ro...@ti...> - 2009-11-04 15:17:29
|
Hi Felipe,
On Nov 4, 2009, at 8:31 AM, Felipe Contreras wrote:
> Hi,
>
> The subject is too long. See the 'discussion' section in 'man git-
> commit'[1].
>
> On Wed, Nov 4, 2009 at 4:25 AM, Rob Clark <ro...@ti...> wrote:
>>
>> Signed-off-by: Rob Clark <ro...@ti...>
>> ---
>> omx/gstomx_base_filter.c | 24 ++------
>> omx/gstomx_base_sink.c | 21 ++------
>> omx/gstomx_base_src.c | 22 ++------
>> omx/gstomx_util.c | 133 ++++++++++++++++++++++++++++++++++
>> +-----------
>> omx/gstomx_util.h | 12 +++--
>> 5 files changed, 123 insertions(+), 89 deletions(-)
>
> [...]
>
>> diff --git a/omx/gstomx_util.c b/omx/gstomx_util.c
>> index 39d900b..1cd224f 100644
>> --- a/omx/gstomx_util.c
>> +++ b/omx/gstomx_util.c
>> @@ -22,6 +22,7 @@
>>
>> #include "gstomx_util.h"
>> #include <dlfcn.h>
>> +#include <string.h>
>>
>> #include "gstomx.h"
>>
>> @@ -76,9 +77,7 @@ omx_state_to_str (OMX_STATETYPE omx_state);
>> static inline const char *
>> omx_error_to_str (OMX_ERRORTYPE omx_error);
>>
>> -static inline GOmxPort *
>> -g_omx_core_get_port (GOmxCore *core,
>> - guint index);
>> +static inline GOmxPort *get_port (GOmxCore *core, guint index);
>
> This doesn't fit with $subject, seems to be a logically independent
> trivial rename that's also changing code-style at the same time.
[RC] not really.. if you look a bit further down g_omx_core_get_port()
became a public (to the gstomx elements) API and most of the
functionality was split out into an internal get_port helper function
which is called by g_omx_core_get_port() and some other places.
Is your preference that additional parameters to a function go on
separate lines? If so, my mistake.. I thought that was only for
purposes of line wrapping long lines.
>
>> static inline void
>> port_free_buffers (GOmxPort *port);
>> @@ -133,7 +132,7 @@ core_for_each_port (GOmxCore *core,
>> {
>> GOmxPort *port;
>>
>> - port = g_omx_core_get_port (core, index);
>> + port = get_port (core, index);
>
> ditto.
>
>> if (port)
>> func (port);
>> @@ -159,6 +158,7 @@ imp_new (const gchar *name)
>> void *handle;
>>
>> imp->dl_handle = handle = dlopen (name, RTLD_LAZY);
>> + GST_DEBUG ("dlopen(%s) -> %p", name, handle);
>
> Again, that's a logically separate change.
[RC] hmm, yeah, that should have been one of the later patches..
looks like a couple small things slipped through in the process of
trying to re-organize the commits I had already made. When a lot of
different changes touch the same file, grouping them into different
commits isn't straightforward. (Hmm, need a way to 'git add' parts of
a file)
>
>> if (!handle)
>> {
>> g_warning ("%s\n", dlerror ());
>> @@ -264,13 +264,22 @@ g_omx_deinit (void)
>> * Core
>> */
>>
>> +/**
>> + * Construct new core
>> + *
>> + * @object: the GstOmx object (ie. GstOmxBaseFilter,
>> GstOmxBaseSrc, or
>> + * GstOmxBaseSink). The GstOmx object should have "component-
>> name"
>> + * and "library-name" properties.
>> + */
>
> Also doing more than advertised.
>
>> GOmxCore *
>> -g_omx_core_new (void)
>> +g_omx_core_new (gpointer object, gpointer klass)
>
> I'm not sure about passing a GObjectClass to the _new function. A
> separate function would make more sense.
[RC] yeah... but it is required to completely initialize the GOmxCore
object. (Or could the klass be retrieved from the gobject?)
The GOmxCore object isn't really complete w/o knowing the library and
component name. And I was trying to keep things simpler for the
gstomx element classes.
>
>> {
>> GOmxCore *core;
>>
>> core = g_new0 (GOmxCore, 1);
>>
>> + core->object = object;
>> +
>> core->ports = g_ptr_array_new ();
>>
>> core->omx_state_condition = g_cond_new ();
>> @@ -282,12 +291,33 @@ g_omx_core_new (void)
>>
>> core->omx_state = OMX_StateInvalid;
>>
>> + {
>> + gchar *library_name, *component_name, *component_role;
>> +
>> + library_name = g_type_get_qdata (G_OBJECT_CLASS_TYPE
>> (klass),
>> + g_quark_from_static_string ("library-name"));
>> +
>> + component_name = g_type_get_qdata (G_OBJECT_CLASS_TYPE
>> (klass),
>> + g_quark_from_static_string ("component-name"));
>> +
>> + component_role = g_type_get_qdata (G_OBJECT_CLASS_TYPE
>> (klass),
>> + g_quark_from_static_string ("component-role"));
>
> "component-role"? Again, that's a completely independent change.
[RC] yeah, that is another one that was supposed to be part of a later
commit but slipped through.. my bad
>
>> + g_object_set (core->object,
>> + "component-role", component_role,
>> + "component-name", component_name,
>> + "library-name", library_name,
>> + NULL);
>> + }
>> +
>> return core;
>> }
>>
>> void
>> g_omx_core_free (GOmxCore *core)
>> {
>> + g_omx_core_deinit (core); /* just in case we didn't have a
>> READY->NULL.. mainly for gst-inspect */
>
> That comment seems unnecessary; if that's the way it is, then that's
> the way it is. But I'm worried about what would happen with multiple
> calls to core_deinit.
[RC] yeah, I was running into a problem w/ gst-inspect otherwise. My
solution was to just make it ok to call g_omx_core_deinit() multiple
times.
>
>> g_sem_free (core->port_sem);
>> g_sem_free (core->flush_sem);
>> g_sem_free (core->done_sem);
>> @@ -301,10 +331,23 @@ g_omx_core_free (GOmxCore *core)
>> }
>>
>> void
>> -g_omx_core_init (GOmxCore *core,
>> - const gchar *library_name,
>> - const gchar *component_name)
>> +g_omx_core_init (GOmxCore *core)
>> {
>> + gchar *library_name=NULL, *component_name=NULL;
>> +
>> + if (core->omx_handle)
>> + return;
>> +
>> + GST_DEBUG_OBJECT (core->object, "loading: %s (%s)",
>> component_name, library_name);
>
> Unrelated change.
>
>> + g_object_get (core->object,
>> + "component-name", &component_name,
>> + "library-name", &library_name,
>> + NULL);
>> +
>> + g_return_if_fail (component_name);
>> + g_return_if_fail (library_name);
>
> If one component_name is there but not library_name there would be a
> memory leak, right?
[RC] yup.. but you get a useful assert message about what was screwed
up so you can fix it. Rather than just a segfault.
maybe those should be g_assert()'s, since it is pretty much a bad
situation of you don't know the component or library name.
>
>> core->imp = request_imp (library_name);
>>
>> if (!core->imp)
>> @@ -314,8 +357,15 @@ g_omx_core_init (GOmxCore *core,
>> (char *)
>> component_name,
>> core,
>> &callbacks);
>> +
>> + GST_DEBUG_OBJECT (core->object, "OMX_GetHandle(&%p) -> %d",
>> + core->omx_handle, core->omx_error);
>
> Unrelated.
>
>> if (!core->omx_error)
>> core->omx_state = OMX_StateLoaded;
>> +
>> + g_free (component_name);
>> + g_free (library_name);
>> }
>>
>> void
>> @@ -328,7 +378,12 @@ g_omx_core_deinit (GOmxCore *core)
>> core->omx_state == OMX_StateInvalid)
>> {
>> if (core->omx_handle)
>> + {
>> core->omx_error = core->imp->sym_table.free_handle (core-
>> >omx_handle);
>> + GST_DEBUG_OBJECT (core->object, "OMX_FreeHandle(%p) ->
>> %d",
>> + core->omx_handle, core->omx_error);
>
> Unrelated.
>
>> + core->omx_handle = NULL;
>
> This one seems to be a fix... still unrelated.
>
>> + }
>> }
>>
>> release_imp (core->imp);
>> @@ -394,37 +449,29 @@ g_omx_core_unload (GOmxCore *core)
>> g_ptr_array_clear (core->ports);
>> }
>>
>> -GOmxPort *
>> -g_omx_core_setup_port (GOmxCore *core,
>> - OMX_PARAM_PORTDEFINITIONTYPE *omx_port)
>> +static inline GOmxPort *
>> +get_port (GOmxCore *core, guint index)
>> {
>> - GOmxPort *port;
>> - guint index;
>> -
>> - index = omx_port->nPortIndex;
>> - port = g_omx_core_get_port (core, index);
>> -
>> - if (!port)
>> + if (G_LIKELY (index < core->ports->len))
>> {
>> - port = g_omx_port_new (core);
>> - g_ptr_array_insert (core->ports, index, port);
>> + return g_ptr_array_index (core->ports, index);
>> }
>>
>> - g_omx_port_setup (port, omx_port);
>> -
>> - return port;
>> + return NULL;
>> }
>>
>> -static inline GOmxPort *
>> -g_omx_core_get_port (GOmxCore *core,
>> - guint index)
>> +GOmxPort *
>> +g_omx_core_get_port (GOmxCore *core, guint index)
>> {
>> - if (G_LIKELY (index < core->ports->len))
>> + GOmxPort *port = get_port (core, index);
>> +
>> + if (!port)
>> {
>> - return g_ptr_array_index (core->ports, index);
>> + port = g_omx_port_new (core, index);
>> + g_ptr_array_insert (core->ports, index, port);
>> }
>>
>> - return NULL;
>> + return port;
>> }
>>
>> void
>> @@ -452,17 +499,31 @@ g_omx_core_flush_stop (GOmxCore *core)
>> core_for_each_port (core, g_omx_port_resume);
>> }
>>
>> +/**
>> + * Accessor for OMX component handle. If the OMX component is not
>> constructed
>> + * yet, this will trigger it to be constructed (OMX_GetHandle()).
>> This should
>> + * at least be used in places where g_omx_core_init() might not
>> have been
>> + * called yet (such as setting/getting properties)
>> + */
>> +OMX_HANDLETYPE
>> +g_omx_core_get_handle (GOmxCore *core)
>> +{
>> + if (!core->omx_handle) g_omx_core_init (core);
>> + return core->omx_handle;
>> +}
>
> Why do we want to do this?
[RC] this way, you can do things like GetConfig/GetParameter earlier
in startup. This was needed by some of the later patches, and is
basically the main purpose of the patch
>
>> /*
>> * Port
>> */
>>
>> GOmxPort *
>> -g_omx_port_new (GOmxCore *core)
>> +g_omx_port_new (GOmxCore *core, guint index)
>> {
>> GOmxPort *port;
>> port = g_new0 (GOmxPort, 1);
>>
>> port->core = core;
>> + port->port_index = index;
>> port->num_buffers = 0;
>> port->buffer_size = 0;
>> port->buffers = NULL;
>> @@ -508,6 +569,10 @@ g_omx_port_setup (GOmxPort *port,
>> port->buffer_size = omx_port->nBufferSize;
>> port->port_index = omx_port->nPortIndex;
>>
>> + GST_DEBUG_OBJECT (port->core->object,
>> + "type=%d, num_buffers=%d, buffer_size=%d, port_index=%d",
>> + port->type, port->num_buffers, port->buffer_size, port-
>> >port_index);
>
> Unrelated.
>
>> g_free (port->buffers);
>> port->buffers = g_new0 (OMX_BUFFERHEADERTYPE *, port-
>> >num_buffers);
>> }
>> @@ -840,6 +905,8 @@ EventHandler (OMX_HANDLETYPE omx_handle,
>>
>> cmd = (OMX_COMMANDTYPE) data_1;
>>
>> + GST_DEBUG_OBJECT (core->object,
>> "OMX_EventCmdComplete: %d", cmd);
>
> Unrelated.
>
>> switch (cmd)
>> {
>> case OMX_CommandStateSet:
>> @@ -858,6 +925,7 @@ EventHandler (OMX_HANDLETYPE omx_handle,
>> }
>> case OMX_EventBufferFlag:
>> {
>> + GST_DEBUG_OBJECT (core->object,
>> "OMX_EventBufferFlag");
>
> I think you got the point.
>
>> if (data_2 & OMX_BUFFERFLAG_EOS)
>> {
>> g_omx_core_set_done (core);
>> @@ -866,6 +934,7 @@ EventHandler (OMX_HANDLETYPE omx_handle,
>> }
>> case OMX_EventPortSettingsChanged:
>> {
>> + GST_DEBUG_OBJECT (core->object,
>> "OMX_EventPortSettingsChanged");
>> /** @todo only on the relevant port. */
>> if (core->settings_changed_cb)
>> {
>> @@ -902,7 +971,7 @@ EmptyBufferDone (OMX_HANDLETYPE omx_handle,
>> GOmxPort *port;
>>
>> core = (GOmxCore*) app_data;
>> - port = g_omx_core_get_port (core, omx_buffer->nInputPortIndex);
>> + port = get_port (core, omx_buffer->nInputPortIndex);
>>
>> GST_CAT_LOG_OBJECT (gstomx_util_debug, core->object, "omx_buffer=
>> %p", omx_buffer);
>> got_buffer (core, port, omx_buffer);
>> @@ -919,7 +988,7 @@ FillBufferDone (OMX_HANDLETYPE omx_handle,
>> GOmxPort *port;
>>
>> core = (GOmxCore *) app_data;
>> - port = g_omx_core_get_port (core, omx_buffer->nOutputPortIndex);
>> + port = get_port (core, omx_buffer->nOutputPortIndex);
>>
>> GST_CAT_LOG_OBJECT (gstomx_util_debug, core->object, "omx_buffer=
>> %p", omx_buffer);
>> got_buffer (core, port, omx_buffer);
>> diff --git a/omx/gstomx_util.h b/omx/gstomx_util.h
>> index f0cf045..4857265 100644
>> --- a/omx/gstomx_util.h
>> +++ b/omx/gstomx_util.h
>> @@ -114,9 +114,9 @@ struct GOmxPort
>> void g_omx_init (void);
>> void g_omx_deinit (void);
>>
>> -GOmxCore *g_omx_core_new (void);
>> +GOmxCore *g_omx_core_new (gpointer object, gpointer klass);
>> void g_omx_core_free (GOmxCore *core);
>> -void g_omx_core_init (GOmxCore *core, const gchar *library_name,
>> const gchar *component_name);
>> +void g_omx_core_init (GOmxCore *core);
>> void g_omx_core_deinit (GOmxCore *core);
>> void g_omx_core_prepare (GOmxCore *core);
>> void g_omx_core_start (GOmxCore *core);
>> @@ -127,9 +127,11 @@ void g_omx_core_set_done (GOmxCore *core);
>> void g_omx_core_wait_for_done (GOmxCore *core);
>> void g_omx_core_flush_start (GOmxCore *core);
>> void g_omx_core_flush_stop (GOmxCore *core);
>> -GOmxPort *g_omx_core_setup_port (GOmxCore *core,
>> OMX_PARAM_PORTDEFINITIONTYPE *omx_port);
>> +OMX_HANDLETYPE g_omx_core_get_handle (GOmxCore *core);
>> +GOmxPort *g_omx_core_get_port (GOmxCore *core, guint index);
>>
>> -GOmxPort *g_omx_port_new (GOmxCore *core);
>> +
>> +GOmxPort *g_omx_port_new (GOmxCore *core, guint index);
>> void g_omx_port_free (GOmxPort *port);
>> void g_omx_port_setup (GOmxPort *port, OMX_PARAM_PORTDEFINITIONTYPE
>> *omx_port);
>> void g_omx_port_push_buffer (GOmxPort *port, OMX_BUFFERHEADERTYPE
>> *omx_buffer);
>> @@ -142,4 +144,6 @@ void g_omx_port_enable (GOmxPort *port);
>> void g_omx_port_disable (GOmxPort *port);
>> void g_omx_port_finish (GOmxPort *port);
>>
>> +
>> +
>
> Definitely not needed.
>
>> #endif /* GSTOMX_UTIL_H */
>> --
>> 1.6.3.2
>
> I'm not completely against this patch, but it's difficult to review
> with so many unrelated changes, and at the end of the day I still
> wonder; What's the point of this patch? I'm sure the purpose would be
> revealed in latter patches, but each individual patch must make sense
> on it's own: explain in detail on the commit message.
>
[RC] yeah, sorry.. in process of making those changes I added a bunch
of traces (which is most of the unrelated changes).. but since they
were interleaved w/ actual changes, it isn't always easy to break them
into a separate commit after the fact. If you *really* want to see
those as a separate commit, I'll break them out.
either way, I'll resend the patch with the component-role stuff split
out.. that part really needs to go along w/ it's corresponding changes
in some other files
> In general I try to answer these questions:
> * What does the patch do?
> * Why do we want it?
> * What is the impact?
btw, I guess I should have put this in the commit msg, but main
purpose of the patch is to make it easier for the various element
classes to have properties which use OMX_{Get,Set}Parameter, for
example. This is used in some of the later commits. But was a big
enough change by itself that I wanted to break it into it's own commit.
Why do we want it? I think it simplifies usage of the GOmxCore/
GOmxPort utility classes by making it possible to initialize the core/
port objects in the element constructor while still deferring
instantiation of the OMX component (in the normal case) until where
they were previously instantiated. (For example, NULL_TO_READ state
change for classes that inherit from GstOmxBaseFilter)
The impact will come later, when some properties that use Get/
SetParameter() are introduced, that if the properties are set, the OMX
component will be instantiated earlier. But this is mainly only in
debug uses, such as if you use gst-inspect. In normal cases startup
order stays the same.
BR,
-R
>
> [1] http://www.kernel.org/pub/software/scm/git/docs/git-commit.html
>
> --
> Felipe Contreras
>
|
|
From: Felipe C. <fel...@gm...> - 2009-11-05 16:57:07
|
On Wed, Nov 4, 2009 at 5:17 PM, Rob Clark <ro...@ti...> wrote:
> On Nov 4, 2009, at 8:31 AM, Felipe Contreras wrote:
>> This doesn't fit with $subject, seems to be a logically independent
>> trivial rename that's also changing code-style at the same time.
>
> [RC] not really.. if you look a bit further down g_omx_core_get_port()
> became a public (to the gstomx elements) API and most of the functionality
> was split out into an internal get_port helper function which is called by
> g_omx_core_get_port() and some other places.
Ok, so it's a different function with essentially the same name.
BTW. No need to prefix your replies with "[RC]". I'm not sure why TI
people do that.
> Is your preference that additional parameters to a function go on separate
> lines? If so, my mistake.. I thought that was only for purposes of line
> wrapping long lines.
Well, yeah, that's how that function is right now. It probably doesn't
matter since the coding style will change, but it introduces noise in
the patch.
>> Again, that's a logically separate change.
>
> [RC] hmm, yeah, that should have been one of the later patches.. looks like
> a couple small things slipped through in the process of trying to
> re-organize the commits I had already made. When a lot of different changes
> touch the same file, grouping them into different commits isn't
> straightforward. (Hmm, need a way to 'git add' parts of a file)
git add --patch $file
>> I'm not sure about passing a GObjectClass to the _new function. A
>> separate function would make more sense.
>
> [RC] yeah... but it is required to completely initialize the GOmxCore
> object. (Or could the klass be retrieved from the gobject?)
It's not required right now, is it? The component_name and
library_name are only needed in the _init function.
> The GOmxCore object isn't really complete w/o knowing the library and
> component name. And I was trying to keep things simpler for the gstomx
> element classes.
Currently GOmxCore is independent of the actual OpenMAX
implementation. If you want to change that I think that should be a
different patch.
>>> + g_return_if_fail (component_name);
>>> + g_return_if_fail (library_name);
>>
>> If one component_name is there but not library_name there would be a
>> memory leak, right?
>
> [RC] yup.. but you get a useful assert message about what was screwed up so
> you can fix it. Rather than just a segfault.
g_return_if_fail is not fatal, it would just silently return.
> maybe those should be g_assert()'s, since it is pretty much a bad situation
> of you don't know the component or library name.
Maybe, unless we alternatively obtain those values from somewhere else
(not happening right now).
>>> +/**
>>> + * Accessor for OMX component handle. If the OMX component is not
>>> constructed
>>> + * yet, this will trigger it to be constructed (OMX_GetHandle()). This
>>> should
>>> + * at least be used in places where g_omx_core_init() might not have
>>> been
>>> + * called yet (such as setting/getting properties)
>>> + */
>>> +OMX_HANDLETYPE
>>> +g_omx_core_get_handle (GOmxCore *core)
>>> +{
>>> + if (!core->omx_handle) g_omx_core_init (core);
>>> + return core->omx_handle;
>>> +}
>>
>> Why do we want to do this?
>
> [RC] this way, you can do things like GetConfig/GetParameter earlier in
> startup. This was needed by some of the later patches, and is basically the
> main purpose of the patch
Perhaps, but I still don't see why another patch would *need* this. If
anything, g_omx_core_init should be called in some other strategic
place, not leaked in like this... it messes up the semantics of the
API.
>> I'm not completely against this patch, but it's difficult to review
>> with so many unrelated changes, and at the end of the day I still
>> wonder; What's the point of this patch? I'm sure the purpose would be
>> revealed in latter patches, but each individual patch must make sense
>> on it's own: explain in detail on the commit message.
>
> [RC] yeah, sorry.. in process of making those changes I added a bunch of
> traces (which is most of the unrelated changes).. but since they were
> interleaved w/ actual changes, it isn't always easy to break them into a
> separate commit after the fact. If you *really* want to see those as a
> separate commit, I'll break them out.
It is easy with git :)
http://gitcasts.com/posts/interactive-adding
> either way, I'll resend the patch with the component-role stuff split out..
> that part really needs to go along w/ it's corresponding changes in some
> other files
Thanks.
>> In general I try to answer these questions:
>> * What does the patch do?
>> * Why do we want it?
>> * What is the impact?
>
> btw, I guess I should have put this in the commit msg, but main purpose of
> the patch is to make it easier for the various element classes to have
> properties which use OMX_{Get,Set}Parameter, for example. This is used in
> some of the later commits. But was a big enough change by itself that I
> wanted to break it into it's own commit.
Yeah, exactly, this should go into the commit message. But it's still
not clear to me; anybody can do OMX_{Get,Set}Parameter already, and
the changes of component and library name seem completely independent
of that.
> Why do we want it? I think it simplifies usage of the GOmxCore/GOmxPort
> utility classes by making it possible to initialize the core/port objects in
> the element constructor while still deferring instantiation of the OMX
> component (in the normal case) until where they were previously
> instantiated. (For example, NULL_TO_READ state change for classes that
> inherit from GstOmxBaseFilter)
So you want to change the point at which OpenMAX is really
initialized? There's some patches ready pending merging that serialize
omx to gst state changes, although I'm not sure if they would be
useful to you; in my testing those would require dynamic port
configuration to work, and it doesn't seem to in TI's omx video
components.
> The impact will come later, when some properties that use Get/SetParameter()
> are introduced, that if the properties are set, the OMX component will be
> instantiated earlier. But this is mainly only in debug uses, such as if you
> use gst-inspect. In normal cases startup order stays the same.
I see. In that case the impact is: non-functional/code-reorganization
or something like that.
Anyway, I see you only have one branch of development. It's generally
not a good idea to do that because most probably one of the later
patches might depend on the first ones, so if the merge/review process
is slow for the initial patches, even if they are trivial, the
important changes would be delayed. If you have multiple branches,
then you can send multiple patch series for review at the same time.
For internal development you can merge all your branches into a
working branch. It sounds complicated but once you learn your git
ropes then it's easy :)
Cheers.
--
Felipe Contreras
|
|
From: Rob C. <ro...@ti...> - 2009-11-06 02:58:57
|
On Nov 5, 2009, at 10:56 AM, Felipe Contreras wrote:
> On Wed, Nov 4, 2009 at 5:17 PM, Rob Clark <ro...@ti...> wrote:
>> On Nov 4, 2009, at 8:31 AM, Felipe Contreras wrote:
>>> This doesn't fit with $subject, seems to be a logically independent
>>> trivial rename that's also changing code-style at the same time.
>>
>> [RC] not really.. if you look a bit further down
>> g_omx_core_get_port()
>> became a public (to the gstomx elements) API and most of the
>> functionality
>> was split out into an internal get_port helper function which is
>> called by
>> g_omx_core_get_port() and some other places.
>
> Ok, so it's a different function with essentially the same name.
>
> BTW. No need to prefix your replies with "[RC]". I'm not sure why TI
> people do that.
I guess just habit.. won't do that in future ;-)
>
>> Is your preference that additional parameters to a function go on
>> separate
>> lines? If so, my mistake.. I thought that was only for purposes of
>> line
>> wrapping long lines.
>
> Well, yeah, that's how that function is right now. It probably doesn't
> matter since the coding style will change, but it introduces noise in
> the patch.
>
>>> Again, that's a logically separate change.
>>
>> [RC] hmm, yeah, that should have been one of the later patches..
>> looks like
>> a couple small things slipped through in the process of trying to
>> re-organize the commits I had already made. When a lot of
>> different changes
>> touch the same file, grouping them into different commits isn't
>> straightforward. (Hmm, need a way to 'git add' parts of a file)
>
> git add --patch $file
>
>>> I'm not sure about passing a GObjectClass to the _new function. A
>>> separate function would make more sense.
>>
>> [RC] yeah... but it is required to completely initialize the GOmxCore
>> object. (Or could the klass be retrieved from the gobject?)
>
> It's not required right now, is it? The component_name and
> library_name are only needed in the _init function.
But the point of this patch was that _init() could be called upon
demand the first time the element needs to access the handle. So they
might be needed earlier than when _init() was traditionally called.
>
>> The GOmxCore object isn't really complete w/o knowing the library and
>> component name. And I was trying to keep things simpler for the
>> gstomx
>> element classes.
>
> Currently GOmxCore is independent of the actual OpenMAX
> implementation. If you want to change that I think that should be a
> different patch.
I'm not sure I quite catch your point.. the GOmxCore object represents
on instance of one OMX component.. and this requires both library name
and component name (and later in a later commit, when I add component-
role, the component role string as well)
but this could be split out into an earlier patch in the series
>
>>>> + g_return_if_fail (component_name);
>>>> + g_return_if_fail (library_name);
>>>
>>> If one component_name is there but not library_name there would be a
>>> memory leak, right?
>>
>> [RC] yup.. but you get a useful assert message about what was
>> screwed up so
>> you can fix it. Rather than just a segfault.
>
> g_return_if_fail is not fatal, it would just silently return.
yeah, agree.. should be g_assert()
(and if support to get these values from elsewhere, like a config
file, were added.. then we'd have to make sure the config file
actually contained these values at this point. So I don't think that
really changes anything.)
>
>> maybe those should be g_assert()'s, since it is pretty much a bad
>> situation
>> of you don't know the component or library name.
>
> Maybe, unless we alternatively obtain those values from somewhere else
> (not happening right now).
>
>>>> +/**
>>>> + * Accessor for OMX component handle. If the OMX component is not
>>>> constructed
>>>> + * yet, this will trigger it to be constructed
>>>> (OMX_GetHandle()). This
>>>> should
>>>> + * at least be used in places where g_omx_core_init() might not
>>>> have
>>>> been
>>>> + * called yet (such as setting/getting properties)
>>>> + */
>>>> +OMX_HANDLETYPE
>>>> +g_omx_core_get_handle (GOmxCore *core)
>>>> +{
>>>> + if (!core->omx_handle) g_omx_core_init (core);
>>>> + return core->omx_handle;
>>>> +}
>>>
>>> Why do we want to do this?
>>
>> [RC] this way, you can do things like GetConfig/GetParameter
>> earlier in
>> startup. This was needed by some of the later patches, and is
>> basically the
>> main purpose of the patch
>
> Perhaps, but I still don't see why another patch would *need* this. If
> anything, g_omx_core_init should be called in some other strategic
> place, not leaked in like this... it messes up the semantics of the
> API.
>
with the addition of call to g_omx_core_deinit() in
g_omx_core_deinit(), the OMX component won't be leaked.. unless the
GOmxCore itself was leaked, but that would be a problem in any case
>>> I'm not completely against this patch, but it's difficult to review
>>> with so many unrelated changes, and at the end of the day I still
>>> wonder; What's the point of this patch? I'm sure the purpose would
>>> be
>>> revealed in latter patches, but each individual patch must make
>>> sense
>>> on it's own: explain in detail on the commit message.
>>
>> [RC] yeah, sorry.. in process of making those changes I added a
>> bunch of
>> traces (which is most of the unrelated changes).. but since they were
>> interleaved w/ actual changes, it isn't always easy to break them
>> into a
>> separate commit after the fact. If you *really* want to see those
>> as a
>> separate commit, I'll break them out.
>
> It is easy with git :)
> http://gitcasts.com/posts/interactive-adding
ahh, that is the coolest thing since sliced bread
this will be very helpful, thx!
>
>> either way, I'll resend the patch with the component-role stuff
>> split out..
>> that part really needs to go along w/ it's corresponding changes in
>> some
>> other files
>
> Thanks.
>
>>> In general I try to answer these questions:
>>> * What does the patch do?
>>> * Why do we want it?
>>> * What is the impact?
>>
>> btw, I guess I should have put this in the commit msg, but main
>> purpose of
>> the patch is to make it easier for the various element classes to
>> have
>> properties which use OMX_{Get,Set}Parameter, for example. This is
>> used in
>> some of the later commits. But was a big enough change by itself
>> that I
>> wanted to break it into it's own commit.
>
> Yeah, exactly, this should go into the commit message. But it's still
> not clear to me; anybody can do OMX_{Get,Set}Parameter already, and
> the changes of component and library name seem completely independent
> of that.
>
>> Why do we want it? I think it simplifies usage of the GOmxCore/
>> GOmxPort
>> utility classes by making it possible to initialize the core/port
>> objects in
>> the element constructor while still deferring instantiation of the
>> OMX
>> component (in the normal case) until where they were previously
>> instantiated. (For example, NULL_TO_READ state change for classes
>> that
>> inherit from GstOmxBaseFilter)
>
> So you want to change the point at which OpenMAX is really
> initialized? There's some patches ready pending merging that serialize
> omx to gst state changes, although I'm not sure if they would be
> useful to you; in my testing those would require dynamic port
> configuration to work, and it doesn't seem to in TI's omx video
> components.
do you mind sending these patches to me? Even if they are only half-
baked and not ready to merge yet. I can have a look and see if I need
to change my patch to fit in better with these other patches
(btw, I have some later patches that I'm still working on for dynamic
port enable/disable/reconfig. Although these aren't for use w/ the
omap3 omx components that you are familiar with. And really has
nothing to do with this patch.)
>
>> The impact will come later, when some properties that use Get/
>> SetParameter()
>> are introduced, that if the properties are set, the OMX component
>> will be
>> instantiated earlier. But this is mainly only in debug uses, such
>> as if you
>> use gst-inspect. In normal cases startup order stays the same.
>
> I see. In that case the impact is: non-functional/code-reorganization
> or something like that.
>
> Anyway, I see you only have one branch of development. It's generally
> not a good idea to do that because most probably one of the later
> patches might depend on the first ones, so if the merge/review process
> is slow for the initial patches, even if they are trivial, the
> important changes would be delayed. If you have multiple branches,
> then you can send multiple patch series for review at the same time.
> For internal development you can merge all your branches into a
> working branch. It sounds complicated but once you learn your git
> ropes then it's easy :)
>
well, several of these early commits are laying groundwork for some
later commits.. so they aren't all completely independent. Although
some of them are, and different branches for the independent commits
probably would have simplified life.. but I'm learning new things
about git every day ;-)
BR,
-R
|
|
From: Felipe C. <fel...@gm...> - 2009-11-14 12:33:24
|
On Fri, Nov 6, 2009 at 4:58 AM, Rob Clark <ro...@ti...> wrote: > On Nov 5, 2009, at 10:56 AM, Felipe Contreras wrote: >> It's not required right now, is it? The component_name and >> library_name are only needed in the _init function. > > But the point of this patch was that _init() could be called upon demand the > first time the element needs to access the handle. So they might be needed > earlier than when _init() was traditionally called. I sent a reply to your personal mail explaining why this is a fundamental change, and we should probably wait until we have an omx registry implemented. > I'm not sure I quite catch your point.. the GOmxCore object represents on > instance of one OMX component.. and this requires both library name and > component name (and later in a later commit, when I add component-role, the > component role string as well) > > but this could be split out into an earlier patch in the series I'm saying GOmxCore is independent of the omx implementation when you call _new(), it's tied to it *only* when you call _init(). In theory you can call _deinit() and _init() again, and re-use it for a different implementation. I'm not saying this is good, or desirable, just the way it is, and that if you want to change that, that should be a different patch. >> g_return_if_fail is not fatal, it would just silently return. > > yeah, agree.. should be g_assert() > > (and if support to get these values from elsewhere, like a config file, were > added.. then we'd have to make sure the config file actually contained these > values at this point. So I don't think that really changes anything.) Unless the config file format makes that impossible. >> Perhaps, but I still don't see why another patch would *need* this. If >> anything, g_omx_core_init should be called in some other strategic >> place, not leaked in like this... it messes up the semantics of the >> API. > > with the addition of call to g_omx_core_deinit() in g_omx_core_deinit(), the > OMX component won't be leaked.. unless the GOmxCore itself was leaked, but > that would be a problem in any case I didn't mean "leak" as in memory leak. I meant as in silently tagged along to something completely different. If you need the _init() to happen sooner, then do a separate call to _init() sooner. >> So you want to change the point at which OpenMAX is really >> initialized? There's some patches ready pending merging that serialize >> omx to gst state changes, although I'm not sure if they would be >> useful to you; in my testing those would require dynamic port >> configuration to work, and it doesn't seem to in TI's omx video >> components. > > do you mind sending these patches to me? Even if they are only half-baked > and not ready to merge yet. I can have a look and see if I need to change > my patch to fit in better with these other patches > > (btw, I have some later patches that I'm still working on for dynamic port > enable/disable/reconfig. Although these aren't for use w/ the omap3 omx > components that you are familiar with. And really has nothing to do with > this patch.) Sure. I'm in the process of cleaning all the repos I've been working on for Maemo 5, among different machines and servers. I'm going to push my pending gst-openmax branches to github (personal repo) soon. > well, several of these early commits are laying groundwork for some later > commits.. so they aren't all completely independent. Although some of them > are, and different branches for the independent commits probably would have > simplified life.. but I'm learning new things about git every day ;-) Yeap, this is usually referred to as "feature branches", and it's not specific to git, but git makes to easy to work with them :) For example, in linux I have 'fc-cleanup', and 'fc-iommu-reorg' and these are completely independent, so I send the patch series for review independently too, and can be reviewed and merged in the same way. If 'fc-iommu-reorg' requires a try v5 that doesn't affect 'fc-cleanup' at all. Similarly, I start new branches based on the 'master' branch, so that they are independent of all the other patches I've done. I had a similar problem than you do when the 'maemo' branch in gst-openmax was huge, and it was not clear which patches should go into 'master', which into 'omap', which just dropped, and so on. But with a little bit of training on git commands such as chery-pick, rebase --interactive, and mergetool, it's even fun ;) Cheers. -- Felipe Contreras |
|
From: Rob C. <ro...@ti...> - 2009-11-23 05:44:37
|
On Nov 14, 2009, at 6:33 AM, Felipe Contreras wrote: > On Fri, Nov 6, 2009 at 4:58 AM, Rob Clark <ro...@ti...> wrote: >> On Nov 5, 2009, at 10:56 AM, Felipe Contreras wrote: >>> It's not required right now, is it? The component_name and >>> library_name are only needed in the _init function. >> >> But the point of this patch was that _init() could be called upon >> demand the >> first time the element needs to access the handle. So they might >> be needed >> earlier than when _init() was traditionally called. > > I sent a reply to your personal mail explaining why this is a > fundamental change, and we should probably wait until we have an omx > registry implemented. yeah, I'm starting to get your point about needing a registry.. it might be another month or so before I have much time to work on it, but I'd be happy to implement some sort of registry / config-file when I do have a bit more time. > >> I'm not sure I quite catch your point.. the GOmxCore object >> represents on >> instance of one OMX component.. and this requires both library name >> and >> component name (and later in a later commit, when I add component- >> role, the >> component role string as well) >> >> but this could be split out into an earlier patch in the series > > I'm saying GOmxCore is independent of the omx implementation when you > call _new(), it's tied to it *only* when you call _init(). In theory > you can call _deinit() and _init() again, and re-use it for a > different implementation. I'm not saying this is good, or desirable, > just the way it is, and that if you want to change that, that should > be a different patch. Is this a desirable feature to anyone? I'm not entirely sure how this fits in w/ a registry.. And in particular, I'm interested in being able to expose more settings of the OMX component thru properties (since that is nice for debug-ability in a lot of cases, and at least one of the new components I'm implementing will have a lot of configurability to expose to the application.. but I admit to be biased here because for the most part I'm only caring about a single OMX implementation ;-) > >>> g_return_if_fail is not fatal, it would just silently return. >> >> yeah, agree.. should be g_assert() >> >> (and if support to get these values from elsewhere, like a config >> file, were >> added.. then we'd have to make sure the config file actually >> contained these >> values at this point. So I don't think that really changes >> anything.) > > Unless the config file format makes that impossible. > >>> Perhaps, but I still don't see why another patch would *need* >>> this. If >>> anything, g_omx_core_init should be called in some other strategic >>> place, not leaked in like this... it messes up the semantics of the >>> API. >> >> with the addition of call to g_omx_core_deinit() in >> g_omx_core_deinit(), the >> OMX component won't be leaked.. unless the GOmxCore itself was >> leaked, but >> that would be a problem in any case > > I didn't mean "leak" as in memory leak. I meant as in silently tagged > along to something completely different. If you need the _init() to > happen sooner, then do a separate call to _init() sooner. > >>> So you want to change the point at which OpenMAX is really >>> initialized? There's some patches ready pending merging that >>> serialize >>> omx to gst state changes, although I'm not sure if they would be >>> useful to you; in my testing those would require dynamic port >>> configuration to work, and it doesn't seem to in TI's omx video >>> components. >> >> do you mind sending these patches to me? Even if they are only >> half-baked >> and not ready to merge yet. I can have a look and see if I need to >> change >> my patch to fit in better with these other patches >> >> (btw, I have some later patches that I'm still working on for >> dynamic port >> enable/disable/reconfig. Although these aren't for use w/ the >> omap3 omx >> components that you are familiar with. And really has nothing to >> do with >> this patch.) > > Sure. I'm in the process of cleaning all the repos I've been working > on for Maemo 5, among different machines and servers. I'm going to > push my pending gst-openmax branches to github (personal repo) soon. > >> well, several of these early commits are laying groundwork for some >> later >> commits.. so they aren't all completely independent. Although some >> of them >> are, and different branches for the independent commits probably >> would have >> simplified life.. but I'm learning new things about git every day ;-) > > Yeap, this is usually referred to as "feature branches", and it's not > specific to git, but git makes to easy to work with them :) > > For example, in linux I have 'fc-cleanup', and 'fc-iommu-reorg' and > these are completely independent, so I send the patch series for > review independently too, and can be reviewed and merged in the same > way. If 'fc-iommu-reorg' requires a try v5 that doesn't affect > 'fc-cleanup' at all. Similarly, I start new branches based on the > 'master' branch, so that they are independent of all the other patches > I've done. > > I had a similar problem than you do when the 'maemo' branch in > gst-openmax was huge, and it was not clear which patches should go > into 'master', which into 'omap', which just dropped, and so on. But > with a little bit of training on git commands such as chery-pick, > rebase --interactive, and mergetool, it's even fun ;) well, at least I'm learning a lot about git in the process ;-) BR, -R |
|
From: Stefan K. <en...@ho...> - 2009-11-23 22:12:22
|
hi,
Rob Clark schrieb:
> On Nov 14, 2009, at 6:33 AM, Felipe Contreras wrote:
>
>> On Fri, Nov 6, 2009 at 4:58 AM, Rob Clark <ro...@ti...> wrote:
>>> On Nov 5, 2009, at 10:56 AM, Felipe Contreras wrote:
>>>> It's not required right now, is it? The component_name and
>>>> library_name are only needed in the _init function.
>>> But the point of this patch was that _init() could be called upon
>>> demand the
>>> first time the element needs to access the handle. So they might
>>> be needed
>>> earlier than when _init() was traditionally called.
>> I sent a reply to your personal mail explaining why this is a
>> fundamental change, and we should probably wait until we have an omx
>> registry implemented.
>
>
> yeah, I'm starting to get your point about needing a registry.. it
> might be another month or so before I have much time to work on it,
> but I'd be happy to implement some sort of registry / config-file when
> I do have a bit more time.
>
It might be totally off topic, but are you aware that you can have custom data
in gstreamers registry. gst_plugin_{set,get}_cache_data allows you to store a
hierarchic structure within the registry.
Stefan
|
|
From: Rob C. <ro...@ti...> - 2009-11-24 01:59:50
|
On Nov 23, 2009, at 4:12 PM, Stefan Kost wrote:
> hi,
>
> Rob Clark schrieb:
>> On Nov 14, 2009, at 6:33 AM, Felipe Contreras wrote:
>>
>>> On Fri, Nov 6, 2009 at 4:58 AM, Rob Clark <ro...@ti...> wrote:
>>>> On Nov 5, 2009, at 10:56 AM, Felipe Contreras wrote:
>>>>> It's not required right now, is it? The component_name and
>>>>> library_name are only needed in the _init function.
>>>> But the point of this patch was that _init() could be called upon
>>>> demand the
>>>> first time the element needs to access the handle. So they might
>>>> be needed
>>>> earlier than when _init() was traditionally called.
>>> I sent a reply to your personal mail explaining why this is a
>>> fundamental change, and we should probably wait until we have an omx
>>> registry implemented.
>>
>>
>> yeah, I'm starting to get your point about needing a registry.. it
>> might be another month or so before I have much time to work on it,
>> but I'd be happy to implement some sort of registry / config-file
>> when
>> I do have a bit more time.
>>
>
> It might be totally off topic, but are you aware that you can have
> custom data
> in gstreamers registry. gst_plugin_{set,get}_cache_data allows you
> to store a
> hierarchic structure within the registry.
hmm... is there any way to get this information out of a human
readable config file of some sort?
BR,
-R
|
|
From: Stefan K. <en...@ho...> - 2009-11-24 15:00:49
|
Rob Clark wrote:
> On Nov 23, 2009, at 4:12 PM, Stefan Kost wrote:
>
>
>> hi,
>>
>> Rob Clark schrieb:
>>
>>> On Nov 14, 2009, at 6:33 AM, Felipe Contreras wrote:
>>>
>>>
>>>> On Fri, Nov 6, 2009 at 4:58 AM, Rob Clark <ro...@ti...> wrote:
>>>>
>>>>> On Nov 5, 2009, at 10:56 AM, Felipe Contreras wrote:
>>>>>
>>>>>> It's not required right now, is it? The component_name and
>>>>>> library_name are only needed in the _init function.
>>>>>>
>>>>> But the point of this patch was that _init() could be called upon
>>>>> demand the
>>>>> first time the element needs to access the handle. So they might
>>>>> be needed
>>>>> earlier than when _init() was traditionally called.
>>>>>
>>>> I sent a reply to your personal mail explaining why this is a
>>>> fundamental change, and we should probably wait until we have an omx
>>>> registry implemented.
>>>>
>>> yeah, I'm starting to get your point about needing a registry.. it
>>> might be another month or so before I have much time to work on it,
>>> but I'd be happy to implement some sort of registry / config-file
>>> when
>>> I do have a bit more time.
>>>
>>>
>> It might be totally off topic, but are you aware that you can have
>> custom data
>> in gstreamers registry. gst_plugin_{set,get}_cache_data allows you
>> to store a
>> hierarchic structure within the registry.
>>
>
> hmm... is there any way to get this information out of a human
> readable config file of some sort?
>
the registry cache is a cache and not a config. Do you need a cache or a
config? The idea of the cache is to cache things you normally lookup
(e.g. introspect plugins).
Stefan
> BR,
> -R
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Gstreamer-openmax mailing list
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax
>
|
|
From: Felipe C. <fel...@gm...> - 2009-11-24 17:10:34
|
On Tue, Nov 24, 2009 at 5:01 PM, Stefan Kost <en...@ho...> wrote: > the registry cache is a cache and not a config. Do you need a cache or a > config? The idea of the cache is to cache things you normally lookup > (e.g. introspect plugins). We need a config. So the same code creates multiple gst-openmax elements with different properties depending on such config. -- Felipe Contreras |
|
From: Rob C. <ro...@ti...> - 2009-11-24 21:57:29
|
On Nov 24, 2009, at 9:01 AM, Stefan Kost wrote:
>>>
>>> It might be totally off topic, but are you aware that you can have
>>> custom data
>>> in gstreamers registry. gst_plugin_{set,get}_cache_data allows you
>>> to store a
>>> hierarchic structure within the registry.
>>>
>>
>> hmm... is there any way to get this information out of a human
>> readable config file of some sort?
>>
> the registry cache is a cache and not a config. Do you need a cache
> or a
> config? The idea of the cache is to cache things you normally lookup
> (e.g. introspect plugins).
>
ah, no, config.. so maybe we should pick a name other than
"registry" so as to not confuse w/ gst registry
BR,
-R
|
|
From: Felipe C. <fel...@gm...> - 2009-11-24 11:30:08
|
On Mon, Nov 23, 2009 at 7:44 AM, Rob Clark <ro...@ti...> wrote: > On Nov 14, 2009, at 6:33 AM, Felipe Contreras wrote: >> I'm saying GOmxCore is independent of the omx implementation when you >> call _new(), it's tied to it *only* when you call _init(). In theory >> you can call _deinit() and _init() again, and re-use it for a >> different implementation. I'm not saying this is good, or desirable, >> just the way it is, and that if you want to change that, that should >> be a different patch. > > Is this a desirable feature to anyone? I'm not entirely sure how this fits > in w/ a registry.. It's probably not desirable, but as I said, it should be a different patch so it's easy to review; see the actual proposed change, and the impact, etc. -- Felipe Contreras |
|
From: Stefan K. <en...@ho...> - 2009-11-05 21:21:20
|
Rob Clark schrieb:
> Signed-off-by: Rob Clark <ro...@ti...>
> ---
> omx/gstomx_base_filter.c | 24 ++------
> omx/gstomx_base_sink.c | 21 ++------
> omx/gstomx_base_src.c | 22 ++------
> omx/gstomx_util.c | 133 +++++++++++++++++++++++++++++++++++-----------
> omx/gstomx_util.h | 12 +++--
> 5 files changed, 123 insertions(+), 89 deletions(-)
>
> void
> -g_omx_core_init (GOmxCore *core,
> - const gchar *library_name,
> - const gchar *component_name)
> +g_omx_core_init (GOmxCore *core)
> {
> + gchar *library_name=NULL, *component_name=NULL;
> +
> + if (core->omx_handle)
> + return;
> +
> + GST_DEBUG_OBJECT (core->object, "loading: %s (%s)", component_name, library_name);
> +
> + g_object_get (core->object,
> + "component-name", &component_name,
> + "library-name", &library_name,
> + NULL);
> +
> + g_return_if_fail (component_name);
> + g_return_if_fail (library_name);
> +
> core->imp = request_imp (library_name);
>
just use g_assert here, if that is never supposed to fail. g_return_if_fail is
to handle external wrong api usage (things that you can't control), and g_assert
is for own mistakes. People who are using stable releases of a software would
turn the assert off. When they ship their product and its well tested, they
could turn the g_return_if_fail off too (if there are not going to be other
users of the library).
Stefan
|
|
From: Rob C. <ro...@ti...> - 2009-11-06 02:33:44
|
On Nov 5, 2009, at 3:21 PM, Stefan Kost wrote:
> Rob Clark schrieb:
>> Signed-off-by: Rob Clark <ro...@ti...>
>> ---
>> omx/gstomx_base_filter.c | 24 ++------
>> omx/gstomx_base_sink.c | 21 ++------
>> omx/gstomx_base_src.c | 22 ++------
>> omx/gstomx_util.c | 133 ++++++++++++++++++++++++++++++++++
>> +-----------
>> omx/gstomx_util.h | 12 +++--
>> 5 files changed, 123 insertions(+), 89 deletions(-)
>>
>
>> void
>> -g_omx_core_init (GOmxCore *core,
>> - const gchar *library_name,
>> - const gchar *component_name)
>> +g_omx_core_init (GOmxCore *core)
>> {
>> + gchar *library_name=NULL, *component_name=NULL;
>> +
>> + if (core->omx_handle)
>> + return;
>> +
>> + GST_DEBUG_OBJECT (core->object, "loading: %s (%s)",
>> component_name, library_name);
>> +
>> + g_object_get (core->object,
>> + "component-name", &component_name,
>> + "library-name", &library_name,
>> + NULL);
>> +
>> + g_return_if_fail (component_name);
>> + g_return_if_fail (library_name);
>> +
>> core->imp = request_imp (library_name);
>>
>
> just use g_assert here, if that is never supposed to fail.
> g_return_if_fail is
> to handle external wrong api usage (things that you can't control),
> and g_assert
> is for own mistakes. People who are using stable releases of a
> software would
> turn the assert off. When they ship their product and its well
> tested, they
> could turn the g_return_if_fail off too (if there are not going to
> be other
> users of the library).
>
agreed.. should be g_assert since this is never supposed to fail..
when I re-submit, I'll change this.
BR,
-R
|
|
From: Stefan K. <en...@ho...> - 2009-11-25 07:43:51
|
Felipe Contreras wrote: > On Tue, Nov 24, 2009 at 5:01 PM, Stefan Kost <en...@ho...> wrote: > >> the registry cache is a cache and not a config. Do you need a cache or a >> config? The idea of the cache is to cache things you normally lookup >> (e.g. introspect plugins). >> > > We need a config. So the same code creates multiple gst-openmax > elements with different properties depending on such config. > > Is this to workaround missing introspection features in omx-il? Then I would simply call it (component-)metadata. Stefan |
|
From: Felipe C. <fel...@gm...> - 2009-11-25 16:48:21
|
On Wed, Nov 25, 2009 at 9:44 AM, Stefan Kost <en...@ho...> wrote:
> Is this to workaround missing introspection features in omx-il? Then I
> would simply call it (component-)metadata.
Consider a "registry/config" like this:
omx_nokiaaacdec = { .lib = "/usr/lib/libomxil-bellagio-nokia.so.1",
.component = "OMX.Nokia.audio_decoder.aac" }
omx_tiaacdec = { .lib = "/usr/lib/libOMX_Core.so", .component =
"OMX.TI.AUDIO.DECODE", .role = "audio_decode.dsp.aac" }
omx_mp3dec = { .lib = "/usr/lib/libOMX_Core.so", .component =
"OMX.TI.AUDIO.DECODE", .role = "audio_decode.dsp.mp3" }
omx_fooh264dec = { .lib = "/home/user/libfoovendor.so", .component =
"OMX.foo.video_decoder.h264", .priority = 257 }
I see no way this can be introspected, specially the libraries to
load. Once you have the library, component-name, and component-role,
then you can introspect the specific formats/profiles/levels
supported, etc.
--
Felipe Contreras
|
|
From: Stefan K. <en...@ho...> - 2009-11-25 19:28:22
|
Felipe Contreras schrieb:
> On Wed, Nov 25, 2009 at 9:44 AM, Stefan Kost <en...@ho...> wrote:
>> Is this to workaround missing introspection features in omx-il? Then I
>> would simply call it (component-)metadata.
>
> Consider a "registry/config" like this:
>
> omx_nokiaaacdec = { .lib = "/usr/lib/libomxil-bellagio-nokia.so.1",
> .component = "OMX.Nokia.audio_decoder.aac" }
> omx_tiaacdec = { .lib = "/usr/lib/libOMX_Core.so", .component =
> "OMX.TI.AUDIO.DECODE", .role = "audio_decode.dsp.aac" }
> omx_mp3dec = { .lib = "/usr/lib/libOMX_Core.so", .component =
> "OMX.TI.AUDIO.DECODE", .role = "audio_decode.dsp.mp3" }
> omx_fooh264dec = { .lib = "/home/user/libfoovendor.so", .component =
> "OMX.foo.video_decoder.h264", .priority = 257 }
>
> I see no way this can be introspected, specially the libraries to
> load. Once you have the library, component-name, and component-role,
> then you can introspect the specific formats/profiles/levels
> supported, etc.
>
Now it becomres more clear. Is each omx component one so? I was thinking of
having a .info file with each component (or a group of components). The info
file would have what you can't introspect from the .so.
Stefan
|
|
From: Stephen M. W. <ste...@xa...> - 2009-11-25 19:59:45
|
On 25/11/09 14:28, Stefan Kost wrote: > Felipe Contreras schrieb: > > > > I see no way this can be introspected, specially the libraries to > > load. Once you have the library, component-name, and component-role, > > then you can introspect the specific formats/profiles/levels > > supported, etc. > > Now it becomres more clear. Is each omx component one so? I was thinking of > having a .info file with each component (or a group of components). The > info file would have what you can't introspect from the .so. Trouble is, OpenMAX IL components may be supplied by third parties who know (or care) nothing of gst-openmax, and there may also be conflicts between components supplied by various third parties. The .info idea is good but insufficient for solving the problem. A configuration file is ideal for solving this problem. -- Stephen M. Webb Xandros www.xandros.com |