After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 700845 - gst_launch_parse api with nested bin
gst_launch_parse api with nested bin
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.36
Other Windows
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-05-22 15:57 UTC by pavan goyal
Modified: 2015-08-14 11:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description pavan goyal 2013-05-22 15:57:32 UTC 
The elements are finalized when terminating a pipeline with a single 'bin'
as follows.

G_MESSAGES_DEBUG=all GST_DEBUG_NO_COLOR=1
GST_DEBUG=st*:5,bin:5,*STATES:5,*PARENTAGE:5,*REFCOUNTING:5,*PIPELINE:5
gst-launch filesrc location = /home/frankie/seek/videos/aviTombRaider.avi !
avidemux ! bin.'(' ffdec_mpeg4 ! x264enc ')' ! mpegtsmux ! fakesink async=false


The elements are not finalized with two nested 'bins' as follows.

G_MESSAGES_DEBUG=all GST_DEBUG_NO_COLOR=1
GST_DEBUG=st*:5,bin:5,*STATES:5,*PARENTAGE:5,*REFCOUNTING:5,*PIPELINE:5
gst-launch bin.'('filesrc location =
/home/frankie/seek/videos/aviTombRaider.avi ! avidemux ! bin.'(' ffdec_mpeg4 !
x264enc ')' ! mpegtsmux ')' ! fakesink async=false

is it some known issue?
Comment 1 Sebastian Dröge (slomo) 2013-05-22 16:40:34 UTC 
Does this still happen with GStreamer 1.0?

What do you mean with finalized? If you need to create multiple bins it is recommended to properly do that in code instead of using the gst-launch syntax for that.
Comment 2 Chng JP 2013-06-04 12:38:25 UTC 
It seems that if the object ref count is not 0, dispose() or finalize() will not be call.
So we need to check if the object ref count is really 0.
Comment 3 Sebastian Dröge (slomo) 2013-06-04 15:12:36 UTC 
No, the refcount handling is just generally broken there. You should *never* manually check the refcount of any object, only use ref() and unref() properly.