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

[Tim-Philipp Müller]

On Tue, 2012-06-19 at 11:30 -0400, Eric Montellese wrote:

Hi Eric,

haven't really loked at all details of your mail, but you should
probably assume that seeking in mp3 files has worked out of the box, at
least with decodebin2/playbin2 and our default decoders, in about any
version of GStreamer.

If that's not the case for you, it's probably because you get a
different decoder plugged than most people (we used to implement the
seeking for such formats in the decoders, now that task has moved to the
parsers, although it should still be supported by decoders for backwards
compatibility reasons.)

Make sure you have the mad element (for mp3 decoding) and the faad
element (for aac decoding) installed.


> Looking on the GStreamer
> website http://gstreamer.freedesktop.org/news/, I saw the note in the
> latest 0.10 release that said:
>         decodebin/playbin2 now plug parsers by default
> So I decided to upgrade to the 2012-02-21 release.
> 
> However, I found that playbin2 still does not autoplug the audio
> parsers in this release.  Bummer.  So, first question:
> 
> "Is there any way to encourage playbin2 to autoplug the audio
> parsers?"
> and
> "Is this a known issue, and is there a known workaround?"

It should work. However, it might not work with third party decoders
that assume a rank that's higher or the same as the parsers (we kind of
overlooked that possibility, and none one of those third parties seem to
have noticed either; it's fixed in git though, now parsers are preferred
irrespective of ranks).


> Either way: now that I've done the work to upgrade, I'd like to keep
> the updated components -- however, I am now seeing a bug with aacparse
> regarding newsegments:
> 
> # gst-launch  filesrc location=/media/Honesty.aac ! id3demux !
> aacparse ! custom_audio_decoder_and_sink
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> 0:00:00.282161885  2561  0x812f188 WARN                tagdemux
> gsttagdemux.c:680:gst_tag_demux_chain:<id3demux0> Downstream did not
> handle newsegment event as it should
> 0:00:00.282425516  2561  0x812f188 WARN                 basesrc
> gstbasesrc.c:2625:gst_base_src_loop:<filesrc0> error: Internal data
> flow error.
> 0:00:00.282490123  2561  0x812f188 WARN                 basesrc
> gstbasesrc.c:2625:gst_base_src_loop:<filesrc0> error: streaming task
> paused, reason not-linked (-1)
> ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0:
> Internal data flow error.
> Additional debug info:
> gstbasesrc.c(2625): gst_base_src_loop
> (): /GstPipeline:pipeline0/GstFileSrc:filesrc0:
> streaming task paused, reason not-linked (-1)
> ERROR: pipeline doesn't want to preroll.
>
> This exact command worked correctly (and this pipeline would seek)
> with the previous version (version numbers listed at the top)

I'm surprised this worked before, it's a somewhat weird pipeline. I
would have expected it to error out if there isn't actually an ID3 tag
(I'm assuming there usually isn't). Either way, the "newsegment issue"
isn't a bug in aacparse, but related to id3demux not getting linked to
aacparse. As the error message implies, there is an issue with elements
not getting linked.

In this particular case, that seems to be a bug in aacparse's get_caps()
function. It appears to be fixed in git.

Doesn't seem to be an issue with more normal pipelines such as filesrc !
typefind ! aacparse ! .. or filesrc ! aacparse ! .. as far as I can
tell.

 Cheers
  -Tim