[gst-devel] Error : App hangs when I try to test my source plugin

[Krishnakumar Ramachandran]

Hi,

 Thanks for all the help. The issue got resolved. The issue was that I had
multiple sinks and I wan not using any queues. I tried what  Thabelo
suggested and saw that the pipeline is stuck when trying to preroll. I used
queues to connect to my source and everything worked fine.

Arnout,

   I have no choice on this matter as I am trying to make a gstreamer plugin
out of some existing library. I don't have the source of the library. The
library reads data from a stream, demuxes it and gives me separate outputs.
Thanks once again for all your help.

Regards
KK

On Wed, Jun 10, 2009 at 8:39 PM, Arnout Vandecappelle <arnout at mind.be>wrote:

> On Wednesday 10 June 2009 10:21:26 Krishnakumar Ramachandran wrote:
> >  I am trying to create a sample source plugin with 2 source pads. (My
> large
> > idea is to include a demux also in the source plugin and at that point in
> > time one pad will push audio and the other will push video. But as of now
> > both pads are of type "ANY"). To test my plugin, I am trying to connect
> it
> > to two filesinks (i.e each source pad is connected to the sink pad of a
> > filesink). So the pipeline has 3 plugins. My test source  and 2
> filesinks.
> > After creating the pipeline, I call gst_element_set_state with
> > GST_STATE_PLAYING. After this initially all 3 of the plugins and pipeline
> > move to READY state (I get bus_call callback with state changed
> > confirmation). Then my source plugin changes to PAUSED state and then the
> > entire app hangs. I have attached the sample app code I am working on.
> > Please tell me what I am doing wrong here.
>
>  Most likely, your plugin is not pushing any buffers while in PAUSED state.
> The filesinks try to go to PAUSED asynchronously (as you can see from the
> set_state return value).  They will only succeed in the state change once
> they received a buffer from the upstream element.  This is called
> prerolling.
>
>  You can take a look at the implementation of GstBaseSrc
> (gstreamer/gst-libs/base/gstbasesrc.c) for an example of how a source
> element
> should work.  GstBaseSrc only supports a single source pad, so you can't
> use
> that directly.
>
>  By the way, it is in general not a good idea to combine stuff into a
> single
> element.  In particular, merging the demux with the source is probably a
> very
> bad idea.  In most cases, you can live with the standard source elements
> and
> just add a custom caps type for your mux.  Or, if really necessary, it may
> be
> more convenient to create two source elements that share some common state
> info.
>
>  Regards,
>  Arnout
>
> --
> Arnout Vandecappelle                               arnout at mind be
> Senior Embedded Software Architect                 +32-16-286540
> Essensium/Mind                                     http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR
> Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  D206 D44B 5155 DF98 550D  3F2A 2213 88AA A1C7 C933
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20090611/2474e7e0/attachment.htm>