GST_ELEMENT_FLAG_SINK not set

[Christian Sell]

Hello Thiago,
 
thanks for your reply. In the meantime, the PaseParse has died since all it did
was pull frames from a custom src upstream. Now everything is handled in the
src, and problems have vanished.
 
regards,
Christian
 

> Thiago Santos <thiagoss at osg.samsung.com> hat am 28. Mai 2015 um 06:49
> geschrieben:
> 
>  On 05/21/2015 09:27 AM, Christian Sell wrote:
> 
>      > >      hmm, but whats entirely not normal IMO is the fact that the seek
>      > > fails without ever reaching my element logic. If I dont have the flag
>      > > set, my element is not used at all. If I have it set, the BaseParse
>      > > implementation says it cannot handle negative playback rates...
>      > > bummer.
> > 
> >  > Your baseparse element shouldn't have the SINK flag marked as it is not a
> >  > sink.
> 
>  What is your full pipeline? Does the seek work if you remove your element?
> 
>  Additionally, check gstbaseparse.c code, specially the default source event
> handler: gst_base_parse_src_event_default
> 
>  It should help you understand why does your element doesn't support seeking.
> 
>      > >       
> > 
> >      > Tim Müller <tim at centricular.com> <mailto:tim at centricular.com> hat am
> >      > 21. Mai 2015 um 14:13 geschrieben:
> >      >
> >      >
> >      > On Thu, 2015-05-21 at 13:24 +0200, Christian Sell wrote:
> >      >
> >      > Hi,
> >      >
> >      > > I have an element derived from GstBaseParse. Now, whenever I
> >      > > perform a
> >      > > seek operation on the pipeline, the seek fails, and I see a log
> >      > > messate stating "child <element> is not a sink". Digging into the
> >      > > code
> >      > > that emits the log message, I see that a flag GST_ELEMENT_FLAG_SINK
> >      > > is
> >      > > queried, which is not set on the element, although it clearly has a
> >      > > sink pad.
> >      > >
> >      > > My question: who is responsible for setting it? Is this described
> >      > > somewhere?
> >      >
> >      > Only sink elements,i.e elements that *only* have a sink pad, should
> >      > have
> >      > that flag set. In any case it's just an optimisation so if it's not
> >      > set
> >      > that should not affect behaviour. GstBin looks at that.
> >      >
> >      > The log messages are normal. When a seek is sent to the top-level
> >      > pipeline it travels down the pipeline bin/element hierarchy via the
> >      > GstElement::send_event vfunc. Depending on whether the event is an
> >      > upstream event or a downstream event the GstBin/pipeline will seek to
> >      > go
> >      > down the pipeline hierarchy until it finds a sink or source element,
> >      > which will then inject the element into the data flow and push it
> >      > upstream/downstream. So it's entirely normal.
> >      >
> >      > Cheers
> >      > -Tim
> >      >
> >      > --
> >      > Tim Müller, Centricular Ltd - http://www.centricular.com
> >      >
> >      > _______________________________________________
> >      > gstreamer-devel mailing list
> >      > gstreamer-devel at lists.freedesktop.org
> >      > <mailto:gstreamer-devel at lists.freedesktop.org>
> >      > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> > 
> > 
> > 
> >      _______________________________________________
> >      gstreamer-devel mailing list
> >      gstreamer-devel at lists.freedesktop.org
> > <mailto:gstreamer-devel at lists.freedesktop.org>
> >      http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> > 
> >  > 
> 
>  -- 
>  Thiago Sousa Santos
>  Senior Multimedia Engineer, Open Source Group
>  Samsung Research America - Silicon Valley
> 

 

> _______________________________________________
>  gstreamer-devel mailing list
>  gstreamer-devel at lists.freedesktop.org
>  http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150528/424591d9/attachment-0001.html>