From: Taylor C. P <ct...@cs...> - 2003-05-24 06:21:48
|
Hey everyone! I'm working on the xine-lib plugin and I'm at the part where I get to try to connect a GstBuffer into xine. right now, the way things look is kinda weird. I've written 2 plugins, a gstreamer plugin and a xine plugin. so it works like this, the xine plugin connects a gstreamer-stream into xine and the gstreamer plugin connects a xine-stream into gstreamer. now for my question. How does GstBuffer work in gstreamer? I noticed that there's a GST_BUFFER_MAXSIZE and GST_BUFFER_SIZE macro in gstbuffer.h. Is a "maxsize" equivalent to the streams' total size while a "size" is the size of the current buffer? And I'm going to venture a guess that a GstBufferPool is just a way of reusing GstBuffers to read an entire media stream? Thanks! Christopher Paul Taylor, Clemson University Computer Science Dept. |
From: Ronald B. <rb...@ro...> - 2003-05-24 07:38:20
|
Hey, On Sat, 2003-05-24 at 08:20, Taylor Christopher P wrote: > now for my question. How does GstBuffer work in gstreamer? I noticed that > there's a GST_BUFFER_MAXSIZE and GST_BUFFER_SIZE macro in gstbuffer.h. Is a > "maxsize" equivalent to the streams' total size while a "size" is the size > of the current buffer? Size is the part of the buffer that is in use. Maxsize is the total allocated size in this buffer. Size is what you're most lilely interested in. Maxsize is interesting for in-place conversions (like what audioconvert and colorspace do) - it allows one to see whether the current buffer is big enough to store the new data. > And I'm going to venture a guess that a GstBufferPool is just a way of > reusing GstBuffers to read an entire media stream? Yes. Though it's primary purpose - seen from how we currently use it - isn't to just reuse allocated data, but it's rather to take care of cases where you have to reuse data because you didn't allocate it. Think of a mmap()'ed or Shm'ed (DMA'able) memory area where you're reading a file from (filesrc), where you're reading video from (v4lsrc) or to (xvideosink), etc. You don't want to free the buffers, you rather want to tell the kernel that you're done using this part and that the kernel can move new data into it. HTH, Ronald -- Ronald Bultje <rb...@ro...> |
From: Brett K. <br...@fr...> - 2003-05-24 18:11:35
|
I haven't officially announced anything yet, but I'm currently working on a set of Perl bindings for GStreamer. However, I've encountered a problem with the API which makes it incredibly difficult to bind certain functions. In particular, I've encountered a number of functions (gst_autoplug_to_caps, gst_autoplug_to_renderers, etc) which take variable number of arguments, but don't offer a variant which takes a va_list structure (like vsprintf). Currently, the only way I can work around this is to directly call the class method, which does take a variable list. eg: oclass = GST_AUTOPLUG_CLASS(G_OBJECT_GET_CLASS(autoplug)); if (oclass->autoplug_to_caps) element = (oclass->autoplug_to_caps)(autoplug, srccaps, sinkccaps, vargs); Clearly, this isn't desirable, since I'm delving into the inner workings of the class, rather than using the published interface. So, the question is, can new variants be added which take va_list structures? Heck, I could implement these and provide patches to 0.6.1, if necessary. I'm thinking something like this: GstElement* gst_autoplug_capsv(GstAutoplug *autoplug, GstCaps *caps, GstCaps *sinkcaps, va_list ap); Brett. |
From: Benjamin O. <in...@pu...> - 2003-05-25 12:53:56
|
There exists bug 90471 in bugzilla about this. Please add patches and comments there. A varargs function would clearly make sense IMO. Benjamin On Sat, 24 May 2003, Brett Kosinski wrote: > I haven't officially announced anything yet, but I'm currently working on > a set of Perl bindings for GStreamer. However, I've encountered a problem > with the API which makes it incredibly difficult to bind certain > functions. > > In particular, I've encountered a number of functions > (gst_autoplug_to_caps, gst_autoplug_to_renderers, etc) which take variable > number of arguments, but don't offer a variant which takes a va_list > structure (like vsprintf). Currently, the only way I can work around this > is to directly call the class method, which does take a variable list. > eg: > > oclass = GST_AUTOPLUG_CLASS(G_OBJECT_GET_CLASS(autoplug)); > > if (oclass->autoplug_to_caps) > element = (oclass->autoplug_to_caps)(autoplug, srccaps, > sinkccaps, vargs); > > Clearly, this isn't desirable, since I'm delving into the inner workings > of the class, rather than using the published interface. So, the question > is, can new variants be added which take va_list structures? Heck, I > could implement these and provide patches to 0.6.1, if necessary. I'm > thinking something like this: > > GstElement* > gst_autoplug_capsv(GstAutoplug *autoplug, GstCaps *caps, > GstCaps *sinkcaps, va_list ap); > > Brett. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > gstreamer-devel mailing list > gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > |
From: Brett K. <br...@fr...> - 2003-05-26 00:26:05
|
The "have_type" signal in gsttypefind.c has its first argument defined as G_TYPE_POINTER. For the wrappers I'm creating, this isn't specific enough (since the callback code can't know how to marshall the parameter). I believe the type should be set to GST_TYPE_CAPS (since that's what's passed). Are there any arguments against this change? I can provide a patch (I didn't since the change is VERY simple). Brett. |
From: Ronald B. <rb...@ro...> - 2003-05-26 06:16:10
|
Hey Brett, On Mon, 2003-05-26 at 02:11, Brett Kosinski wrote: > The "have_type" signal in gsttypefind.c has its first argument defined as > G_TYPE_POINTER. For the wrappers I'm creating, this isn't specific enough > (since the callback code can't know how to marshall the parameter). I > believe the type should be set to GST_TYPE_CAPS (since that's what's > passed). Are there any arguments against this change? I can provide a > patch (I didn't since the change is VERY simple). gsttypefind.h has a bug here too, btw: void (*have_type) (GstElement *element); That should have a GstCaps *caps as second argument, of course. Concerning your change, most source files actually use G_TYPE_OBJECT since GstCaps is a derivative of it. GST_TYPE_CAPS isn't a base type in glib... I've applied the following patch (to CVS/HEAD): -- Index: gsttypefind.c =================================================================== RCS file: /cvsroot/gstreamer/gstreamer/gst/gsttypefind.c,v retrieving revision 1.30 diff -u -r1.30 gsttypefind.c --- gsttypefind.c 13 Apr 2003 00:55:08 -0000 1.30 +++ gsttypefind.c 26 May 2003 06:04:52 -0000 @@ -116,7 +116,7 @@ g_signal_new ("have_type", G_TYPE_FROM_CLASS (klass), G_SIGNAL_RUN_LAST, G_STRUCT_OFFSET (GstTypeFindClass, have_type), NULL, NULL, g_cclosure_marshal_VOID__POINTER, G_TYPE_NONE, 1, - G_TYPE_POINTER); + G_TYPE_OBJECT); gobject_class->set_property = GST_DEBUG_FUNCPTR (gst_type_find_set_property); gobject_class->get_property = GST_DEBUG_FUNCPTR (gst_type_find_get_property); Index: gsttypefind.h =================================================================== RCS file: /cvsroot/gstreamer/gstreamer/gst/gsttypefind.h,v retrieving revision 1.11 diff -u -r1.11 gsttypefind.h --- gsttypefind.h 17 Jan 2003 20:41:04 -0000 1.11 +++ gsttypefind.h 26 May 2003 06:04:52 -0000 @@ -57,7 +57,8 @@ GstElementClass parent_class; /* signals */ - void (*have_type) (GstElement *element); + void (*have_type) (GstElement *element, + GstCaps *caps); }; GType gst_type_find_get_type (void); -- That should be enough. Thanks for reporting, Ronald oh, one more thing, we normally use bugzilla (http://bugzilla.gnome.org/) for bug reporting like this, you might want to have a look at that too. -- Ronald Bultje <rb...@ro...> |
From: Benjamin O. <in...@pu...> - 2003-05-26 08:39:01
|
GstCaps is a G_TYPE_BOXED, not a GObject. Caps are derived from GstData. And I'm not sure wether you should use the fundamental type or the real type in signals. Benjamin On 26 May 2003, Ronald Bultje wrote: > Hey Brett, > > On Mon, 2003-05-26 at 02:11, Brett Kosinski wrote: > > The "have_type" signal in gsttypefind.c has its first argument defined as > > G_TYPE_POINTER. For the wrappers I'm creating, this isn't specific enough > > (since the callback code can't know how to marshall the parameter). I > > believe the type should be set to GST_TYPE_CAPS (since that's what's > > passed). Are there any arguments against this change? I can provide a > > patch (I didn't since the change is VERY simple). > > gsttypefind.h has a bug here too, btw: > > void (*have_type) (GstElement *element); > > That should have a GstCaps *caps as second argument, of course. > > Concerning your change, most source files actually use G_TYPE_OBJECT > since GstCaps is a derivative of it. GST_TYPE_CAPS isn't a base type in > glib... > > I've applied the following patch (to CVS/HEAD): > > -- > Index: gsttypefind.c > =================================================================== > RCS file: /cvsroot/gstreamer/gstreamer/gst/gsttypefind.c,v > retrieving revision 1.30 > diff -u -r1.30 gsttypefind.c > --- gsttypefind.c 13 Apr 2003 00:55:08 -0000 1.30 > +++ gsttypefind.c 26 May 2003 06:04:52 -0000 > @@ -116,7 +116,7 @@ > g_signal_new ("have_type", G_TYPE_FROM_CLASS (klass), G_SIGNAL_RUN_LAST, > G_STRUCT_OFFSET (GstTypeFindClass, have_type), NULL, NULL, > g_cclosure_marshal_VOID__POINTER, G_TYPE_NONE, 1, > - G_TYPE_POINTER); > + G_TYPE_OBJECT); > > gobject_class->set_property = GST_DEBUG_FUNCPTR (gst_type_find_set_property); > gobject_class->get_property = GST_DEBUG_FUNCPTR (gst_type_find_get_property); > Index: gsttypefind.h > =================================================================== > RCS file: /cvsroot/gstreamer/gstreamer/gst/gsttypefind.h,v > retrieving revision 1.11 > diff -u -r1.11 gsttypefind.h > --- gsttypefind.h 17 Jan 2003 20:41:04 -0000 1.11 > +++ gsttypefind.h 26 May 2003 06:04:52 -0000 > @@ -57,7 +57,8 @@ > GstElementClass parent_class; > > /* signals */ > - void (*have_type) (GstElement *element); > + void (*have_type) (GstElement *element, > + GstCaps *caps); > }; > > GType gst_type_find_get_type (void); > -- > > That should be enough. > > Thanks for reporting, > > Ronald > > oh, one more thing, we normally use bugzilla > (http://bugzilla.gnome.org/) for bug reporting like this, you might want > to have a look at that too. > > -- > Ronald Bultje <rb...@ro...> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > gstreamer-devel mailing list > gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > |
From: Brett K. <br...@fr...> - 2003-05-26 15:41:45
|
> GstCaps is a G_TYPE_BOXED, not a GObject. Caps are derived from GstData. > And I'm not sure wether you should use the fundamental type or the real > type in signals. Is it expected that people will manipulate the GstCaps itself, or will it always be treated as an opaque object? Because if it's the former, then it strikes me that we should be using the real type (otherwise, in a loosly typed language like Perl, we won't be able to map the object to its exact class). Brett. |
From: Ronald B. <R.S...@ph...> - 2003-05-26 09:13:41
|
Hey, At 10:38 AM 5/26/03 +0200, Benjamin Otte wrote: >GstCaps is a G_TYPE_BOXED, not a GObject. Caps are derived from GstData. >And I'm not sure wether you should use the fundamental type or the real >type in signals. Uhm, no, caps are derived from nothing (they're not GstData). But it's still a G_TYPE_BOXED, so you are right. Could you correct it please, I don't have CVS here at my work. If not, I'll correct it tonight. It's not a G_TYPE_POINTER, though (I asked on the gtk-list once, see http://mail.gnome.org/archives/gtk-list/2003-February/msg00003.html), GstCaps is registered as a boxed type, see gstcaps.c line 72. Ronald |
From: Brett K. <br...@fr...> - 2003-05-27 21:26:10
|
Wow, I'm just spamming the list today... Is there a known bug in CVS regarding the autoplugging stuff? The helloworld2 example in CVS doesn't appear to run... I type ./helloworld /home/mp3/Gershwin-Rhapsody_in_Blue.ogg And it says: INFO (29568: 0) Initializing GStreamer Core Library version 0.7.0.1 INFO (29568: 0) CPU features: (0c040843) MMX INFO (29568: 0) registry: loaded user_registry in 1.263518 seconds (/home/brettk/.gstreamer-0.7/registry.xml) and returns immediately without playing anything (the iterate() call is returning immediately). The same goes for the Perl version of helloworld2 that I wrote. Incidentally, I have a modified helloworld that uses vorbis, and it plays this file fine, which is what makes me wonder if the autoplugging stuff is the culprate. Of course, it could just be that my installation is hosed... On the bright side, at least my Perl version of helloworld2 behaves the same as the CVS version... that's gotta be good. :) Brett. |
From: Brett K. <br...@fr...> - 2003-05-31 02:00:11
Attachments:
funcs.diff
|
This patch implements the _valist equivalents of the gst_autoplug_to_(renderers|caps) functions, which, in their normal form, take a variable number of parameters. Brett. |
From: Thomas V. S. <th...@ur...> - 2003-05-31 14:24:56
|
hey brett, thanks for this patch, but please put it in bugzilla or it will get lost :) bugzilla.gnome.org Thanks ! On Sat, 2003-05-31 at 03:57, Brett Kosinski wrote: > This patch implements the _valist equivalents of the > gst_autoplug_to_(renderers|caps) functions, which, in their normal form, > take a variable number of parameters. > > Brett. Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> Get off that stuff, she said And I'll stone you instead Unchain yourself, said she And tie yourself to me <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/ |
From: Brett K. <br...@fr...> - 2003-05-31 17:37:00
|
> hey brett, > > thanks for this patch, but please put it in bugzilla or it will get lost > :) Whoops, I knew that... done! :) Brett. |
From: Brett K. <br...@fr...> - 2003-05-26 15:43:27
Attachments:
types.diff
|
As per my previous email, there are a bunch of cases where G_TYPE_POINTER is being used to specify types for signals when a specific type should probably used (unless there's some reason I'm not aware of for not specifying the type). The attached patch changes the parameters for these callbacks to specify the correct type in each case (assuming I got it right :). Note, there are a couple cases still left (mostly in the XML loading/saving stuff) that I haven't to fixed yet, simply because I haven't looked into how I'm going to bind that stuff yet. IOW, I don't care yet. :) I've also left out the patch for gsttypefind (the caps stuff) since there's still some question of how to handle that case. Brett. |
From: Brett K. <br...@fr...> - 2003-05-26 22:26:53
Attachments:
types.diff
|
Sorry about this... there were some bugs in the original patch. *sigh* Brett. |
From: Ronald B. <rb...@ro...> - 2003-05-29 15:06:03
|
Hey Brett, On Tue, 2003-05-27 at 00:23, Brett Kosinski wrote: > Sorry about this... there were some bugs in the original patch. *sigh* I'm working on getting back on the patches I missed in the past few days (was working on something else) - can you please give a "diff -u" patch instead of a "diff" patch? It's the standard way to give patches, and they're somewhat more readable for people that are integrating patches. Besides that, thanks for the work, I hope the bindings are starting to get along! Ronald -- Ronald Bultje <rb...@ro...> |
From: Brett K. <br...@fr...> - 2003-05-27 19:18:19
|
Here's the output from: gst-register --gst-plugin-path=/usr/local/lib/gstreamer-0.7 INFO (27894: 0) Adding plugin path: "/usr/local/lib/gstreamer-0.7" INFO (27894: 0) Initializing GStreamer Core Library version 0.7.0.1 INFO (27894: 0) CPU features: (0c040843) MMX trying to load global_registry INFO (27894: 0) Registry isn't writable error loading global_registry added path /usr/local/packages/gstreamer/lib/gstreamer-0.7 to user_registry rebuilding user_registry (/home/brettk/.gstreamer-0.7/registry.xml) added plugin gstputbits with 0 feature(s) added plugin gstgetbits with 0 feature(s) added plugin gstbytestream with 0 feature(s) added plugin gstindexers with 2 feature(s) added plugin gsttypes with 2 feature(s) added plugin gstoptwingoscheduler with 1 feature(s) added plugin gstoptgthreadscheduler with 1 feature(s) added plugin gstoptomegascheduler with 1 feature(s) added plugin gstoptscheduler with 1 feature(s) added plugin gstbasicwingoscheduler with 1 feature(s) added plugin gstbasicgthreadscheduler with 1 feature(s) added plugin gstbasicomegascheduler with 1 feature(s) added plugin gstelements with 14 feature(s) added plugin gstspider with 2 feature(s) added plugin autoplugger with 1 feature(s) added plugin autoplugcache with 1 feature(s) added plugin gststaticautoplugrender with 1 feature(s) added plugin gststaticautoplug with 1 feature(s) added plugin vorbis with 3 feature(s) added plugin sdlvideosink with 1 feature(s) added plugin jpegmmxenc with 1 feature(s) added plugin jpegmmxdec with 1 feature(s) added plugin lame with 1 feature(s) added plugin jpeg with 2 feature(s) added plugin ffmpegdecall with 1 feature(s) added plugin ffmpeg with 112 feature(s) added plugin esdmon with 1 feature(s) added plugin esdsink with 1 feature(s) added plugin gstaf with 3 feature(s) added plugin cdplayer with 1 feature(s) added plugin xvideosink with 1 feature(s) added plugin vcdsrc with 1 feature(s) added plugin qcamsrc with 1 feature(s) added plugin ossaudio with 3 feature(s) added plugin monkey audio with 3 feature(s) added plugin gstvideo with 0 feature(s) added plugin gstriff with 0 feature(s) added plugin gstresample with 0 feature(s) added plugin gstidct with 0 feature(s) added plugin gstaudio with 0 feature(s) added plugin modplug with 5 feature(s) added plugin lavenc with 1 feature(s) added plugin wavparse with 2 feature(s) added plugin wavenc with 1 feature(s) added plugin vumeter with 1 feature(s) added plugin volume with 1 feature(s) added plugin volenv with 1 feature(s) added plugin videotestsrc with 1 feature(s) added plugin videoscale with 1 feature(s) added plugin videocrop with 1 feature(s) added plugin vbidec with 1 feature(s) added plugin udp with 2 feature(s) added plugin synaesthesia with 1 feature(s) added plugin stereosplit with 1 feature(s) added plugin mono2stereo with 1 feature(s) added plugin stereo2mono with 1 feature(s) added plugin stereo with 1 feature(s) added plugin speed with 1 feature(s) added plugin spectrum with 1 feature(s) added plugin smpte with 1 feature(s) added plugin smooth with 1 feature(s) added plugin sinesrc with 1 feature(s) added plugin silence with 1 feature(s) added plugin rtjpeg with 2 feature(s) added plugin rtp with 2 feature(s) added plugin qtdemux with 2 feature(s) added plugin playondemand with 1 feature(s) added plugin passthrough with 1 feature(s) added plugin oneton with 1 feature(s) added plugin monoscope with 1 feature(s) added plugin mpeg1types with 2 feature(s) added plugin mpeg2types with 2 feature(s) added plugin mpegstream with 3 feature(s) added plugin mp3types with 2 feature(s) added plugin mp3parse with 1 feature(s) added plugin mpegaudio with 1 feature(s) added plugin mpeg2subt with 1 feature(s) added plugin mpeg2enc with 1 feature(s) added plugin mp1videoparse with 1 feature(s) added plugin system_encode with 1 feature(s) added plugin mpeg1enc with 1 feature(s) added plugin mixmatrix with 1 feature(s) added plugin median with 1 feature(s) added plugin level with 1 feature(s) added plugin mulaw with 2 feature(s) added plugin alaw with 2 feature(s) added plugin intfloatconvert with 2 feature(s) added plugin goom with 1 feature(s) added plugin flxdec with 2 feature(s) added plugin filter with 3 feature(s) added plugin festival with 2 feature(s) added plugin effectv with 8 feature(s) added plugin deinterlace with 1 feature(s) added plugin cutter with 1 feature(s) added plugin chart with 1 feature(s) added plugin cdxaparse with 2 feature(s) added plugin gstaudioconvert with 1 feature(s) added plugin asfdemux with 1 feature(s) added plugin avidemux with 2 feature(s) added plugin avimux with 1 feature(s) added plugin auparse with 2 feature(s) added plugin audioscale with 1 feature(s) added plugin adder with 1 feature(s) added plugin ac3parse with 1 feature(s) added plugin gstputbits with 0 feature(s) added plugin gstgetbits with 0 feature(s) added plugin gstbytestream with 0 feature(s) added plugin gstindexers with 2 feature(s) added plugin gsttypes with 2 feature(s) added plugin gstoptwingoscheduler with 1 feature(s) added plugin gstoptgthreadscheduler with 1 feature(s) added plugin gstoptomegascheduler with 1 feature(s) added plugin gstoptscheduler with 1 feature(s) added plugin gstbasicwingoscheduler with 1 feature(s) added plugin gstbasicgthreadscheduler with 1 feature(s) added plugin gstbasicomegascheduler with 1 feature(s) (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 212 (gst_object_ref): assertion `GST_IS_OBJECT (object)' failed (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 257 (gst_object_sink): assertion `GST_IS_OBJECT (object)' failed (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 212 (gst_object_ref): assertion `GST_IS_OBJECT (object)' failed (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 257 (gst_object_sink): assertion `GST_IS_OBJECT (object)' failed (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 212 (gst_object_ref): assertion `GST_IS_OBJECT (object)' failed (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 257 (gst_object_sink): assertion `GST_IS_OBJECT (object)' failed (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 212 (gst_object_ref): assertion `GST_IS_OBJECT (object)' failed (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 257 (gst_object_sink): assertion `GST_IS_OBJECT (object)' failed (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 212 (gst_object_ref): assertion `GST_IS_OBJECT (object)' failed (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 257 (gst_object_sink): assertion `GST_IS_OBJECT (object)' failed (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 212 (gst_object_ref): assertion `GST_IS_OBJECT (object)' failed (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 257 (gst_object_sink): assertion `GST_IS_OBJECT (object)' failed (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 212 (gst_object_ref): assertion `GST_IS_OBJECT (object)' failed (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 257 (gst_object_sink): assertion `GST_IS_OBJECT (object)' failed added plugin gstelements with 14 feature(s) (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 212 (gst_object_ref): assertion `GST_IS_OBJECT (object)' failed (process:27904): GStreamer-CRITICAL **: file gstobject.c: line 257 (gst_object_sink): assertion `GST_IS_OBJECT (object)' failed added plugin gstspider with 2 feature(s) added plugin autoplugger with 1 feature(s) added plugin autoplugcache with 1 feature(s) added plugin gststaticautoplugrender with 1 feature(s) added plugin gststaticautoplug with 1 feature(s) (process:27904): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GstPadTemplate' Segmentation fault The output XML registry contains this (notice where it stops): <?xml version="1.0"?> <GST-PluginRegistry> <gst-plugin-paths> <path>/usr/local/packages/gstreamer/lib/gstreamer-0.7</path> <path>/usr/local/lib/gstreamer-0.7</path> </gst-plugin-paths> <plugin> <name>gstputbits</name> <longname>Accelerated routines for putting bits into a data stream</longname> <filename>/usr/local/packages/gstreamer/lib/gstreamer-0.7/libgstputbits.so</filename> </plugin> <plugin> <name>gstgetbits</name> <longname>Accelerated routines for getting bits from a data stream</longname> <filename>/usr/local/packages/gstreamer/lib/gstreamer-0.7/libgstgetbits.so</filename> </plugin> <plugin> <name>gstbytestream</name> <longname>GstByteStream: a byte-oriented layer on top of buffer-passing</longname> <filename>/usr/local/packages/gstreamer/lib/gstreamer-0.7/libgstbytestream.so</filename> </plugin> <plugin> <name>gstindexers</name> <longname>A file index</longname> <filename>/usr/local/packages/gstreamer/lib/gstreamer-0.7/libgstindexers.so</filename> <feature typename="GstIndexFactory"> <name>fileindex</name> <longdesc>A index that stores entries in file</longdesc> </feature> <feature typename="GstIndexFactory"> <name>memindex</name> <longdesc>A index that stores entries in memory</longdesc> </feature> </plugin> <plugin> <name>gsttypes</name> <filename>/usr/local/packages/gstreamer/lib/gstreamer-0.7/libgsttypes.so</filename> <feature typename="GstTypeFactory"> <name>gsttypes_video/raw</name> <mime>video/raw</mime> <extensions>.raw</extensions> </feature> <feature typename="GstTypeFactory"> <name>gsttypes_audio/raw</name> <mime>audio/raw</mime> <extensions>.raw</extensions> </feature> </plugin> <plugin> <name>gstoptwingoscheduler</name> <longname>An optimal scheduler</longname> <filename>/usr/local/packages/gstreamer/lib/gstreamer-0.7/libgstoptwingoscheduler.so</filename> <feature typename="GstSchedulerFactory"> <name>optwingo</name> <longdesc>An optimal scheduler using wingo cothreads</longdesc> </feature> </plugin> <plugin> <name>gstoptgthreadscheduler</name> <longname>An optimal scheduler</longname> <filename>/usr/local/packages/gstreamer/lib/gstreamer-0.7/libgstoptgthreadscheduler.so</filename> <feature typename="GstSchedulerFactory"> <name>optgthread</name> <longdesc>An optimal scheduler using gthread cothreads</longdesc> </feature> </plugin> <plugin> <name>gstoptomegascheduler</name> <longname>An optimal scheduler</longname> <filename>/usr/local/packages/gstreamer/lib/gstreamer-0.7/libgstoptomegascheduler.so</filename> <feature typename="GstSchedulerFactory"> <name>optomega</name> <longdesc>An optimal scheduler using omega cothreads</longdesc> </feature> </plugin> <plugin> <name>gstoptscheduler</name> <longname>An optimal scheduler</longname> <filename>/usr/local/packages/gstreamer/lib/gstreamer-0.7/libgstoptscheduler.so</filename> <feature typename="GstSchedulerFactory"> <name>opt</name> <longdesc>An optimal scheduler using no cothreads</longdesc> </feature> </plugin> <plugin> <name>gstbasicwingoscheduler</name> <longname>A basic scheduler</longname> <filename>/usr/local/packages/gstreamer/lib/gstreamer-0.7/libgstbasicwingoscheduler.so</filename> <feature typename="GstSchedulerFactory"> <name>basicwingo</name> <longdesc>A basic scheduler using wingo cothreads</longdesc> </feature> </plugin> <plugin> <name>gstbasicgthreadscheduler</name> <longname>A basic scheduler</longname> <filename>/usr/local/packages/gstreamer/lib/gstreamer-0.7/libgstbasicgthreadscheduler.so</filename> <feature typename="GstSchedulerFactory"> <name>basicgthread</name> <longdesc>A basic scheduler using gthread cothreads</longdesc> </feature> </plugin> <plugin> <name>gstbasicomegascheduler</name> <longname>A basic scheduler</longname> <filename>/usr/local/packages/gstreamer/lib/gstreamer-0.7/libgstbasicomegascheduler.so</filename> <feature typename="GstSchedulerFactory"> <name>basicomega</name> <longdesc>A basic scheduler using omega cothreads</longdesc> </feature> </plugin> <plugin> <name>gstelements</name> <longname>Standard GST Elements</longname> <filename>/usr/local/packages/gstreamer/lib/gstreamer-0.7/libgstelements.so</filename> <fe --- As you can see, it appears to be a problem with the gstelements plugin, although I can't for the life of me, figure out what it is. Thoughts? I had this problem with 0.6.1 as well, but disabling the fakesink (I think) feature fixed the problem. Note, this is with a CVS version of gstreamer and gst-plugins (checked out a couple nights ago). Brett. |
From: David S. <ds...@sc...> - 2003-05-27 19:57:58
|
On Tue, May 27, 2003 at 01:10:45PM -0600, Brett Kosinski wrote: > Here's the output from: > > gst-register --gst-plugin-path=/usr/local/lib/gstreamer-0.7 ... > As you can see, it appears to be a problem with the gstelements plugin, > although I can't for the life of me, figure out what it is. Thoughts? I > had this problem with 0.6.1 as well, but disabling the fakesink (I think) > feature fixed the problem. > > Note, this is with a CVS version of gstreamer and gst-plugins (checked out > a couple nights ago). You're adding the plugin path twice (by specifying the command line option). See http://bugzilla.gnome.org/show_bug.cgi?id=112745 dave... |
From: Brett K. <br...@fr...> - 2003-05-27 20:53:47
|
> > As you can see, it appears to be a problem with the gstelements plugin, > > although I can't for the life of me, figure out what it is. Thoughts? I > > had this problem with 0.6.1 as well, but disabling the fakesink (I think) > > feature fixed the problem. > > > > Note, this is with a CVS version of gstreamer and gst-plugins (checked out > > a couple nights ago). > > You're adding the plugin path twice (by specifying the command line > option). See http://bugzilla.gnome.org/show_bug.cgi?id=112745 Well, first off, yes, that's the problem, but it's slightly more complex than that. The problem is that gst-register should NOT automatically add $(INST_LIBDIR) to the plugin path on startup if GST_PLUGIN_PATH is set or --gst-plugin-path is used. You see, in my system, I use stow to manage my custom packages. GStreamer is installed to /usr/local/packages/gstreamer and gst-plugins is installed to /usr/local/packages/gst-plugins. I then use stow to install the two to /usr/local/. However, gst-register automatically adds "/usr/local/packages/gstreamer/lib/gstreamer-0.7" to the plugin path without my permission, and so just running gst-register by itself will only detect the default plugin set (since the full set of plugins is, in actuality, available at /usr/local/lib/gstreamer-0.7). Of course, the workaround is to add "/usr/local/packages/gst-plugins/lib/gstreamer-0.7" to the plugin path, however I consider this incorrect, since the behaviour that I (and most people, I think) would assume is that any plugin path set (either through the GST_PLUGIN_PATH variable or with the --gst-plugin-path parameter) should overwrite any "default" settings in gst-register itself (think how the java CLASSPATH, or even the Unix PATH variable, is used). This way, I can set the plugin path to "/usr/local/lib/gstreamer-0.7" and have it do the right thing for my setup. Anyway, this is just MHO. Things are working now (thanks for the tip, BTW), so I'm happy. :) Brett. |
From: David S. <ds...@sc...> - 2003-05-27 21:06:33
|
On Tue, May 27, 2003 at 02:46:11PM -0600, Brett Kosinski wrote: > You see, in my system, I use stow to manage my custom packages. > GStreamer is installed to /usr/local/packages/gstreamer and gst-plugins is > installed to /usr/local/packages/gst-plugins. I then use stow to install > the two to /usr/local/. (This is rather tangential to the bug at hand, but...) You should probably be setting prefix=/usr/local during build, then running 'make install prefix=/usr/local/packages/gstreamer' (or similar) to install. This will cause the build system to compile in the correct (i.e., /usr/local/lib) pathnames, but install to a different place. This is the trick used by RPM and the Debian build system. Unless, of course, stow suggests doing something differently. I'm not familiar with it. dave... |
From: Brett K. <br...@fr...> - 2003-05-27 21:11:04
|
> > You see, in my system, I use stow to manage my custom packages. > > GStreamer is installed to /usr/local/packages/gstreamer and gst-plugins is > > installed to /usr/local/packages/gst-plugins. I then use stow to install > > the two to /usr/local/. > > (This is rather tangential to the bug at hand, but...) > > You should probably be setting prefix=/usr/local during build, then > running 'make install prefix=/usr/local/packages/gstreamer' (or > similar) to install. This will cause the build system to compile in Heh, I didn't even know that was possible. The things you learn... :) Well, it's too late now (well, it's not, but rebuilding takes far too long), but I'll definitely remember that for the future. :) Brett. |
From: Brett K. <br...@fr...> - 2003-05-30 17:14:27
|
Don't ask why I'm doing things this way, I have my reasons :), but for some reason, the following test program isn't doing what I expect. It seems like the second thread isn't pulling any data off the queue. The first statistics element generates output, indicating that the decoder is working and data is being pushed onto the queue, but nothing is generated at the second statistics node, hence my suspicion that, for some reason, the second thread isn't pulling the data. Any thoughts? #include <stdlib.h> #include <gst/gst.h> void eos(GstElement *element, gpointer data) { g_print("have eos, quitting\n"); gst_main_quit(); } void update(GstElement *element, gpointer data) { g_print("Stats update...\n"); } int main (int argc, char *argv[]) { GstElement *thread1, *thread2; GstElement *filesrc, *decoder, *queue, *sink; GstElement *stats1, *stats2; gst_init (&argc, &argv); thread1 = gst_thread_new("thread1"); thread2 = gst_thread_new("thread2"); filesrc = gst_element_factory_make("filesrc", "input"); g_object_set(G_OBJECT(filesrc), "location", argv[1], NULL); decoder = gst_element_factory_make("vorbisfile", "decoder"); queue = gst_element_factory_make("queue", "queue"); sink = gst_element_factory_make("osssink", "sink"); stats1 = gst_element_factory_make("statistics", "stats1"); stats2 = gst_element_factory_make("statistics", "stats2"); g_object_set(G_OBJECT(stats1), "buffer_update_freq", 5, NULL); g_object_set(G_OBJECT(stats2), "buffer_update_freq", 5, NULL); gst_bin_add_many(GST_BIN(thread1), filesrc, decoder, stats1, queue, NULL); gst_bin_add_many(GST_BIN(thread2), stats2, sink, NULL); gst_element_link_many(filesrc, decoder, stats1, queue, stats2, sink, NULL); g_signal_connect(G_OBJECT(filesrc), "eos", G_CALLBACK(eos), NULL); g_signal_connect(G_OBJECT(stats1), "update", G_CALLBACK(update), NULL); g_signal_connect(G_OBJECT(stats2), "update", G_CALLBACK(update), NULL); gst_element_set_state(thread1, GST_STATE_READY); gst_element_set_state(thread2, GST_STATE_READY); gst_element_set_state(thread1, GST_STATE_PLAYING); gst_element_set_state(thread2, GST_STATE_PLAYING); gst_main(); return 0; } |
From: Brett K. <br...@fr...> - 2003-06-04 21:32:45
Attachments:
padtemplatenew.diff
|
Subject says it all. gst_pad_template_new takes a variable number of arguments, so this patch adds a _valist equivalent. Hopefully there wasn't a Bugzilla bug I should've posted this under... :) Brett. |
From: David S. <ds...@sc...> - 2003-06-04 22:13:52
|
On Wed, Jun 04, 2003 at 03:31:37PM -0600, Brett Kosinski wrote: > Subject says it all. gst_pad_template_new takes a variable number of > arguments, so this patch adds a _valist equivalent. > > Hopefully there wasn't a Bugzilla bug I should've posted this under... :) ${N}+1, please. :) By the way, you forgot to fix the documentation block for the new function. dave... |
From: Brett K. <br...@fr...> - 2003-06-07 17:33:40
|
> On Wed, Jun 04, 2003 at 03:31:37PM -0600, Brett Kosinski wrote: > > Subject says it all. gst_pad_template_new takes a variable number of > > arguments, so this patch adds a _valist equivalent. > > > > Hopefully there wasn't a Bugzilla bug I should've posted this under... :) > > ${N}+1, please. :) Heh, of course... :) > By the way, you forgot to fix the documentation block for the new > function. Ahh, thx, I'll take care of that. Brett. |