Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31

[Tim-Philipp Müller]

On Wed, 2012-06-20 at 11:34 -0400, Eric Montellese wrote:

Hi,

> 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. 
> 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?

It should already go to the sink.

The appliction should do gst_element_seek_simple (pipeline, ...), which
does a gst_element_send_event (pipeline, gst_event_new_seek (..))
internally.

The pipeline then passes that seek event to the bins which are sinks,
which in turn also pass it down the object hierachy on the sink side.
This all goes via the send_event vfunc. Ultimately the event ends up in
your sink, where the default send_event vfunc pushes it upstream into
the pipeline, so it gets pushed to the peer element's src pad.

You can of course implement your own vfunc and handle the seek event
yourself in your sinkdecoder if you like.

Cheers
 -Tim


> 
> 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.
> 
> 
> So, back to the original problem:  getting playbin to plug a parser
> automatically.
> 
> 
> I found that aacparse has its rank set to:  GST_RANK_PRIMARY + 1
> 
> 
> 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.
> 
> 
> The pipeline created by playbin2 now looks like this:
> filesrc ! typefind ! id3demux ! aacparse ! inputselector ! audiotee !
> streamsynchronizer ! aqueue ! identity ! the_custom_decoder_and_sink
> I'm digging through here now to try and determine where the seek
> command is getting rejected.  In the meantime, any guesses?
> 
> 
> This pipeline also produces the id3demux->aacparse warning:
> 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
> 
> 
> 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)
> 
> 
> --
> Finally, regarding the issue with id3demux not linking to aacparse:
> 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?
> 
> 
> Unfortunately running gstreamer out of git isn't an option for this
> project, which requires stability (otherwise I would :)
> 
> 
> 
> 
> Thanks again for the help,
> Eric
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel