<div>OK, I figured out the problem there.</div><div><br></div>What I was seeing is that the seek event never reaches my sink element, and when I dug into the gstreamer code using gdb to trace what code is actually being run, what I found is:<div>
<br></div><div>gstpad.c</div><div>function gst_pad_push_event()</div><div>around line 5267 (at least in this version)</div><div><br></div><div>peerpad = GST_PAD_PEER (pad);</div><div>...followed by...</div><div>result = gst_pad_send_event (peerpad, event);</div>
<div><br></div><div><br></div><div>So the event is going to the sink's peer instead of the sink itself. It turns out that the problem is that the custom audio sink does not have the "send_event" function defined.</div>
<div><br></div><div>Because of that, gst_element_send_event() in gstelement.c (called by gstbin.c) is choosing the default_send_event() since oclass->send_event is not defined. </div><div><br></div><div>I had been looking for the seek event to arrive in the class's "event" function, and hadn't implemented the "send_event" function. A quick hack to define it shows it being called correctly.</div>
<div><br></div><div>It seems confusing that a received seek event should come in on the "send_event" -- what's the reason for that?</div><div><br></div><div>--</div><div><br></div><div>Meanwhile,</div><div>
I'm still trying to determine why seek is failing with the new playbin2 pipeline</div>
<div><br></div><div>I edited the test stream and removed the id3 tags, so that playbin2 doesn't autoplug the id3demux. So the pipeline now looks like this:</div><div>filesrc ! typefind ! aacparse ! inputselector ! audiotee ! streamsynchronizer ! aqueue ! identity ! the_custom_decoder_and_sink</div>
<div><br></div><div>The seek command gets sent to the source pad of the "identity" element (because of my missing send_event() as explained above), and every part of the pipeline upstream are gstreamer built-ins.</div>
<div><br></div><div>Any thoughts?</div><div><br></div><div><br></div><div>Thank you,</div><div>Eric</div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">On Wed, Jun 20, 2012 at 12:01 PM, Tim-Philipp Müller <span dir="ltr"><<a href="mailto:t.i.m@zen.co.uk" target="_blank">t.i.m@zen.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 2012-06-20 at 11:34 -0400, Eric Montellese wrote:<br>
<br>
Hi,<br>
<div class="im"><br>
> However, when I dug into the code deeper, I found that the seek event<br>
> is not being delivered to the sink at all (which in this case would be<br>
> necessary since the sink and decoder are one element) -- instead the<br>
> seek event is going to the pad connected to the sink's sink pad (how's<br>
> that for a confusing sentence?). In other words, it is going to the<br>
> source pad of the element just upstream of the sink.<br>
> Is there a reason for that (other than to save a hand-off), or could I<br>
> modify the bin code to send the seek event to the sink element itself?<br>
<br>
</div>It should already go to the sink.<br>
<br>
The appliction should do gst_element_seek_simple (pipeline, ...), which<br>
does a gst_element_send_event (pipeline, gst_event_new_seek (..))<br>
internally.<br>
<br>
The pipeline then passes that seek event to the bins which are sinks,<br>
which in turn also pass it down the object hierachy on the sink side.<br>
This all goes via the send_event vfunc. Ultimately the event ends up in<br>
your sink, where the default send_event vfunc pushes it upstream into<br>
the pipeline, so it gets pushed to the peer element's src pad.<br>
<br>
You can of course implement your own vfunc and handle the seek event<br>
yourself in your sinkdecoder if you like.<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888"> -Tim<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> Of course, that would require me to implement seek within the decoder;<br>
> and given that it is already implemented within the parser, that would<br>
> be a foolish waste of effort if it's possible to avoid.<br>
><br>
><br>
> So, back to the original problem: getting playbin to plug a parser<br>
> automatically.<br>
><br>
><br>
> I found that aacparse has its rank set to: GST_RANK_PRIMARY + 1<br>
><br>
><br>
> Our decoder/sink was set to GST_RANK_PRIMARY + 2 -- so I deleted the<br>
> "+2" and ran again with playbin2. Lo and behold, aacparse is<br>
> autoplugged!... however, seek is still not working... so close and<br>
> yet no cigar.<br>
><br>
><br>
> The pipeline created by playbin2 now looks like this:<br>
> filesrc ! typefind ! id3demux ! aacparse ! inputselector ! audiotee !<br>
> streamsynchronizer ! aqueue ! identity ! the_custom_decoder_and_sink<br>
> I'm digging through here now to try and determine where the seek<br>
> command is getting rejected. In the meantime, any guesses?<br>
><br>
><br>
> This pipeline also produces the id3demux->aacparse warning:<br>
> 0:00:00.307036432 2287 0x8130758 WARN tagdemux<br>
> gsttagdemux.c:680:gst_tag_demux_chain:<id3demux0> Downstream did not<br>
> handle newsegment event as it should<br>
><br>
><br>
> but in this case, it continues playing (but not seeking). Perhaps<br>
> I'll see if I can pull the fix for that issue from git. Happen to<br>
> know where it went in? (if not, I can search, of course, but simpler<br>
> if someone happens to be familiar with it)<br>
><br>
><br>
> --<br>
> Finally, regarding the issue with id3demux not linking to aacparse:<br>
> I used id3demux because that was what was getting automatically<br>
> plugged by playbin2 (and I wanted to create a similar pipeline during<br>
> my testing). As we've seen, removing it does appear to work. Any<br>
> idea why playbin2 is autoplugging?<br>
><br>
><br>
> Unfortunately running gstreamer out of git isn't an option for this<br>
> project, which requires stability (otherwise I would :)<br>
><br>
><br>
><br>
><br>
> Thanks again for the help,<br>
> Eric<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> gstreamer-devel mailing list<br>
> <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</div></div></blockquote></div><br></div>