<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 05/21/2015 09:27 AM, Christian Sell wrote: </div> <blockquote cite="mid:1396151870.161728.1432211266364.JavaMail.open-xchange@omgreatgod.store" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <div>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.</div> </blockquote> 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. <blockquote cite="mid:1396151870.161728.1432211266364.JavaMail.open-xchange@omgreatgod.store" type="cite"> <div> </div> <div> > Tim Müller <a class="moz-txt-link-rfc2396E" href="mailto:tim@centricular.com"><tim@centricular.com></a> 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 - <a class="moz-txt-link-freetext" href="http://www.centricular.com">http://www.centricular.com</a> > > _______________________________________________ > gstreamer-devel mailing list > <a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> > <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></div> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ gstreamer-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </pre> </blockquote> <pre class="moz-signature" cols="72">-- Thiago Sousa Santos Senior Multimedia Engineer, Open Source Group Samsung Research America - Silicon Valley</pre> </body> </html>