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

[Eric Montellese]

OK, I figured out the problem there.

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:

gstpad.c
function gst_pad_push_event()
around line 5267 (at least in this version)

peerpad = GST_PAD_PEER (pad);
...followed by...
result = gst_pad_send_event (peerpad, event);


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.

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.

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.

It seems confusing that a received seek event should come in on the
"send_event" -- what's the reason for that?

--

Meanwhile,
I'm still trying to determine why seek is failing with the new playbin2
pipeline

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:
filesrc ! typefind ! aacparse ! inputselector ! audiotee
! streamsynchronizer ! aqueue ! identity ! the_custom_decoder_and_sink

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.

Any thoughts?


Thank you,
Eric




On Wed, Jun 20, 2012 at 12:01 PM, Tim-Philipp Müller <t.i.m at zen.co.uk>wrote:

> 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
>
>
> _______________________________________________
> 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/20120620/30e261a4/attachment.html>