Extracting properties from element causes hang

[Wes Miller]

Elsewhere I have posted to this forum a routine based on gst-inspect that queries the various properties and ancestry of a declared  element.  

I have used this routine today to extract information about a gstrtpbin element is a running pipeline (the inspection point is in the on_pad_added(0 callback).  The program hangs as the third property is queried (latency).

I have read other code that discusses the lock on elements and wonder if I am stuck behind some mutex or if there is some other reason a running element would block a g_object_get_property() (I think that what's blocking)?

And, of course, any suggestions for a method to make this work?

Warmly,

Wes

Have you tried using g_object_get() instead?

Not directly related to the issue but documentation recommends the usage of this one.

Rohit

On Thu, Dec 30, 2010 at 9:53 PM, Wes Miller <[hidden email]> wrote:

Elsewhere I have posted to this forum a routine based on gst-inspect that
queries the various properties and ancestry of a declared  element.

I have used this routine today to extract information about a gstrtpbin
element is a running pipeline (the inspection point is in the on_pad_added(0
callback).  The program hangs as the third property is queried (latency).

I have read other code that discusses the lock on elements and wonder if I
am stuck behind some mutex or if there is some other reason a running
element would block a g_object_get_property() (I think that what's
blocking)?

And, of course, any suggestions for a method to make this work?

Warmly,

Wes
--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Extracting-properties-from-element-causes-hang-tp3168471p3168471.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Wes Miller]

Rohit,

I tried your suggestion and found that it has exactly the same problem and a couple of others.  The value I'm after is in gstrtpbin:

 latency             : Default amount of ms to buffer in the jitterbuffers
                        flags: readable, writable
                        Unsigned Integer. Range: 0 - 4294967295 Default: 200 Current: 200

I tried skipping over "latency" and hung on "do-lost":

  do-lost             : Send an event downstream when a packet is lost
                        flags: readable, writable
                        Boolean. Default: false Current: false

Which, at least, confirms its not related to the datatype of the queried value.

Other suggestions happily accepted!

Wes

p.s. the "other" problems using g_object_get() are that it returns different datatypes for the values than does g_object_get_property().  For example, the "name" property is returned as a gchararray not as the expected G_TYPE_STRING.

[Edward Hervey]

On Mon, 2011-01-03 at 08:48 -0800, Wes Miller wrote:

  gstrtpbin holds an internal lock when adding those pads. That same
lock is used to query those properties.

>
> Wes
>
> p.s. the "other" problems using g_object_get() are that it returns different
> datatypes for the values than does g_object_get_property().  For example,
> the "name" property is returned as a gchararray not as the expected
> G_TYPE_STRING.

  And what would the difference between a gchar array (gchar*) and a
G_TYPE_STRING (gchar*) be ?

>



------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

On Mon, 2011-01-03 at 08:48 -0800, Wes Miller wrote:

> Which, at least, confirms its not related to the datatype of the queried
> value.

It won't depend on the data type, but on the locks taken by the
implementation.

> Other suggestions happily accepted!

Run your code in gdb. When it hangs, interrupt it and get the stack
trace (thread apply all bt). That should show you exactly where it hangs
(ie. what lock it tries to take ususally). Then you can look at the
implementation ..


> p.s. the "other" problems using g_object_get() are that it returns different
> datatypes for the values than does g_object_get_property().  For example,
> the "name" property is returned as a gchararray not as the expected
> G_TYPE_STRING.

Not quite sure what the problem is here or what you expect for
G_TYPE_STRING if not a char array.

Cheers
 -Tim




------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Wes Miller]

I stink at gdb.  I'll see where I get but I'm light on hope.


I guess I expected a string to be a string object with a length field and a pointer to the data and gchararray to be either a char xyz[234] or the "g" representation of a chararray.  I hadn't expected any difference in what wouyld be returned.  FWIW, the code I copied from gst-inspect sees them differently.

With g_object_get_property() this runs as expected:

      switch( G_VALUE_TYPE( &value ))
      {
         case G_TYPE_STRING:  // String

But with g_object_get() I get to the bailaout case for Unknown datatype, which prints Unknown datatype: gchararray (64).

The 64 appears to be the type index of gchararray.

So, I assume I'm missing the obvious and that they really are the same, but Tim's code caught it.

Wes