[gstreamer-bugs] [Bug 641047] [mpegaudioparse] Multiple issues with new mpegaudioparse element from -bad, lower rank?

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=641047
  GStreamer | gst-plugins-bad | 0.10.21

Mark Nauwelaerts <mnauw> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mnauw at users.sourceforge.net

--- Comment #1 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2011-01-31 17:40:23 UTC ---
For the seeking case there is actually an improvement in mpegaudioparse that
makes it (baseparse) wait a (slight) while to come up with a reliable duration
estimate.  However, it happens that Totem queries for seekability during this
short interval, and baseparse reports (cautiously) "not seekable" (since not
knowing a duration yet).  After initial query, Totem does not query again, and
so the clip is believed not seekable.

As such, it depends on the precise (undefined?) semantics of QUERY_SEEKING. 
Should an application query multiple times, or is the first TRUE answer to hold
for ever?  Anyway, possible patch to follow that will have baseparse return
FALSE to the query as long as it does not have a duration and there might still
be a chance it can handle seeking.  It is then to be hoped that "failing to
handle the query" does not confuse other players/frameworks out there and is
actually a valid response in such case.

As the artwork, that is actually extracted by another element (id3demux), and
still works fine (using gst-launch-0.10) when mpegaudioparse is used:
----
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
FOUND TAG      : found by element "id3demux0".
           title: Glimmer (Album Version)
          artist: Garmisch
           album: Glimmer
            date: 2010-01-01
    track number: 1
           genre: Electropop
container format: ID3 tag
        duration: 1537158784000000
     ID3v2 frame: buffer of 30 bytes, type: application/x-gst-id3v2-tden-frame,
version=(int)4
                : buffer of 30 bytes, type: application/x-gst-id3v2-tdtg-frame,
version=(int)4
     track count: 6
       copyright: This work is licensed under a Creative Commons
Attribution-Noncommercial-No Derivative Works 3.0 License
           image: buffer of 913258 bytes, type: image/png,
image-type=(GstTagImageType)GST_TAG_IMAGE_TYPE_UNDEFINED
FOUND TAG      : found by element "apedemux0".
replaygain track gain: 0.925000
replaygain track peak: 0.630134
replaygain album gain: -0.695000
replaygain album peak: 0.649180
container format: APE tag
FOUND TAG      : found by element "mpegaudioparse0".
         bitrate: 192000
FOUND TAG      : found by element "mpegaudioparse0".
     audio codec: MPEG 1 Audio, Layer 3 (MP3)
FOUND TAG      : found by element "mpegaudioparse0".
         has crc: FALSE
    channel mode: joint-stereo
FOUND TAG      : found by element "mad0".
           layer: 3
            mode: joint
        emphasis: none
         bitrate: 192000
FOUND TAG      : found by element "mpegaudioparse0".
 minimum bitrate: 4294967295
         bitrate: 192000
 maximum bitrate: 0
FOUND TAG      : found by element "mpegaudioparse0".
 minimum bitrate: 192018
 maximum bitrate: 192018
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock
FOUND TAG      : found by element "mpegaudioparse0".
 minimum bitrate: 191712
---
Tags thrown by mpegaudioparse are slightly different than those by mp3parse,
but Totem should still pick up what id3demux reports (which it seems to fail
with more than only album art afaics).

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