Tim, thanks for the reply.  Knowing that seek was implemented in the decoders in older versions of gstreamer clears up some of my confusion.<div><br></div><div>However, when I dug into the code deeper, I found that the seek event is not being delivered to the sink at all (which in this case would be necessary since the sink and decoder are one element) -- instead the seek event is going to the pad connected to the sink's sink pad (how's that for a confusing sentence?).  In other words, it is going to the source pad of the element just upstream of the sink. </div>

<div><br></div><div>Is there a reason for that (other than to save a hand-off), or could I modify the bin code to send the seek event to the sink element itself?</div><div><br></div><div>Of course, that would require me to implement seek within the decoder; and given that it is already implemented within the parser, that would be a foolish waste of effort if it's possible to avoid.</div>

<div><br></div><div>So, back to the original problem:  getting playbin to plug a parser automatically.</div><div><br></div><div>I found that aacparse has its rank set to:  GST_RANK_PRIMARY + 1</div><div><br></div><div>Our decoder/sink was set to GST_RANK_PRIMARY + 2 -- so I deleted the "+2" and ran again with playbin2.  Lo and behold, aacparse is autoplugged!... however, seek is still not working...  so close and yet no cigar.</div>

<div><br></div><div>The pipeline created by playbin2 now looks like this:</div><div>filesrc ! typefind ! id3demux ! aacparse ! inputselector ! audiotee ! streamsynchronizer ! aqueue ! identity ! the_custom_decoder_and_sink</div>

<div>I'm digging through here now to try and determine where the seek command is getting rejected.  In the meantime, any guesses?</div><div><br></div><div>This pipeline also produces the id3demux->aacparse warning:</div>

<div><div>0:00:00.307036432  2287  0x8130758 WARN                tagdemux gsttagdemux.c:680:gst_tag_demux_chain:<id3demux0> Downstream did not handle newsegment event as it should</div></div><div><br></div><div>but in this case, it continues playing (but not seeking).  Perhaps I'll see if I can pull the fix for that issue from git.  Happen to know where it went in?  (if not, I can search, of course, but simpler if someone happens to be familiar with it)</div>

<div><br></div><div>--</div><div>Finally, regarding the issue with id3demux not linking to aacparse:</div><div>I used id3demux because that was what was getting automatically plugged by playbin2 (and I wanted to create a similar pipeline during my testing).  As we've seen, removing it does appear to work.  Any idea why playbin2 is autoplugging?</div>

<div><br></div><div>Unfortunately running gstreamer out of git isn't an option for this project, which requires stability (otherwise I would :)</div><div><br></div><div><br></div><div>Thanks again for the help,</div>
<div>
Eric</div>