[gst-devel] Problem with linking more sinks

[Miron Kunz]

Yes queue is set to PLAYING too.

Looks like the pad in wrong state belongs to some videoscale element in sink2. Videoscale's sink pad is in state "flushing" causing the flow to stop.
Is it possible to revive it?

Is there element that can keep flow on even if one brunch of the tee is flushing?

Thanks,
Miron.


> Are you changed the queue, tee elements into playing state.
> Because pad_push returns - wrong state, if pad in wrong state.
> 
> On Sat, Jan 2, 2010 at 2:17 PM, Miron Kunz <mironoz at mail.ru> wrote:
> 
> > Hi,
> >
> > I am trying to link a next sink like this:
> >
> > 1) start pipeline : src!tee ! queue!sink1
> > 2) pipeline is in PLAYING
> > 3) block Src's src pad and from call back add new sink2:
> >  src ! tee ! queue !sink1
> >            ! queue !sink2
> > 4) set sink2 to PLAYING
> > 5) unblock Src's src pad
> > 6) Src's task is PAUSED with this message:
> >  basesrc gstbasesrc.c:2326:gst_base_src_loop:<camera> pausing after
> > gst_pad_push() = wrong-state
> >
> > The problem is that source's task is paused and there is no flow through
> > the pipeline.
> >
> > What is the correct way to deal with it?
> >
> >
> > Thanks,
> > Miron
> >
> >
> >
> > ------------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Verizon Developer Community
> > Take advantage of Verizon's best-in-class app development support
> > A streamlined, 14 day to market process makes app distribution fast and
> > easy
> > Join now and get one step closer to millions of Verizon customers
> > http://p.sf.net/sfu/verizon-dev2dev
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> >
> 
>