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

Wed Jun 20 18:51:40 PDT 2012

I determined what is going on (but still not sure how to fix it):

With playbin2 on my "host" machine (a standard ubuntu install), playbin2
plugs in the faad decoder within the decodebin.  The seek event traverses
the pipeline from sink to source and gets handled by the faad decoder
within decodebin

With playbin2 on my "target" machine (hardware requires use of the custom
audio sink), playbin2 plugs in the aacparse element within the decodebin.
 When the seek event traverses the pipeline, it is received by decodebin
which appears to skip the aacparse element entirely.  Instead it goes
through the typefind element and into the source, which then fails to
perform the seek due to a failure in the GST_QUERY_CONVERT call (haven't
dug into exactly why yet -- but appears to be a type mismatch?)

This explains why the manual pipeline works, but the playbin2 pipeline
doesn't... the critical element is being skipped with playbin2.

So, the big question remaining is:  Why is the decodebin not sending the
SEEK event to the aacparse element within it?

Any pointers as I dig through this are appreciated!

Thanks,
Eric

On Wed, Jun 20, 2012 at 12:49 PM, Eric Montellese <
eric.montellese at videon-central.com> wrote:

> 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/97a79fee/attachment-0001.html>