[Bug 680367] GstDiscoverer on Gstreamer 0.11/1.0 is slower than on 0.10 and throws errors

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=680367
  GStreamer | don't know | 0.11.x

Edward Hervey <bilboed> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bilboed at gmail.com

--- Comment #1 from Edward Hervey <bilboed at gmail.com> 2012-07-22 08:18:04 UTC ---
(In reply to comment #0)
> ** (disco:13162): CRITICAL **: gst_audio_decoder_finish_frame: assertion `buf
> == NULL || gst_pad_has_current_caps (dec->srcpad)' failed

  This should be fixed in git

> 
> At least initially 0.10 seems to manage to extract mp3 files in ~0.005s while
> 1.0 needs ~0.05s. 
> 

  I think this is due to the following commit (present in both 0.10 and 1.0):

commit e40ea309721eff8e1168844d81e2ca515e7acb6d
Author: Tim-Philipp Müller <tim.muller at collabora.co.uk>
Date:   Tue Feb 14 19:23:27 2012 +0000

    discoverer: try harder to obtain a duration if we don't get one right away

    If we don't get a duration right away, set the pipeline to playing
    and sleep a bit, then try again. This is ugly, but the least worst
    we can do right now. The alternative would be to make parsers etc.
    return some bogus duration estimate even after only having pushed
    a single frame, for example.

    Fixes discoverer showing 0 durations for some mp3 and aac files
    (e.g. soweto-adts.aac).

---------

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.